[boost] Re: math constants

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-07-26 06:44:31

Daryl,

>I don't think that would work.  It could count as a forward declaration,
leading to a link-time error (not compile-time since the compiler could
assume it's just defined elsewhere).  If it could result in a compile-time
error, you could not test that type!  The is-specialized method works
better, since you could always check it and use it in meta-whatever stuff.

template <typename T>
struct math_const
{
    static bool  is_specialized = false;

    // Should we even have fake-methods follow this?  Having nothing
    // here would make any use of a non-specialized version choke.
    // We could leave nothing after this, but then you wouldn't get
    // a guide for future implementers.  Another alternative would
    // be to define the methods as private, but have them public
    // for all specializations.
};

template <>
struct math_const<double>
{
    static bool  is_specialized = true;

    //...
};
<

I forgot all about is_specialized, yes you are correct, we should follow
numeric_limits example, and implement all methods - but have them return
dummy values if is_specialized is false.

>There's another problem: how do we know that the constant is long enough?
Some implementations may consider the literals given sufficient, others can
allow more precision, so a longer constant could be used.  Is there a
minimum precision for float, double, and long double?  Are floating-point
literals allowed to be longer that the implementation can handle, silently
truncating the extra digits?  If so, maybe we could make the literals a
hundred or two digits long to be (currently) safe.
<

I think float and double are covered by IEEE754 (23 and 53 bits precision
respectively), extended float must have at least 32 bits precision and
extended double (aka long double in C and C++) must have 64 bits precision
(meaning at least 79 bits including sign and exponent bits).

So we are OK for float and double, but not for long double, for which we
satisfy only the minimum requirements (that is for 80 bit long doubles), I
suspect that there may be 128-bit long doubles out there (anyone know?), in
which case we're going to need more digits, I don't know how many more
though...

>The name "math" would be too vague.  The "math_constants" name would be a
nice adaptation of the name currently suggested.  It's a general name, so
maybe only really generally important mathematical numbers (zero, one, pi,
e, gamma, etc.) should be in this class.  A lot of the different constant
combinations probably shouldn't be in this class, but in similar class,
since a lot of people wouldn't need the derivative constants.  (Maybe they
could be kept in the same header file.)
<

Yep, OK.

>Actually, boost doesn't seem to use a compact naming style, and these
classes should remain consistent.  The longer names provide a better
explanation of what the derivative constants are, and underscores mean the
user doesn't have to attempt inter-caps parsing.

"root2" is bad since:
1.  The two words are run together.  (I count a number as a word.)
2.  It's inaccurate.  You mean square root, but the original poster had
cube
roots, etc., so "root" by itself is vague.

The "sqrt" part of "sqrt_two" (or "sqrt_2") is tolerable since "sqrt" is
already used by C/C++ as the square root function in the standard library.

I guess "reciprocal_sqrt_2" would be better than "r_root2" or
"one_div_sqrt_two" ("1_div_sqrt_2" is illegal, of course).  It better
emphasizes that we want the multiplicative inverse of the square root of
two, not just one divided by two (like we could want negative one, not zero
minus one).
<

OK I just dislike typing :-)

- John.