new exp fails erfc in libc-test

new exp fails erfc in libc-test

[Dan Gohman]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

As of the patch which introduced the new exp implementations:

http://git.musl-libc.org/cgit/musl/commit/?id=e16f7b3c02e17d0ace779a11f0d53a9c05fdd434

I am seeing a test failure in the erfc test in libc-test on at least x86-64
(erfc calls exp internally):

src/math/special/erfc.h:6: RN erfc(0x1.5db559fe5c0bap+0) want
0x1.b53cf571d328fp-5 got 0x1.b53cf571d328cp-5 ulperr -2.609 = -0x1.8p+1 +
0x1.900982p-2

Please let me know if there's any other information which would be useful.

Dan

[-- Attachment #2: Type: text/html, Size: 765 bytes --]

Re: new exp fails erfc in libc-test

[Rich Felker]

On Wed, Aug 07, 2019 at 05:47:54PM -0700, Dan Gohman wrote:
> As of the patch which introduced the new exp implementations:
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=e16f7b3c02e17d0ace779a11f0d53a9c05fdd434
> 
> I am seeing a test failure in the erfc test in libc-test on at least x86-64
> (erfc calls exp internally):
> 
> src/math/special/erfc.h:6: RN erfc(0x1.5db559fe5c0bap+0) want
> 0x1.b53cf571d328fp-5 got 0x1.b53cf571d328cp-5 ulperr -2.609 = -0x1.8p+1 +
> 0x1.900982p-2
> 
> Please let me know if there's any other information which would be useful.

I think errors on this order of magnitude are considered normal for
the transcendental functions. Is there something you're concerned will
break due to the difference in accuracy here, or are you asking if
it's potentially something you should be concerned about?

Rich

Re: new exp fails erfc in libc-test

[Dan Gohman]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Wed, Aug 7, 2019 at 6:46 PM Rich Felker <dalias@libc.org> wrote:

> I think errors on this order of magnitude are considered normal for
> the transcendental functions. Is there something you're concerned will
> break due to the difference in accuracy here, or are you asking if
> it's potentially something you should be concerned about?
>

I'm just reporting a nominal regression I observed. If the finding is the
test is too narrow, that's fine with me.

Dan

[-- Attachment #2: Type: text/html, Size: 811 bytes --]

Re: new exp fails erfc in libc-test

[Szabolcs Nagy]

* Dan Gohman <sunfish@mozilla.com> [2019-08-07 17:47:54 -0700]:
> As of the patch which introduced the new exp implementations:
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=e16f7b3c02e17d0ace779a11f0d53a9c05fdd434
> 
> I am seeing a test failure in the erfc test in libc-test on at least x86-64
> (erfc calls exp internally):
> 
> src/math/special/erfc.h:6: RN erfc(0x1.5db559fe5c0bap+0) want
> 0x1.b53cf571d328fp-5 got 0x1.b53cf571d328cp-5 ulperr -2.609 = -0x1.8p+1 +
> 0x1.900982p-2
> 
> Please let me know if there's any other information which would be useful.

erfc in this range returns

 exp(a)*exp(b)/x

which is

 R(R(R(exp(a)) * R(exp(b))) / x)

where R is the round to nearest operation.

each rounding may introduce about eps/2 relative
error so about 2eps error overall.

1 eps relative error translates to 1..2 ulp error,
so 4 ulp error bound in this case, but in practice
the actual worst case is likely closer to 3 ulp for
this expression.

this analysis assumes a correctly rounded exp
and exact a and b, so this algorithm cannot be
expected to have < 2.6ulp error, no matter what
exp is used.

so i guess i will just have to update the error
threshold in the erfc test.

btw the new exp algorithm happens to be correctly
rounded on the input that is used during that
test, while the old algorithm is off by one.