Re: Boost.MathConstants: Review

From: Ed Brey (brey_at_[hidden])
Date: 2001-04-20 12:39:53

My question was referring to the portable code that would work on any 
conforming platform.  You need such code as a starting point, and it 
doesn't have any need for the constants to be in a separate file; 
rather there are disadvantages to doing so.

Platform-specific code to tweak out the best bits for the platform is 
fine, too.  It can be added to the generated file.  Since math 
constants don't tend to change (the earth would shake from teachers 
and theorists rolling over in their graves), this is a case where 
hand editing a generated file is perfectly acceptable.  What you'd 
end up with would be something like this:

namespace boost {
 namespace math {
  template<typename T>
  struct constants {
   #ifdef PLATFORM1
    static T pi() {long double l _asm {do_magic(l)}; return T(l);}
   #else
    static T pi() {return T(3.14...L);}
   #endif
  };
 } // namespace math
} // namespace boost

Of course, this probably isn't the right magic.  You might need to 
specialize on type or whatever, but in any case, it doesn't affect 
the baseline, portable version.

As far as release schedule and reviews go, I'd be perfectly happy to 
see a portable-only version released, followed up by future super-
tweaked versions as they are completed.  The tweaked versions are 
likely to be much more difficult, and there is no reason to hold up 
the library as a whole for them.

Ed

--- In boost_at_y..., Matt Austern <austern_at_r...> wrote:
> Ed Brey wrote:
>  
> > The part I'm not understanding is what value is there to _not_ 
having
> > the constants in the header, given that a header with built-in 
values
> > can be easily generated?
> 
> I should start with my prejudice: I think that the interface is far
> more important than the implementation.  My assumption is that in
> cases like this it is impossible to write good code portably.
> If the interface is well done, and if it is standardized or widely 
> adopted, then individual vendors will each rewrite it for their own 
> platform.  I think it's very important to have an interface that 
> allows vendors to use whatever tricks are necessary.
> 
> So: if your goal is to do the best possible job for one specific
> platform, it is *not* true that a header with built-in values can
> easily be generated.  You can generate a header that contains (say)
> a decimal expansion of pi, but that's not what you really want.  You
> want a constant that contains a binary expansion of pi for a 
particular
> floating-point representation.  You're unlikely to get the best 
> possible binary approximation of pi if you write something like
>   const double pi = 3.141592653589793;
> (no matter how many decimal digits you use).
> 
> If you want the best possible approximation of pi that will fit in
> a double on a specific processor, you'll need to play tricks.  
Maybe 
> your processor has a special floating point instruction that will 
> load pi into a floating-point register, or maybe your friendly 
local 
> numerical analyst can tell you what the best 64-bit binary 
> approximation is, and you can twiddle bits by hand.  Either way, 
> it's probably not something you can easily put in a header.
> 
> With portable code, of course, you can't do anything better than a
> bunch of decimal expansions.  That's a reasonable fallback, and 
> it's probably all that's necessary for version 1.0.  But even
> version 1.0 shouild be a framework that makes it possible to plug
> in platform-specific code.
> 
> 			--Matt