Re: [boost] Math constants for naive and gurus? - which constants do you want?

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-10-26 10:58:58

----- Original Message ----- 
From: Peter Dimov <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 26, 2001 4:35 AM
Subject: Re: [boost] Math constants for naive and gurus? - which constants do you want?

> From: "Ross Smith" <r-smith_at_[hidden]>
> > As long as we're all piling on, here's yet another suggestion...
> 
> [ based on operator Result() ]
> 
> > Now we can use boost::pi() as a constant, and the type will be deduced
> > from the context. If the context gives the wrong type or is ambiguous,
> > just use an explicit cast. (This doesn't quite solve the "people who
> > want to use 'pi' unadorned" problem, but I think a simple pair of
> > parentheses should be acceptable.)
> 
> All these solutions have a common drawback:
> 
> template<class Numeric> void foo(Numeric n);
> 
> foo(pi()); // calls void foo<some_type_that_is_not_numeric>

If this is a real problem, and I can see where it might be, then
the solution could be something like:

  template <classname T=double> inline T pi() { return T(3.14...);}

with optional specializations.  But then of course pi() is not
an object, and we are stuck with those ugly parentheses.

Another solution, if pi or pi() are actually objects, is to
provide a full complement of arithmetical operators, so that in
some sense the type of the pi object is numeric.  But no doubt
it will fail to act like a built-in numeric type in some
important way.

So at the moment I am feeling defeated, and think we should
just take John Skaller's advice:

    namespace boost {
        namespace math {
            namespace constants {
                static const double pi = ... ;
                static const double e = ... ;
                ...
            }
        }
    }

Simple, easy to use with no nasty surprises, and all that is
needed by most users.  And rather than try to design in advance
for possible fancy implementations we wait for such to be
proposed before worrying about the best possible interface.