Re: glibc 2.2.4: More math errors (K6, DX4, and Linux emulator)

[Michael Deutschmann]

On 9 Oct 2001, you wrote:
> Michael Deutschmann <address@hidden> writes:
> 
> > So once again I have to ask you to widen the error tolerance, it seems.
> 
> No way.  If you insist on using obsolete technology it's your problem.
> It doesn't mean everybody should be punished by adding to possibility

But you adjusted for DX4 errors last time, and the K6 is more modern than
the DX4.  And while I can understand not accomodating the IIT 3C87 (which
I later learned was considered second-most-inaccurate 387 clone
available), at least you should support the emulator as a 
lowest-common-denominator.

Also, two of the emulator issues are not really their fault.  The sinh()
error occurs because the K6 and the emulator are _better_ than the Intel
chips.  And the cos() error is partly your fault, because your test has an
incorrect expected value.

> to miss real errors.

What is a "real error" in this context, anyway?

IMO it is irresponsible to expect less than 1 ULP (compared after rounding) 
for all values on any transcendental function anyway.  If the true answer 
is close to the rounding decision point, narrowing down the last bit 
could take a lot of space and time.  But if <= 1 ULP error is tolerable, 
then an efficent algorithm is designable, because you only need to verify 
that worst-case error is under 0.5 ULP before rounding.
 
You can choose test values that are not close to rounding decisions -- 
but that just -ensures- that your known-ULP page will be 
over-optimistic.  For practical applications, you can't assume the values 
you work on aren't close to the border point.

Also, as a possible compromise -- could you perhaps copy the present 
libm-test-ulps to "sysdeps/i586/fpu", then provide a weakened version in 
"sysdeps/i386/fpu".  That way, you get your error warnings on the modern 
systems, and we don't have to live with spurious check-failures on our 
old reliables.  It's also more honest, since your "Known Errors" page 
will then reflect the fact that the promised figures only apply to 
Pentium or better.  (but you'll still need to update sinh() in the 
586+ standard, as that failure occurs with -better- FPUs.)

Note that I'll understand if you don't weaken the 386 standard so far
that ALL known coprocessors pass -- so long as the emulator passes, then
people with crappy math chips have an alternative. 

(Speaking of chips -- that reminds me of a minor documentation problem.  A
lot of chips are not easy to assign to "i586, i686, i786" etc. based on
their names.  You could perhaps provide in your INSTALL file a key.)

---- Michael Deutschmann <address@hidden>