[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 8 Aug 2019 20:11:58 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: new exp fails erfc in libc-test
* Dan Gohman <sunfish@...illa.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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
