Comment 1:

Labels changed: added priority-later, go1.3, removed priority-triage.

Status changed to Accepted.

Comment 2 by jeff.allen:

Float32() is just float32(r.Float64())
This happens on play.golang.org on call number 7533753 to Float64, which returns
0.9999999777168924 (bits: 11111111101111111111111111111111110100000010010110111011011010)
http://play.golang.org/p/tGq_lqQIeL
Does seem like a better solution is to use Int32 to get mantissa bits and set the
exponent, then use http://golang.org/pkg/math/#Float32frombits on the bits.
This technique would also allow us to skip the floating point divide in Float64().

Comment 3 by arnehormann:

An alternative solution from my response in
https://groups.google.com/forum/#!topic/golang-nuts/94bTFkFUteE
(math.Float32frombits(0x3f800000 | (0x007fffff & uint32(VALUE))) - 1.0)
use IEEE 754 exponent for range [1,2)
combine with mantissa bits of VALUE
make float32
subtract 1
I initially proposed this for float64 in
https://golang.org/issue/4965
but Remy convinced me that the current approach for float64 is superior.
Maybe it's usefull for float32.

Comment 4:

I think the implementations should change to
float64(r.Int63n(1<<53)) / (1 << 53)
and
float32(r.Int31n(1<<24)) / (1 << 24)

Comment 5 by akalin:

+rsc, yeah that's roughly the solution I converged on.

Comment 6 by jeff.allen:

https://golang.org/cl/22730043

Comment 7:

Status changed to Started.

Comment 8:

Labels changed: added release-go1.3, removed go1.3.

Comment 9:

Labels changed: added repo-main.

Comment 10:

This issue was closed by revision 17dc712.

Status changed to Fixed.

Comment 11:

CL https://golang.org/cl/95460049 mentions this issue.

Comment 12:

This issue was closed by revision 5aca051.