Why no rand.Uint64()?

2,652 views
Skip to first unread message

Aaron Jacobs

unread,
Oct 12, 2012, 7:21:33 AM10/12/12
to golan...@googlegroups.com
The math/rand package seems to be built around uniformly-distributed random
integers in [0, 2^63), with the fundamental building block being Source's
Int63() method. Even Rand has no Uint64() method.

I need random integers in [0, 2^64). I can of course use two calls to Uint32
to do what I need, so I'm more curious than anything: why use a signed int64
as the fundamental type? Why not uint64? I skimmed the code, but I couldn't
divine the answer.

Aaron

Russ Cox

unread,
Oct 16, 2012, 2:09:11 PM10/16/12
to Aaron Jacobs, golan...@googlegroups.com
The generator we're using only generates 63 bits worth of output.
You're right that we probably should have corrected that before the API freeze.
Oh well.

Russ

Aaron Jacobs

unread,
Oct 16, 2012, 8:31:00 PM10/16/12
to Russ Cox, golan...@googlegroups.com
On Wed, Oct 17, 2012 at 5:09 AM, Russ Cox <r...@golang.org> wrote:
> The generator we're using only generates 63 bits worth of output.
> You're right that we probably should have corrected that before the API freeze.
> Oh well.

Ah, well that makes sense. Is it worth filing a bug for 2.0, or whatever?

Aaron

Rob Pike

unread,
Oct 16, 2012, 8:57:59 PM10/16/12
to Aaron Jacobs, Russ Cox, golan...@googlegroups.com
Please do.

Aaron Jacobs

unread,
Oct 17, 2012, 12:09:55 AM10/17/12
to Rob Pike, Russ Cox, golan...@googlegroups.com
On Wed, Oct 17, 2012 at 11:57 AM, Rob Pike <r...@golang.org> wrote:
> Please do.

Done. Link for posterity:

http://code.google.com/p/go/issues/detail?id=4254

Michael Jones

unread,
Dec 4, 2012, 2:50:24 PM12/4/12
to TheoDeNot, golan...@googlegroups.com
There clearly should be.

On Tue, Dec 4, 2012 at 7:40 AM, TheoDeNot <timog...@gmail.com> wrote:
Just wondering if the link posted has been taken into consideration? Just find it weird that there hasn't been a reply yet.


On Thursday, 18 October 2012 00:01:56 UTC+2, Michael Hofmann wrote:
I've written an alternative implementation of rand.Source that also has an Uint64() method. Maybe you can use it:

Michael 

--
 
 



--
Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

Ian Lance Taylor

unread,
Dec 4, 2012, 2:54:08 PM12/4/12
to TheoDeNot, golan...@googlegroups.com
On Tue, Dec 4, 2012 at 7:40 AM, TheoDeNot <timog...@gmail.com> wrote:
> Just wondering if the link posted has been taken into consideration? Just
> find it weird that there hasn't been a reply yet.

It's not clear to me what change we can make today without breaking
the Go 1 guarantee. We can't add methods to the rand.Source
interface. I suppose we could add a rand.Uint64 function that tests
whether the Source has a Uint64 method, and calls that, otherwise
calls the Int63 method twice. Does that make sense? Is it
sufficiently useful?

Ian

> On Thursday, 18 October 2012 00:01:56 UTC+2, Michael Hofmann wrote:
>>
>> On Friday, October 12, 2012 1:21:50 PM UTC+2, Aaron Jacobs wrote:
>>>

TheoDeNot

unread,
Dec 6, 2012, 7:10:37 AM12/6/12
to golan...@googlegroups.com, TheoDeNot
Yeah it makes sense to leave things the way they are now. This will work fine for now right?

package main

import (
        "fmt"
        "math/rand"
        "time"
)

func main() {
        for a := 0; a < 10; a++ {

                rand.Seed(time.Now().UTC().
UnixNano())
                t := uint64(rand.Uint32())<<32 + uint64(rand.Uint32())
                fmt.Println(t, "\n")

        }
}
Reply all
Reply to author
Forward
Message has been deleted
0 new messages