-
Notifications
You must be signed in to change notification settings - Fork 432
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
Implement HighPrecision01 distribution #372
Conversation
(The mean test is totally inadequate for checking high precision.)
So if I recall correctly we want to try implementing This is thus a good addition but doesn't have to be done before 0.5. |
Instead of testing the average, I think it makes more sense to fill a histogram. With a sufficient number of samples, it should be possible to distinguish the biased I think it might make sense to expose |
One caveat (from http://xoroshiro.di.unimi.it/) that should probably be addressed in the documentation:
|
Is there still interest in this? I wrote a generator a while back for values in the [0, 1) range using maximum precision here. What the algorithm effectively does is that it picks a random, but perfectly unbiased, point on the continuous line between 0 and 1. It then rounds that down to the nearest point that can be represented as a f32/f64. This means that all values in the [0, 1) range that can be represented by an f32/f64 can be returned by the algorithm. However not all values are equally likely since f32/f64 has many more values close to 0 than close to 1, and so likelyhood of rounding to a particular value close to 0 is smaller, than a particular value close to 1. Happy to adapt this to There's also code in the same file which uses the same approach to generate values between two arbitrary, finite, f32/f64. I.e. it picks an random unbiased point on the continuous line between the start and end and then rounds to the closest f32/f64 below the picked point. However it relies on the |
I should also mention that the code for high-precision sampling for an arbitrary range is quite slow. I mainly wrote it for funsies to see what it'd look like. However the code for high-precision sampling in [0, 1) has more reasonable performance. Though obviously slower than the |
IIRC this implementation works fine and has reasonable performance, but we were considering going with arbitrary ranges. On the other hand, if that's not easy to do it might not be a good option. We were planning on adding |
Cool, the existing implementation here does seem faster than the one I wrote, so I think we should go with this one. Happy to port the arbitrary-range full-precision implementation that I wrote if there's a interest? The current code is here. Would there be any perf goals in mind? |
FWIW, i benchmarked my full-precision-arbitrary-range implementation and it's about 50-100x slower than the low-precision version, which is similar to what's in It's not been perf optimized much, so I'm sure that can be lowered some. But it's pretty darn slow. |
I'm working on a more performant implementation here. Still doesn't work, so can't get perf numbers yet. |
The implementation over here is now working and benchmarked. It's looking about 6-9x slower than the current Uniform implementation which seems viable? I'm sure some more performance can be squeezed out as well. |
Good work. I think with that performance it is probably worth including this somehow, though obviously not as the default option. I guess we may also want a different implementation for high-precision I would say open a PR, but it probably makes sense to resolve #494 first. |
Closing in favor of #531 |
Why? As I understand this has better performance, but only works over |
Re-opening #320.