Re: Random Number Question

["Michael J. Mahon" <mjmahon@aol.com>]

Bryan Parkoff wrote:
> Hello folks,
>
>     Do you know how random number work?  You use either Applesoft BASIC or 
> Integer BASIC.  You use the function like RND().  Take a look at my example 
> here.
>
> 10 PRINT INT( RND( 10 ) * 10)
> 20 GET A$
> 30 GOTO 10
>
>     Apple II has chosen the random number of the range from 0 to 9 and print 
> each random number to the screen.  How do Apple II know to guess random 
> number?  Take a look at monitor routine $FD1B.  $4E and $4F are the high 
> byte of random and low byte of random.  It waits for the key to be pressed 
> while random number continues to increment.  If key is pressed, random 
> number stops to increment before it is printed to the screen.  Repeat the 
> procedure to increment random number while it waits for a key.
>     Do you know the alternative implementation rather than keyin?  Do you 
> think to implement the clock to replace keyin?  The random number stops to 
> increment each one second while clock reads one second and another.  What do 
> you think?

If the KEYIN 16-bit counter is used, the result is actually random
(particularly in the low byte), since the counter is counting at over
50kHz and human response times (even when trying to be consistent) have
variances of several milliseconds, the sampled value of the low byte
is essentially random.  The effect is like a roulette wheel with 256 
"slots" that is spinning at 12,000 RPM being stopped by a keypress!

The high byte "turns over" in slightly more than a second, so if
a person is asked to read a prompt and respond, a situation in which
variances are likely to be on the order of a second, then even the
high byte of the counter is fairly random.

The Applesoft RND function, however, is a *pseudorandom* number
generator (and a defective one, at that), whose outputs will always
be an identical sequence of numbers.  The length of the sequence,
because of a design error, is rather short (a few tens of thousands of
numbers before approximate repeats occur).  The starting point in this
sequence is set by the "seed", which is set by a call with a negative
argument.  (Interestingly, another bug causes the low byte of the
cold-start seed to be ininitialized.)

Unlike Integer BASIC's RND, which returns a positive integer determined
by RND's argument, Applesoft ignores the value of any non-negative
argument, and always returns a floating point number greater than or
equal to zero and less than one.

There is a long history of pseudorandom and actual random number
generators, with some very interesting results.  If you're interested
in them, a Google search will turn up lots of fascinating reading.

If you are debugging a program, there are real advantages to having
a deterministic source of pseudorandom numbers.  If you wish to avoid
repeating the same sequence in game play, then the pseudorandom
generator can be seeded with a "real" random number from the KEYIN
counter as long as there is at least one (nondeterministic) human
interaction prior to each sampling.

There are also several better replacements for Applesoft's RND
function for demanding applications--though that may be an oxymoron.
;-)

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."