Re: Math Functions: Basic building blocks...

From: Eric Ford (eford_at_[hidden])
Date: 2001-09-28 20:08:20

> In the "3.0" version of the gcc ANSI C++ library (an "in progress"
> version ships with the gcc-2.96 suite that ships with Redhat 7.1),
if
> you take a look in <cmath>, you'll find all the overload prototypes,
but
> they are commented out with a   #if 0   as there don't appear to
(yet)
> be implementations of these functions.  This same library, however,
DOES
> have implementations of the "suffix functions" from C99.  (It gets
> wierder on the x86 ... the implementations of all three functions,
sinf,
> sin, sinl for example, are identical assembly code in glibc ... not
a
> bit of difference that I could detect, meaning, I think, that the
> assembly generated from these templates will be doing casting on the
too
> and from the fpu, even with the choice of the correct template :-(

Yeah, I noticed the #if 0, but didn't understand their purpose.  I
didn't bother to compare the assembly of the suffix functions, that's
weird.  Could it be that the FPU does it's calculations to a precision
that's more accurate than necessary for double?  Even good enough for
long doubles?  I seem to remember reading that the functions in cmath
typically had errors much greater than the type's epsilon.  But it
seems that gcc's sqrtf, sqrt, and sqrtl do give different answers, and
the long double value is consistant with A&S.  Hopefully, such time
saving measures are no longer necessary with modern CPUs.

> I agree on both counts, unfortunately.  The right (interim)
> implementation workaround is straightforward, I think: create at
least
> three preprocessor flags
> 
> BOOST_HAS_STD_CMATH_OVERLOADS
> BOOST_HAS_C99_MATH
> BOOST_HAS_C99_MATH_OVERLOADS
> 
> (I'm not attached to the names).  The correct combinations should do
the
> "right thing", which is pretty obvious, I think.  I'm working on
> implementing this stuff on your design as I mentioned in a previous
> email.  I still think that I can have it done by Monday (although I
> don't guarantee that it will work  :-)

Evidently, we may need to have even more preprocessor flags (grrr). 
Fernando Cacciola is reporting that Borland has double and long double
versions, but not float versions.  He suggested a separate header that
defined the missing overloads.  I'm not sure what the advantage of
using overloads rather than specializations is, though.  I like the
idea of specializations, since they won't cause possibly unexpected
implicit conversions.  What about having non-standard compilers use 
different versions of the macro definitions?  I don't think you can
include an #ifdef inside a multi-line #define, so we'll probably have
to have several macros for each combinations of preprocessor flags. 
Unless someone knows of a better way.

E