Re: e_pow.c bug

[Andrew Haley <aph at redhat dot com>]

Mark Wielaard writes:
 > 
 > On Mon, 2004-04-12 at 18:39, Steve Moshier wrote:
 > > On Mon, 12 Apr 2004, Bryce McKinlay wrote:
 > > 
 > > > Interesting. It looks like our StrictMath.java, which is a port of the C
 > > > code, also suffers from this problem. As does Sun's JRE as of 1.5-beta,
 > > > from looking at the following test case. Any idea if this issue has been
 > > > reported to Sun?
 > > 
 > > To my knowledge, Sun Microsystems has never lifted a finger to maintain
 > > or support fdlibm.  They specifically refused to address other fdlibm
 > > bugs that I showed them years ago, when the package was first released.
 > > But since you brought it up, I will write to one of the people who were
 > > involved with the development.
 > 
 > I looked into this last week for GNU Classpath and the spec actually
 > says we need to have the exact same bugs as one specific fdlibm
 > release... Hmmm mail.gnu.org is down, so let me quote:
 >         
 >         See the spec for java.lang.Math and java.lang.StrictMath:
 >         "The Java math library is defined with respect to the version of
 >         fdlibm dated January 4, 1995. Where fdlibm provides more than
 >         one definition for a function (such as acos), use the "IEEE 754
 >         core function" version (residing in a file whose name begins
 >         with the letter e)."

AFAIK that's obsolete: the spec for java.lang.Math is now written in
terms of accuracy.  "Accuracy of the floating-point Math methods is
measured in terms of ulps, units in the last place. For a given
floating-point format, an ulp of a specific real number value is the
difference between the two floating-point values closest to that
numerical value."  It's only StrictMath where we have to keep to the
One True Math Package.

 >         
 >         For us the "upstream" for these functions is actually libgcj
 >         since they test against a lot more platforms then we do at the
 >         moment. But they haven't actually been applying patches to it
 >         for years. Which isn't surprising seen the fact that the spec is
 >         so specific about a particular version of fdlibm.

We haven't applied patches because they don't come up very often.

I'm assuming that's because fdlibm is a good package...

Andrew.