Boost logo

Boost :

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, gregod at, cpdaniel at, john at