New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bad accuracy of powf for integer exponent #211
Comments
Is it possible for you to try it in the latest release? The library just takes a couple of mins to download and build and try out. |
the last tar.gz available on https://openlibm.org/ is 0.4.1, this is the one I used |
I don't that website has been updated in quite a while. You can get the 0.7.0 tarball from the GitHub releases page: https://github.com/JuliaMath/openlibm/archive/v0.7.0.tar.gz. You could also do a |
We should update the website. Thanks for bringing to our notice. Most people just download straight from GitHub. |
Website updated. |
@zimmermann6 can you tell us what value % ./testf -a 0xd.65874p-4f 4.0f libm = 4.91470873e-01f, /* 0x3efba212 */ mpfr = 4.91470873e-01f, /* 0x3efba212 */ ulp = 0.09839 |
Steve, here is what I get (same with 0.7.0):
The expected value is 0x7.dd109p-4=0x1f74424p-2, which is the one I get with GNU libc. |
I confirm this fixes the example I gave, now we get the same result as glibc. However for x=0x1.ffffeep-1 and y=-0x1.000002p+27 openlibm powf(x,y) gives +Inf whereas the correct result is 0x1.d53532p+103: $ cat test_pow_openlibm.c int main() $ gcc -fno-builtin test_pow_openlibm.c -lm $ gcc -fno-builtin test_pow_openlibm.c /tmp/openlibm/libopenlibm.a Should I open a separate issue for that? |
Seems to be the same general issue so I think we can reopen this. |
Ah well - this is most likely then an issue in the freebsd msun. |
Interesting corner case x->1 and y >> 1. This patch, lacking any additional analysis, fixes the issue on FreeBSD.
|
I confirm this fixes the issue. Now the largest error I find with my program in a quick test is less than 1 ulp. |
Thanks, committed in FreeBSD here: freebsd/freebsd-src@93fc678 |
while doing some heuristic search for large errors (in ulps) of the single-precision powf function (with rounding to nearest) I noticed that for integer exponent we can get some quite bad accuracy.
One example is x=0xd.65874p-4f and y=4.0f, where I get an error of 1.9ulps with respect to the infinite precision result.
This is with OpenLibm 0.4.1 on x86_64 under Linux.
The text was updated successfully, but these errors were encountered: