RE: [boost] Boost.MathConstants: Review

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-04-23 10:08:50

I am still trying to finish Knuth Vol 1 !!!

I have assumed that the result you get by reading
a string of ample decimal digits (at least 2 'spares')
should be at worst 1 least significant bit 'wrong'.
(assuming the compiler does its stuff right).

And that this least significant bit can be found using
numeric_limits::epsilon for the type. (Is epsilon
the same as ulp?)

And that the interval (that some people need) can be
defined by adding and subtracting epsilon
to the compiler's 'best' value?

Is this right?  Or is it more complicated still?

Paul

> -----Original Message-----
> From: austern_at_[hidden] [mailto:austern_at_[hidden]]
> Sent: Friday, April 20, 2001 6:38 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost.MathConstants: Review
>
>
> "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
>
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>