![]() |
|
Message-ID: <20190808181158.GG22009@port70.net> 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.