🚀 go-pugleaf

Oops.  Forgot to copy the newgroups...

-------- Original Message --------
Subject: Re: Can erand48 really generate a 1.0?
Date: Thu, 06 Mar 2003 23:36:51 -0500
From: Shing-Fat Fred Ma <fma@doe.carleton.ca>
To: Ronald Bruck <bruck@math.usc.edu>

Ronald Bruck wrote:

> > -------- Original Message --------
> > Subject: Can erand48 really generate a 1.0?
> > Date: Thu, 06 Mar 2003 20:34:43 -0500
> > From: Fred Ma <fma@doe.carleton.ca>
> > Organization: Bell Sympatico
> > Newsgroups: comp.unix.programmer, gnu.gcc.help
> >
> > Hello,
> >
> > I'm using gcc's erand48.  On solaris8, the man page header
> > says SunOS5.8, while on cygwin, it says NEWLIB.  Both
> > pages say that the range of random numbers is the
> > closed range [0.0,1.0].  However, "many people" have
> > said on various web pages that the values lie in the
> > range [0.0,1.0) i.e. doesn't include 1.0. This is kind of
> > important if you multiply the random number by SomeInt+1
> > and and take the floor().  In the former case, you have the
> > slight possibility of getting SomeInt+1, which is bad if
> > SomeInt represents the index of the final element in an array.
> >
> > So I wonder if anyone knows for sure whether the random
> > number spans the closed range, or semiopen (latter case).
> > I mean know for sure, because suspicions abound (I have
> > my own suspicions that the semiopen range is correct because
> > the integer counterparts in this family of random generators
> > always goes up to +/-( 2**31 - 1 ), whereas I suspect the
> > floating point versions just normalize the integer version by
> > 2**31.
> >
> > One could always write code to trap the case when erand48
> > returns 1.0, but that's an overhead that you pay for every
> > time you make a call to erand48.
>
> Looking at the source code, it looks like it returns "unsigned short
> xseed[3]" into 48 bits via
>
>   ldexp((double) xseed[0],-48) + ldexp((double) xseed[1],-32) +
>    ldexp((double) xseed[2], -16);
>
> which would imply that it CANNOT exactly equal one.
>
> This isn't the gcc version--I'm looking at the code from
>
>
> <http://www.ics.uci.edu/~eppstein/projects/pairs/Source/testbed/rand48/>
>
> --but I doubt there's much difference.

That's very cool.  Thanks.  Effectively, it's using a random collection
of bits to generate an integer in [0,2**48-1] and then moving the
decimal point (er...I mean binary point) all the way to the left.

Fred

--
Fred Ma, fma@doe.carleton.ca
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6