-
Notifications
You must be signed in to change notification settings - Fork 0
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
cpp_double_fp_backend<4-byte float> division fails accuracy threshold #136
Comments
Hi Fahad (@sinandredemption) I am very glad to read your post and see the real dedicated effort to assess our precision at the bit-expected level.
Quick note here... If you are using GCC, then compile with |
Ummm... Just thinking out loud here, we could use traditional Briggs/Shoup for add/sub/mul. Maybe mix these with 1 round of Newton-Raphson for div/sqrt? Maybe a combination will give us the best compromise on speed/accuracy/precision? Cc: @cosurgi |
I should've mentioned it earlier: division fails 102 bits for The only difference is in terms of accuracy between the two implementations seems to be in mul, where David Bailey's implementation preserves one extra bit (104 bits vs 103 bits) at the cost of speed, presumably. |
Sorry Fahad (@sinandredemption) you had actually mentioned that. But I was not being a careful reader.
To me, that one is a real toss-up. In my experience, either of the choice of sets of these algorithms are still all several factors faster than our own Tough choice, but I'd go for the bit. I would encourage you to run some |
I agree with this. |
So in light of 1.82 I've fired up this effort again. I watched with great interest as an extreme value case was handled in Math, as i suspect this was hampering extreme values on I forgot a few details where we actually were, but i did just hammer out a specfun test locally. As it turns out now with the Math improvements for 1.82, the Cc: @sinandredemption and @jzmaddock and @mborland and @cosurgi So I'll try to re-orient to 1.82 and finally get |
P.S. Those failing |
TLDR: cpp_double_fp_backend<4-byte float> is expected to preserve 44 bits of accuracy based on it's epsilon value, but only preserves 43 bits.
Hello @ckormanyos @cosurgi
I ran a modification of a old test I wrote during the GSoC days to assess how many bits of accuracy are preserved while performing add/sub/mul/div operations by both the David Bailey's implementation and our Briggs/Shoup derived implementation. The only "special" thing about that test is the random values generated are log-normally distributed, which has helped me catch quite a few bugs in the past.
Based on the value of
my_value_eps()
, we expectcpp_double_fp_backend< 4-byte float >
to preserve 44 bits of accuracy, andcpp_double_fp_backend< 8-byte double >
to preserve 102 bits. Note that I could not run these tests for float128.After running a million rounds of each operation here are some observations:
cpp_double_fp_backend< 4-byte float >
, division preserves only 43 bits of accuracy (vs. 44 expected) for both the algorithms.cpp_double_fp_backend< 8-byte double >
Overall, it seems like the new algos are fast and reliable. However, as we have previously decided that my_value_eps() will reflect the accuracy of the type, this issue needs to be addressed. Possible ways forward include specializing
numeric_limits<>
forfloat
but want to hear your thoughts before that.The test I used is a somewhat of a kludge, but here is the link to it anyway.
The text was updated successfully, but these errors were encountered: