Math Constants

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-02-09 05:45:44

Many months ago I floated (sorry) some high accuracy mathematical constants
to become part of the Boost suite.

I have now cleaned the paint off my body in the aftermath of moving house
and am returning to more esoteric math constants.

I have considered the comments on my initial proposals, and taken expert
advice.

As a result I am starting again with a much simpler proposal -
a file of long double #defined constants

  #define SQRT2 1.41421356237309504880168872420969807857L
  // and lots more

and some recommendations for C++ use:

const float sqrt_2 = static_cast<float>SQRT2;

(Perhaps a recommendation for using a un-named namespace to limit the scope
of sqrt_2 to one compilation unit?)

Perhaps a small sub-set of doubles(?) in a separate file in the boost
namespace: pi, e, sqrt2 ...?

My reasons for this are:

1  High-as-possible accuracy is the most important feature of the constants.
35 decimal digits are enough for all floating point hardware available
now or for some time to come - 128 bit reals with 106 mantissa bits.

(Though it would be useful to the number theoretic community, using NTL for
example,
to provide even more digits but some 'naive' (non-compliant?) compilers are
said (by pjp) to choke on more than 35 decimal digits.  (MS is OK for once!)
(Using NTL it is very easy to change the number of digits output).

2  They may be more widely used in C, C++ and higher precision packages
128-bit quad_precision like NTL
(which was used to compute them).

3  Using #define means that conversion will take place in the host compiling
machine,
and so no run-time penalty.  Host machines are more likely to have better FP
hardware.
(Anyone working with new ultra-super 256-bit floating point hardware can do
their own thing!)

4  Using #define means that the namespace need not be cluttered with lots of
names,
and the compiler doesn't have to deal with preprocessor stuff for long.
This is
convenient if the list contains many constants as I feel is useful.  It is
difficult
to argue one constant's usefulness over another - one man's meat ...
Splitting the constants into lots of smaller files is trouble for
maintenance,
and confusing for the users.  Lots of names are needed to get the advantage
of more accurate values (because calculated with higher precision NTL than
the compiler can with long double).

5  Using #define means that cut and paste editing is easy and less
error-prone.
(Though this is not the main intention of the files, but what may happen in
practice!)

6  Ending constants with L puts the onus on the compiler to make conversions
correctly from long double, (and this does seem to happen OK from pjp's
experience).

7 static_cast ing provides the way for users to get what they want.
In practice, I cannot foresee wanting more than one type at a time.
Either one is doing the calculations in float, double or long double,
but not both piFloat and piDouble at the same time.  So other suggestions
made are not sufficiently useful here to justify their complexity.

8  The NTL program to calculate the constants is simpler, as it the
verification.

Please tell me if you agree that I should alter my generation program
to produce a file of many #define constants.

Please give me your votes for the sub-set of doubles, pi, sqrt2 ...?

Thanks

Paul

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
mailto: pbristow_at_[hidden]