From: Ed Brey (edbrey_at_[hidden])
Date: 2001-10-25 15:55:47
From: "Greg Colvin" <gcolvin_at_[hidden]>
> I don't see the need for three flavors of pi, so if double is the best
> default then that is all we should provide for unadorned use.
Sounds quite reasonable to me. Especially given availability of float or long double via a constant<float>::pi() style interface.
> If someone is serious about paramerizing their program on floating-point
> type it seems they should do:
> typedef double Real;
> using namespace boost::math;
> Real foo = Real(4.)/Real(3.) * constant<Real>(pi) * r * r * r;
> Or if they need to use these constants a lot:
> const Real Four_Thirds = Real(4) / Real(3);
> const Real Pi = constant<Real>(pi);
Agreed in spirit, although, I'd tend towards
Real foo = Real(4.)/Real(3.) * constants<Real>::pi() * r * r * r;
Or if various constants appear frequently:
typedef constants<Real> constants;
Real foo = Real(4.)/Real(3.) * constants::pi() * r * r * r;
Both approaches seem fine. I tend toward the second one because of its consistency with numeric_limits, and the obviousness of the function syntax (see below).
> > > Of course Beman says "Please do not make any design decisions for math
> > > constants based on brain-dead compilers."
> > Agreed. Of course, the same techniques that break compilers also tend to fight the language. Using the operator double()
> approach, gone is the obviousness of parentheses meaning function and no parentheses meaning variable. Instead, what looks like a
> variable actually has the restrictions of a function. This may be one of those cases when an exception to the norm is a good thing,
> but such exceptions need to be examined closely.
> What restrictions of a function do you mean? In my design pi is an
> object, not a function. You can pass it by address or by reference.
pi is an object, but not of the type one might expect. For example, a function like the following won't work:
double triple(double const* x); // Triples x, or returns 0 if x is null.
Of course, such a function won't work with a literal either. One approach is to say "treat a math constant like a literal", even though it is really an object. On the other hand, if a function-style syntax is used, you don't need to say anything: it will be obvious that you can only do what you'd do with a literal.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk