Re: glibc 2.2: math test failures

[Michael Deutschmann]

On 14 Dec 2000, you wrote:
> For a guaranteed maximum error, we would need to either proved the
> correctness of our algorithms (some ia64 developers at intel actually
> did this with the help of an automatic theorem prover!) or evaluate a
> function over a wide range to check our guarantee.  We can't do both
> at the moment and nobody volunteered to help here.

I know that.  (Actually, I don't think you could use a theorem prover 
since the FPU is a black box to you, and not all are the same, as the 
test failures show.)

I meant `guarantee' more in the commercial sense, where the person does
not actually -know- the promise can't be broken, but has pledged to take
responsibility if it is.  Of course, since glibc is free software, there
is no real-life legal liability (we hope), but I think there is still an
analogy.

I want to know the line in the sand -- the level of ULP that, when
reproducibly shown, will cause you to fix the library (at possible severe
performance cost), rather than just adjust your "Known Errors" page.

So if I was writing numeric software, I'd know not to promise my users
more than a certain level of accuracy.  If my users do report accuracy
errors, then (assuming no errors on my part) I could trace it back to a
new problem case and report it to you, and know that eventually my
program will work correctly under the next glibc release.  Just like I'd
deal with any other glibc error.

>  > I would think the ANSI/ISO standards should give some maximal error don't
>  > they -- to stop a pathological implementor from approximating cos() with
>  > a constant function....  You should comment on that, for those trying to
>  > write portable code.
> No, they don't give any.

Ouch.

---- Michael Deutschmann <address@hidden>