-
Notifications
You must be signed in to change notification settings - Fork 17.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
math/rand: improve uniformity of rand.Float64,Float32
Replaced code that substituted 0 for rounded-up 1 with code to try again. This has minimal effect on the existing stream of random numbers, but restores uniformity. Fixes #12290. Change-Id: Ib68f0b0a4a173339bcd0274cc16509f7b0977de8 Reviewed-on: https://go-review.googlesource.com/17670 Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
- Loading branch information
Showing
1 changed file
with
11 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
38255cb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change does not really improve uniformity that much. Again, as there are more floating points near zero, the outcome will be skewed towards zero with probability 1/2^11.
The change suggests a confusion in the definition of uniformity. Hitting all floating point numbers with equal probability does not mean uniform, because of the over representation of the numbers close to zero. So the fix continues the same mistake, just make things on average a tiny bit slower, and will be useless for Quasi random number generators.
The positive outcome however is that now floating points number are hit with equal probability (which was not the case with f=0 code). But it's not uniform, and not good for Monte Carlo simulations
38255cb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a test that we could run that would demonstrate this non-uniformity? It ought to be pretty obvious in Float32.
Also: "Hitting all floating point numbers with equal probability"
I don't think we do that.
We hit 0 and 1 with p=1/2^63.
(please forgive off-by-ones below)
We hit 1-(1/2^53) with all the points between (1-(1/2^54))2^63 and (1-3(1/2^54))*2^63
I think that is 2^10 points from the Int63 distribution mapping to a single point near one in the Float64 distribution.