
Boost : 
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 20010423 12:26:55
I don't have time (and/or perhaps brain) to fully understand all of this
paper,
but I do conclude that having plenty of decimal digits
should, in practice, get within one least significant bit
for almost all the time, and remains the best we can
reasonably expect to do for portability,
if not necessarily the last bit in accuracy.
Since every practical downstream calculation is subject
to at least this uncertainty, I don't think we should
worry about it for math_constants. Anyone who IS worried should
probably be using a higher precision system like
Victor Shoup's NTL (a C++ program) which is used to produce these constants.
However, it does bring me back to another query raised before
which nobody answered. P J Plauger said he had been 'burnt' by
compilers which actually choked on too many decimal digits.
But I am concerned that we are setting our sights too low for
the higher precision proposed Itanium hardware floating point?
It would be doing it 'right first time' to push up to 40 decimal digits,
provided it didn't cause trouble for existing compilers.
(This will avoid having to revisit and recalculate in a few years time
when this hardware becomes a reality).
Does anyone have a compiler which chokes on
const double sqrt_2 = 1.4142135623730950488016887242096980785696718753769L;
Thanks
Paul
> Original Message
> From: Herve Bronnimann [mailto:herve_at_[hidden]]On Behalf Of
> Herve Bronnimann
> Sent: Friday, April 20, 2001 10:19 PM
> To: Matt Austern
> Cc: boost_at_[hidden]
> Subject: [boost] Re: Boost.MathConstants: Review
>
>
> >And in some cases you might not have to use any such tricks.
> >I'm thinking of something like this:
> >
> >union fp_constant {
> > unsigned int n;
> > float f;
> >};
> >
> >fp_constant internal_pi = { 0x40490fdb };
> >float pi = internal_pi.f;
> >
> >(Digression: why is this important? It's becuase when you
> >write something like "pi = 3.141592653589793238", you're
> >relying on your compiler's radix conversion routine. There
> >are no guarantees about how accurate the radix conversion is,
> >and it has been proven to be impossible to write a radix
> >conversion routine that (a) gives the best binary approximation
> >to an arbitrary decimal fraction; and (b) takes constant space.
> >If you know the exact binary representation for a platform,
> >and if you know a trick that will let you specify it, you
> >should.)
>
> While this is true, there are algorithms for determining the closest
> representable number at a given precision, and these don't necessarily
> have to be represented as unions, or exotic bittwiddling schemes Matt
> was referring to in his message. A simple native representation (binary
> for most computers, maybe decimal for some rarities) would suffice.
> Check out:
>
> William D Clinger. How to Read Floating Point Numbers Accurately. In
> Proceedings of the 1990 ACM Conference on Principles of Programming
> Languages, pages 92101.
>
> http://www.ccs.neu.edu/home/will/papers.html
>
> Given that anybody can compute a pretty close approximation of their
> constants if they need to, I guess the great interest of a
> MathConstant library could be to have the best possible constant for
> your computer. Not that you NEED to do this... but it's great if it's
> available. See recents messages by Ed and Matt about this.
>
> Side note: it doesn't solve the case of a user doing things like
> double two_pi = 2.0 * boost::mathconstants<double>::pi();
> So if you have a short program that generates those numbers (perhaps a
> C++ template metacode, although it's hard to imagine how to do THAT)
> it would be best if you include it in the distribution for users who
> care to be able to derive their own constants...
>
> Best,
> 
> Hervé
>
> To unsubscribe, send email to: <mailto:boostunsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk