RE: [boost] math constants

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2000-07-24 15:10:43

> From: John Maddock [mailto:John_Maddock_at_[hidden]]
> Sent: Sunday, July 23, 2000 12:29 PM

> Subject: [boost] math constants
> 1) is the class int_math_const really necessary?  I don't
> really see what benefit it brings?

[PAB]C onfirms my feeling.

> 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.

[PAB] Probably best, though won't this mean that user defined types
always have to be specialised,
when they might rely on conversion to double?

If you have a type square with length & width, will you have to define

> 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),

[PAB] Since there are so many sig figs, surely should get the nearest
possible representation in 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.
[PAB]  Not too sympathetic to dodgy compilers here!
Surely the above is strictly correct, and should not avoid any warnings.

> 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).

[PAB]  Other views on names?????
If you have constants like "two", it seems logical to have "sqrt_two" ...
Other names may have been used before?

> 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?

[PAB]  Many of these tests DO fail - precisely because the
value given to 40 decimal places really is closer than the
result of the coputation and/or C library call
which necessarily are less accurate cos only done using IEEE FP hardware,
not Victor Shoup's NTL.  One objective is to get the nearest
to the possible representation.

The checks only highlight significant differences.  Most are within
1 or 2 epsilon, but pow functions are quite a lot less good.

I haven't been able to test on long double (MS VC++ 6 treats double and long
double the same).

Can anyone do this with a real compiler?

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

[PAB]  Yes, indeed.
>
> - John.
>
> Note 1 - see "What Every Compuser Scientist Should Know About Floating
> Point Arithmetic", David Goldberg, March 91, Computing Surveys.

Seen this - and is in the references in the enhanced documentation.