RE: [boost] Standard Constants?

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2000-07-07 15:36:47

I believe that Victor Shoup's NTL code is reliable from its
provenance, experience, correspondence, and that it agrees with other
sources like Knuth who gives a selection of 40 decimal digits,
and Plouffe - who has collected many constants with far
more decimal places than you can ever want (thousands!!)
(You can download and examine and use it yourself)

You can select the number of decimal places - default 300!

My aim was to produce values which are more accurate than
any compiler is likely to be able to handle.  40 seems about
right for all practical purposes, so that worries
about the least significant bits can be ignored.
The documentation discusses the rationale for this.

Any remaining differences are in the compiler and/or hardware,
which simplifies matters a lot.

(Physical constants, big G, speed of light etc are in a
quite different category I believe.  They are much less accurate,
never exact, but most useful of course.)

Paul

> -----Original Message-----
> From: Reid Sweatman [mailto:borderland_at_[hidden]]
> Sent: Friday, July 07, 2000 1:59 AM
> To: boost_at_[hidden]
> Subject: RE: [boost] Standard Constants?
>
> I kind of like this idea, since I'm always having to look up
> the occasional
> oddball constant, with the problem that most books that print
> such things
> don't give much precision.  I'm not familiar with the NTL,
> but would ask
> whether it verifiably gives the actually correct values out
> to the required
> precision (in my time I've seen a lot of numeric routines, including
> compiler library routines, that didn't give quite correct
> answers, usually
> because of choice of algorithm and constraints on convergence
> time...which
> means also that the problem of failed equality tests still
> exists for some
> compilers, because they--let alone the programmer--can
> introduce such error
> into *any* numeric calculation).
>
> I'd also like to see some requirements on how the
> least-significant digit
> was arrived at, since that can also affect the numeric
> accuracy of results
> and tests.  Rounding?  Floor?  Ceiling?  Truncation?  Maybe a traits
> solution.
>
> I'd also expand the list to include lots of other constants.
> For instance,
> constants from the various realms of physics and engineering.
>  For instance,
> Boltzmann's constant, or standard air density at sea level.
>
> But those caveats aside, as I said, I like this idea.  I'm
> not sure, though,
> how the Boost Big Brains (BBB's <g>) will take to it, since
> such constants
> aren't a part of a language standard, but of various problem
> domains.  I'd
> think that to work at all, there'd have to be a considerable effort to
> partition the constants with domain-specific namespaces.
> Again, not sure
> that belongs in Boost.  Sure would be useful, though.
>
> Reid Sweatman
> Software Engineer
>
> > -----Original Message-----
> > From: Paul A. Bristow [mailto:pbristow_at_[hidden]]
> > Sent: Thursday, July 06, 2000 4:06 AM
> > To: boost_at_[hidden]
> > Subject: [boost] Standard Constants?
> >
> >
> > Is there any interest in some high accuracy constants for the
> > boost libraries?
> >
> > For example the draft values below.
> >
> > Use of these should increase program portability
> > (no annoying and hard to trace discrepancies when moving
> > to a different floating-point type, compiler, processor or
> platform).
> >
> > No cost or performance penalty in using the right value,
> > but improving quality by getting it right 1st time.
> >
> > Saving some time and hassle in finding them from a wide variety
> > of sources.
> >
> > Single or sub-sets of constants may be useful too. Cut'n'paste?
> > Some constants like pi are very widely used, but others are
> > rather obscure.  Open to suggestions on packaging.
> >
> > The ones listed cover most statistics and numerical
> analysis requirements.
> >
> > Other constants could be added easily (calculated if necessary using
> > Victor Shoup's, NTL, www.shoup.net/ntl/ Numeric Template Library).
> >
> > There is some html documentation available, as well as some comments
> > shown below (which might well NOT be part of .hpp files).
> > Paul
> >
> > Dr Paul A. Bristow, hetp Chromatography
> > 4 Victoria Road, Wilmslow, Cheshire SK9 5HN   UK
> > Phone [phone] FAX & Voicemail [phone]
> > email mailto:pbristow_at_[hidden]
>	typedef std::istreambuf_iterator<char, std::istream::traits_type> _Iter;
        typedef std::time_get<char, _Iter> time_get_facet; // facet time_get.

        const time_get_facet& UKtime_get_fac = std::use_facet(UKDate,
(time_get_facet*)0); // UK time_get facet
>