Re: Use of C99 extra long double math functions after r236148

On Sun, Jul 08, 2012 at 08:13:21PM -0600, Warner Losh wrote:
> 
> On Jul 8, 2012, at 8:01 PM, Steve Kargl wrote:
> > Not to mention, I've seen way too many examples of 'x - y'
> > where cancellation of significant digits causes
> > problems.  Throw in rather poor estimates of function
> > results with real poor ULP and you have problems.
> 
> Are these problems significantly more or less than the
> usual #define I talked about before?  If the functions
> are so so, but much better than the double version, we
> have a significant win, even if things aren't perfect.

The answer is more complicated than the question asked.
On i386, the precision of long double and double is
53 bits.  On amd64, the precision of long double and
double are 64 and 53 bits.  On i386 and amd64, emax
and emin are 1024 and -1023 (could be off by one here)
for double and 16384 and -16383 for long double.  Now,
consider 2**emin <= exp(x) <= 2**emax for some set of
x (where I'm using the Fortran exponential operator **
instead of powl(2,{emin|emax}) because FreeBSD does not
have a powl()).  The sets for long double and double are
significantly different.

> If we weren't 13 past the publication date of the c99 standard,
> I'd be more sympathetic to the 'we need a high quality
> implementation' arguments.  However, we can't let the perfect
> be the enemy of the good here.  We claim c99 conformance, yet
> don't have these functions. 

AFAIK, neither gcc in base nor clang would be c99 complaint
even if all of the c99 math functions were available.

> After all, many of the original functions that were in our
> library had sub-optimial performance which bruce optimized
> over many years.  Why can't we use this model here?

I think the fear is that committing sub-optimal code would
take many many more years to fix.  AFAICT, bde longer commits
code to src/ (since the switch from cvs to svn), and he depends
on his code reviews to get things fixed.  With das and me
both having little to no time for FreeBSD, that leaves no one
to review/commit his suggested fixes (not that I would question
bde's opinion on a code change).

-- 
Steve