Re: [boost] Boost.MathConstants: Review

From: Matt Austern (austern_at_[hidden])
Date: 2001-04-20 12:37:58

"Paul A. Bristow" wrote:
 
> Surely we have to assume that the compiler will (or at least should) convert
> this back into the same binary representation?
> 
> (My experience so far with these 36 or more decimal digits is that it does).

There are very few guarantees about floating-point radix conversion in
the C or C++ standard.  I'm not saying there's anything very wrong with
providing a high-precision decimal fraction, but if you want exact 
control over the binary represenation there's really no substitute for
providing the exact binary fraction.  This is a really picky point,
but it's the sort of thing that a very picky numerical analyst will
worry about.  This is the sort of reason that hardware vendors
customize math libraries.

I'm not saying you should worry about this, mind you.  I'm just saying
the interface should be designed such that someone else can worry 
about it, if they feel it's necessary. 
 
>  > 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;
> 
> Can you give more details/references please.
> 
> > and (b) takes constant space.
> 
> What does constant space mean here please?

I'm working at home, and most of my references are at work, so I'll
just give the vague answer "see Knuth".  It's in volume 2.  He mostly
discusses integer radix conversion, but there's a little bit on 
floating-point radix conversion.

The reason I say "constant space" is that if you use arbitrary-
precision integer arithmetic, you can do optimal floating-point 
radix conversion.  (That is, given a floating-point expansion 
in one base, you can find the closest expansion in another 
base.) What's been proven is that you can't quite do it with N-bit 
integer arithmetic, no matter how large N is.

To some extent this is a picky point too.  Once you've decided
what error you're willing to tolerate (1 ulp, say), then you can
use finite-precision arithmetic.

                        --Matt