> -----Original Message-----
> From: David N. Smith (IBM) [mailto:dnsmith at watson.ibm.com]
> Sent: May 18, 1999 3:18 PM
> To: swart at home.com
> Cc: Squeak List
> Subject: Re: Random Numbers
>
>
> Steve:
>
> It appears that your LavaLamp random number code does this:
>
> * Fills a buffer from the LavaLamp site with 512 64-bit values.
>
> * Each time a new random number is needed, take one of these values as a
> seed and generate a new random number using the existing Park-Miller
> generator.
>
> * When the buffer empties, get more data.
>
This is essentially correct, but the P-M generator method is overridden with
a simpler method that scales the random number between 0.0 and 1.0.

>
> However:
>
> * while the data fetched from the site may be random, it is only updated
> once per minute. If you draw at least 512 values in a minute, and many
> random number users do more than that, then you get a repeated sequence.
>
This is a good point. If your application requires more data, then it would
have to start with a larger data set. My intention was to use it for an
interactive game that would not exceed the buffer in that time period.

> * Why is the value, supposedly already truly random, run through the
> Park-Miller generator once? Are you sure that this doesn't have some
> damaging effect on the randomness of the result? Since the P-M generator
> produces 32-bit values, it would at least seem to waste half of the data
> you fetch.
>
I initially avoided the extra generator step, but I had problems scaling the
number to fall between 0.0 and 1.0. The LavaRandom class is not using the
standard generator, but one that is simplified to just scale the numbers. I
agree that 64 bit numbers is probably overkill. I originally tried to
interpret them as IEEE values from the random stream, but this approach was
too naive.

> * Have you tested this generator using the techniques in Knuth Volume 2
> (3rd ed)? If not, than how do you know what you have? The source
> values may
> be flawed, or the pass thru the P-M generator may damage the
> result, or who
> knows? If it hasn't been tested for randomness, then it might be doing
> anything.
>
My biggest concern is that the "scaling" I did damaged the randomness. The
thing I really like about the source data is that they are continually being
tested for randomness and there are a number of nifty animated graphs
showing time sequences of the random data. Other sites such as
www.random.org do not post tests of their data.

>
> (I can't run it since I live behind a firewall, use a Mac, and Squeak
> doesn't supports SOCKS. It may also be that I can't read, so feel free to
> point out where I've gone astray.)
>
It should be easy enough to download sample data and modify the code to work
with a file-based buffer. If you are interested let me know and I can
forward something to you.

>
>
> Note that Squeak floats are IEEE Doubles and do not hold 64 bits of data:
> there is an exponent field and a sign bit which take up 12 bits,
> leaving 52
> bits. Taking a value from the code you included:
>
> 9223372036854775807 asFloat
> 9.22337203685478e18
>
> 9.22337203685478e18 asInteger
> 9223372036854779904
>
> Note that the last digits are different when converted back to integer. In
> hex, you can see that the value has been rounded during
> conversion to float:
>
> 9223372036854775807 hex
> '16r7FFFFFFFFFFFFFFF'
>
> 9223372036854779904 hex
> '16r8000000000001000'
>
I guess this is one way that the scaling method could damage the randomness
of the data. I suppose we could toss out the extra 12 bits of information if
it does have any effect. Or maybe just go to 32 bit integers (which would
double the useful life of the stream).

>
> Just a random number nut,
>
> Dave
>

Thanks for the feedback.

Steve

>
> At 3:55 -0400 5/2/99, Steve Wart wrote:
> >I'll be the first to admit that this is a little weird, but I
> was thinking
> >about trying to generate random numbers for a dice game and
> thought, nobody
> >is going to want to trust a computer to generate their rolls; we need
> >something better.
> >
> >So I remembered this quirky site (http://lavarand.sgi.com) and
> thought about
> >building a *true* random number generator.
> >
> >Most people with any sense of elegant design will probably be put off by
> >what I have done, but it has some interesting attributes:
> >
> >1. The numbers are truly random
> >2. The seed is completely unpredictable and secure
> >3. It could be used for doing cryptography in Squeak, not just games
> >4. It's the first thing I ever wrote in Squeak
> >5. It's really simple
> >
> >The big drawback is that it depends on SGI's web site to be available, it
> >could be slow at times, and the parsing is not robust if they
> change their
> >site design.
> >
> >On the other hand, someone may have built a non-http interface
> by now, which
> >would mitigate the last problem (it would be a random number
> service on the
> >net not unlike the time servers that are out there).
> >
> >Steve
> >
> >Content-Type: application/octet-stream;
> >	name="LavaRandom.st"
> >Content-Disposition: attachment;
> >	filename="LavaRandom.st"
> >
> >Attachment converted: PPC9500:LavaRandom.st (????/----) (0000D12B)
>
> _______________________________
> David N. Smith
> IBM T J Watson Research Center
> Hawthorne, NY
> _______________________________
> Any opinions or recommendations
> herein are those of the author
> and not of his employer.
>