Re: [boost] Boost.MathConstants: Review

From: Matt Austern (austern_at_[hidden])
Date: 2001-04-19 15:11:47

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