You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just noticed a paper recently, which reports that the implementation of drawing uniform floating point numbers in rand has some imperfections. Specifically, according to the paper rng.gen_range(-f64::MAX..=f64::MAX) will only generate negative floating point numbers.
After a quick search over the issues I didn't find any issued raised with regard to this paper. I just want to post it in case it's not mentioned here.
The text was updated successfully, but these errors were encountered:
Result: range overflow. Not really surprising given that range = f64::MAX - -f64::MAX is not representable.
Maybe there's more to take away from a proper reading, but usage of that range should draw alarm bells (it has no practical use and skirts the limits of the type).
A possible take-away from that paper is an alternative method of implementing Uniform for floats which does much of the arithmetic using integers, with better equidistributivity of samples and good performance. We should try implementing this, comparing to the current method (b - a)*x01 + a, possibly also comparing to #531.
dhardy
changed the title
Corner case when the range is too large for floats
Equidistant sampling of uniform FP values
Feb 20, 2023
I just noticed a paper recently, which reports that the implementation of drawing uniform floating point numbers in
rand
has some imperfections. Specifically, according to the paperrng.gen_range(-f64::MAX..=f64::MAX)
will only generate negative floating point numbers.After a quick search over the issues I didn't find any issued raised with regard to this paper. I just want to post it in case it's not mentioned here.
The text was updated successfully, but these errors were encountered: