Re: [boost] Re: Boost.MathConstants: Review

From: Ed Brey (brey_at_[hidden])
Date: 2001-04-22 14:39:43

From: "David Abrahams" <abrahams_at_[hidden]>
> I think it might be a reasonable simplification to supply a single
interface
> and ask the user to write:
>
>   double const four_thirds_pi = boost::math::constants<long double>::pi()
*
> 4./3.;

I think at the heart of the matter is the question of the true requirements
for Boost.MathConstants.  One requirement that I would like to see is that a
constant act "just like a float".  For many (most?) applications, absolute
best precision isn't necessary, and is secondary to ease of use (read
time-to-market), so long as the result still falls in the range of
"correct".  Just having math constants is a great starting point: I don't
need to dig out a textbook.  But even better is to not have to learn a new
set of rules.  I know how floats work, and if I am guaranteed that (assuming
a compiler can inline reasonably) the boost constants will operate just like
a literal, I can get my job done quickly.  The kind of temporary above is
exactly the type of thing I would want to avoid.

On the other hand, if I need abolute precision, I also wouldn't write an
expression for four_thirds_pi, but rather would use some mechanism to
generate the binary value for that expression for each platform my program
will run on.  I would consider this an uncommon case, which is fortunate,
since it is a lot of work.  I certainly don't see any problem with a
different interface for this quite different usage.

Regarding Peter's contention that the user can hardly tell the difference
between inline, out-of-line, and tailored (binary) constants, I think the
difference between having and not having compile-time constant folding is
quite noticeable and cannot be abstracted away, since it can have an
important performance impact.

From: "John Maddock" <John_Maddock_at_[hidden]>
> I prefer "boost::constants<T>" to the "boost::math::constants<T>" which
> some have suggested, I don't see what the latter buys us, other than more
> typing.  Shouldn't nested namespaces be reserved for things probably not
> used by end users (or only used by power users), this definitely in the
end
> user camp.

A potential problem with boost::constants is that boost will in the future
have physical constants, and it may be valuable to keep mathematical and
physical constants separate.  No conflicts between math and physical
constants come to mind at the moment; however, I'm pretty sure there are
conflicts between different domains of physical constants, and so they will
need to be separated, and so it would be natural to put math constants into
a sibling group, rather than have them own the name "constants".

The issue of the subnamespace is a larger one, which to my knowledge is
still quite unresolved.  Other modern languages are moving to subsectioning
their standard namespaces (I'm thinking of Java and C#), which does have the
advantage of the using directive practical, since name collision risk drops
to an acceptable level (minimally no more likely than a new language keyword
stomping on your existing code).  It would be nice to see Math.Constants be
part of a coordinated approach one way or the other.  An example of a
question that would be answered by the approach is whether there would be a
boost::math::abs.