Re: [boost] Math Constants Library formal review results

From: Ed Brey (brey_at_[hidden])
Date: 2001-04-25 13:02:33

From: "Jens Maurer" <Jens.Maurer_at_[hidden]>

> Also, the user can emulate constant-folding by defining
> additional variables any time, e.g.
>   const double three_pi = 3*constants<double>::pi()
> for those rare cases where it really matters speed-wise.

True.  However, this feels even more distasteful than having a larger
interface to Boost.MathConstants.  A large part of the purpose of this
library is to make life easy for the user.

> Contrary to integer constant folding, where some integer
> multiplications can be replaced by clever shift and add
> sequences, I don't believe that floating point compile-time
> constants versus floating point variables with fixed content
> provide significant advantage to the compiler.

By constant folding, I'm not referring to finder more optimal ways to
perform a computation at run-time; I'm referring to the elimination of
the computation altogether, as in 3. * 3. gets converted to 9. at
compile time.  This optimization applies equally well to integer and
floating point operations.

Giving this whole issue some more thought, I think there's another
factor that will help define what to do.  It is a common case that
constants get multiplied together at compile time.  If this were not the
case, we wouldn't see so many constants like half_square_root_two in the
proposed library.  It's also likely that the user will encounter
constant combinations that don't exist in the predefined library, just
like four_thirds_pi wasn't in the proposed library.  Since a user who
needs binary precision numbers really cares about accuracy, he will be
compelled to not let the compiler combine the constants at runtime, but
rather do it by hand at design time.  Most of the work in creating
constants by hand is digging out and setting up the tool to do the
generation.  Therefore, having a subset of the constants he needs
predefined in MathConstants will be of little value, since the large
overhead remains for the generation of the constants not supplied.

Since users who need binary constants are few and the value to them of a
MathConstants library that supports binary constants is small, there is
insufficient justification for a tailored_constants interface.
Furthermore, the extended accuracy of binary constants becomes a small
factor in weighting the implementation of the mainstream (and only)
constants interface (since those needing accuracy need custom code
anyway).  Rather, the benefits, particularly constant folding, of the
constants behaving just like a literal take precedence, and so the
library implementation should be biased toward having the constants
behave like literals (inline and in decimal form for most
implementations).