RE: [boost] Boost.MathConstants: Review

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-04-20 03:50:46

I'm a bit gob-smacked by this.

Naively, I had assumed that having ample decimal digits was enough
(empirical tests on output show that 2 more than numeric_limits::digits10
is needed to show a least significant binary bit).

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).

(Leaving aside funny numbers, for example near DBL_MAX, not normalised near
zero....)

 > 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?

Thanks

Paul

> -----Original Message-----
> From: austern_at_[hidden] [mailto:austern_at_[hidden]]
> Sent: Thursday, April 19, 2001 9:12 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost.MathConstants: Review
>
>
> David Abrahams wrote:
>
> > > If you find it reasonable to have macros, you can hide them
> > > away in that implementation file where they're out of sight.
> > >
> > > This strikes me as a cleaner solution, and I think you'd be
> > > hard pressed to find a platform where it made a noticable
> > > difference in performance.
> >
> > Oh, maybe you just answered my question. But could you please
> go into a bit
> > more detail?
>
> I don't have any.  I don't know of any platforms where there
> would be a big speed difference here; there may be some.  But
> on the processors that I do know anything about, you have to
> touch memory to load a floating-point number into a register.
> In a case like this, I'd want to see timing tests before I
> believed that putting numerical values in headers was an
> important optimization.
>
> > > It also has the advantage that,
> > > on some platforms you could initialize the numerical value
> > > in tricky ways that wouldn't be appropriate in a header.
> > > (I'm thinking of awful stuff, like using unions to control
> > > the exact bitwise representation.)
> >
> > Mmm, delicious! I guess that having a carefully-generated exact
> > representation is probably more important than speed, here. But
> isn't there
> > an initialization-order issue in this case?
>
> There might be, depending on what kind of initialization we're
> talking about.  But since this is inherently platform specific
> anyway, you can always use platform-specific initialization
> tricks if you have to.
>
> 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.)
>
> (Oh, and don't take "0x40490fdb" seriously.  It happens to
> be more or less the right value for single precision little-
> endian ia32, but I haven't done the work to see if it's the
> best possible binary approximation to pi.)
>
> 			--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/
>
>
>