Re: Random Number Question

[pausch@saaf.se (Paul Schlyter)]

In article <482071f7$0$4105$4c368faf@roadrunner.com>,
Bryan Parkoff <nospam@nospam.com> wrote:
>>>     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?

Yes - Applesoft has its own formula for pseudo random numbers.  Superficially
they appear like random numbers, but they're completely predictable once
you know the formula.

>Bryan Parkoff 




-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stjarnhimlen dot se
WWW:     http://stjarnhimlen.se/