math constants

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

Hi,

I noticed the following while looking through your math constants defs:

1) is the class int_math_const really necessary?  I don't really see what
benefit it brings?

2) I wouldn't provide a default implementation for math_const, if
math_const isn't specialised for a given type then using it should result
in a compile time error, a simple declaration like:

template <class T> struct math_const;

is sufficient.

3) In the definition of math_const<float> you have:

    static const T sqrt_two() _THROW0()
                { return
static_cast<T>(1.41421356237309504880168872420969807857L); }

I think that I'm correct in saying that the value here will be rounded
twice - once on decimal to binary conversion (to a long double), and then
once again on conversion to float.  However, some compilers will not do the
second rounding (though according to the standard they should) and instead
return the long double value.  Whatever you may want to check your
suffixes.

4) I'm not all that struck on your choice of names (although I don't
necessarily have any better idea's!), some possible choices in place of
math_const would be: numeric_values, math_values, math_constants, or just
plain "math".

For the names of members, lets try and keep them as short as possible, how
about "root2" in place of "sqrt_two", and "r_root2" in place of
"one_div_sqrt_two".  There are a few other names that could have digits
replace charcaters in parts of their names (I note that you do this already
for ln_2): for example sin1, cos1 etc.  BTW I don't think that you need an
underscore to separate a digit from an character in these cases (so maybe
just ln2 ln10 etc).

5) I'm not entirely convinced by you're tests (yet), The key test for each
value is: "that there exists no binary representation that is closer to the
actual value", in other words each value should be to within 0.5ulp (see
note 1), or to put it another way, if we add (or subtract) 1ulp to the
value, then the result should be demonstrably further away from the actual
value.  This should be testable fairly easily for things like root2, but
may be very hard (impossible?) for the other values.

I'm not necessarily convinced that tests like:

        assert(sqrtTwo == sqrt(2.));  // C Library call same a const
double.

are always guarenteed to succeed - maybe for float and double they are, but
not for long double where rounding error must surely have contaminated some
of the digits in the calculated result?

Anyway, thats enough for now, I hope you find this useful.

- John.

Note 1 - see "What Every Compuser Scientist Should Know About Floating
Point Arithmetic", David Goldberg, March 91, Computing Surveys.