Re: Random Number Question

["Bryan Parkoff" <nospam@nospam.com>]

>>     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,

    I am surprised that Applesoft BASIC does not simulate random number 
correctly.  Do you have idea why there is no bug fix?

>> 10 PRINT INT( RND( 10 ) * 10)
>> 20 GET A$
>> 30 GOTO 10

    If you remove "20 GET A$", the loop continues to print random number 
without accessing keyin routine.  Is this way how Applesoft BASIC has its 
own routine and do not use kegin routine?

Bryan Parkoff