From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2000-07-07 16:05:32
"Paul A. Bristow" wrote:
> Is there any interest in some high accuracy constants for the boost libraries?
Yes, I need pi in my random number library. It already has a plea
for a "boost::mathconst" embedded in a comment.
Your suggested header file looks like it still needs some boost-ification.
boost seems to prefer all lower-case identifiers with underscores as
separators, so it's "half_pi" instead of "halfPi". Aliases (sqrtTwo
and rootTwo) should be avoided. The naming should be consistent
(gammaThird vs. thirdPi and sqrtE vs. eSqr). Probably define
an explicit naming policy so that others can add further constants
with a compatible naming.
Include guards should be applied to the header file.
Oh, and we need a test file, which would compare the constants
to on-the-fly FPU computed values with a certain accuracy.
You should upload your package to the boost "files" section
at www.egroups.com/files/boost in a new directory.
> typedef double real_type; // float or double or long double.
> // Changing this typedef automatically converts the constant to the
> // type, for example float 1.234F, double 1234. or long double 1.234L.
This is plain ugly. Use a template instead, that's exactly what they
were made for. Example:
static const double pi;
template<class T> const double mathconst<T>::pi = 3.14;
I think we need pi, e and the euler constant, but the rest can
be computed (with a possible loss of accuracy, of course).
Probably we should offer only a basic set of constants to gain
more experience before expanding things further.
If we ever consider physical constant, they should be in a different
> const real_type realMax = std::numeric_limits<real_type>::max();
> const real_type eps = std::numeric_limits<real_type>::epsilon();
This is completely redundant and should be avoided. That would also
do away with #include <limits> and makes the file self-contained.
> const real_type pi = (real_type) 3.141592653589793238462643383279502884197;
I think the compiler is allowed to parse 3.14..., store it as a "double"
internally and convert it to a "long double" afterwards (when
real_type == long double). This makes all the countless digits rather
useless. Thus, all constants should be given as "long double", e.g.
Please don't be disappointed by the above suggestions. I am looking
forward to seeing a re-worked header file.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk