TechTalkz.com Logo Ask the Experts!

Go Back   TechTalkz.com Technology & Computer Troubleshooting Forums > Tech Support Archives > Apple

Random Number Question

Apple

 
 
Thread Tools Display Modes
Unread 06-05-2008, 01:25 AM   #1
Bryan Parkoff
Guest
 
Posts: n/a
Random Number Question

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?

--

Yours Truly,
Bryan Parkoff



Sponsored Links
 
Unread 06-05-2008, 04:18 AM   #2
Michael Black
Guest
 
Posts: n/a
Re: Random Number Question



On Mon, 5 May 2008, 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 it's just counting until a keypress, that's your randomness. One of
the odd things about random is that it is indeed random. There's no
pattern to it. Just because you may get similar numbers in a row doesn't
mean it's not random.

One method often used is to sample some random source, like white noise.
The white noise is random, the sampling is clocked at a regular period.

That keyboard method, assuming I'm reading you right, is the reverse,
the source is a clock that's always counting, but when you press keys
is a fairly random thing and that gives the randomness.

The two methods are basically the same thing.

But since a white noise source isn't something you normally have on
hand, a lot of times equipment will have a pseudo-random output. That's
done by clocking a shift register and having feedback at the right points.
But unlike the previous methods, it is merely pseudo-random. Start it
up, and the output will always be the same as the last time it was
started. Make the shift register long enough, and it will take a long
time before the pattern repeats, and thus it often is "random enough".


Michael


 
Unread 06-05-2008, 10:18 AM   #3
Michael J. Mahon
Guest
 
Posts: n/a
Re: Random Number Question

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."
 
Unread 06-05-2008, 03:29 PM   #4
Bryan Parkoff
Guest
 
Posts: n/a
Re: Random Number Question

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


 
Unread 06-05-2008, 05:25 PM   #5
nem
Guest
 
Posts: n/a
Re: Random Number Question

Michael Black <et472@ncf.ca> wrote in news:

> But since a white noise source isn't something you normally have on
> hand


I know on the C64 you could use the SID chip to get true random numbers,
however Commodore BASIC generates pseudo-random numbers exactly like
Applesoft BASIC.
 
Unread 06-05-2008, 06:31 PM   #6
Michael Black
Guest
 
Posts: n/a
Re: Random Number Question

On Tue, 6 May 2008, nem wrote:

> Michael Black <et472@ncf.ca> wrote in news:
>
>> But since a white noise source isn't something you normally have on
>> hand

>
> I know on the C64 you could use the SID chip to get true random numbers,
> however Commodore BASIC generates pseudo-random numbers exactly like
> Applesoft BASIC.
>

If I'm remembering properly, the white noise source in the SID was
actually generated by a long shift register configured to generate
a pseudo-random sequence.

It was generally easier to generate "random" that way than put some
current through a diode and amplify the results, despite the pseudo
random shift register being "larger". But in IC design, sometimes the
most direct method is not the easiest way.

I'm not certain about the SID, but I do know other sound generator
ICs like the General Instrument one did use a shift register.

Of course, even given a white noise source, you'd have to still
have hardware to convert to some digital form. Hence it is usually
easier to do a pseudo random number in software.

Michael

 
Unread 06-05-2008, 07:30 PM   #7
Michael J. Mahon
Guest
 
Posts: n/a
Re: Random Number Question

Michael Black wrote:
> On Tue, 6 May 2008, nem wrote:
>
>> Michael Black <et472@ncf.ca> wrote in news:
>>
>>> But since a white noise source isn't something you normally have on
>>> hand

>>
>>
>> I know on the C64 you could use the SID chip to get true random numbers,
>> however Commodore BASIC generates pseudo-random numbers exactly like
>> Applesoft BASIC.
>>

> If I'm remembering properly, the white noise source in the SID was
> actually generated by a long shift register configured to generate
> a pseudo-random sequence.
>
> It was generally easier to generate "random" that way than put some
> current through a diode and amplify the results, despite the pseudo
> random shift register being "larger". But in IC design, sometimes the
> most direct method is not the easiest way.
>
> I'm not certain about the SID, but I do know other sound generator
> ICs like the General Instrument one did use a shift register.
>
> Of course, even given a white noise source, you'd have to still
> have hardware to convert to some digital form. Hence it is usually
> easier to do a pseudo random number in software.


And sampling a real noise source, like an amplified diode junction,
is a *real* random number.

Any algorithmically produced number is, at best, pseudo-random, meaning
that the sequence is completely deterministic but can pass most tests
for randomness.

John von Neumann famously joked, "Anyone who considers arithmetical
methods of producing random digits is, of course, in a state of sin."
;-)

-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."
 
Unread 06-05-2008, 07:30 PM   #8
Michael J. Mahon
Guest
 
Posts: n/a
Re: Random Number Question

Bryan Parkoff 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?


Sure--it's Microsoft code, it's in ROM, and it's irrelevant for most
uses of random numbers that are likely to be encountered in a BASIC
program. ;-)

Anyone serious about their pseudorandom number generator would provide
there own as, for example, a USR() function.

The issues in any "product recall" situation are: does it compromise
safety or does it significantly affect customer satisfaction? This bug,
like several other Applesoft bugs, do not meet the test. In fact, it
could be argued (and probably was ;-) that making changes to the ROM
would cause more problems than the bugs being fixed.

There are patched versions of the Applesoft ROM image out there, that
can be downloaded to the "language card" area if desired (of course,
that wouldn't play well with ProDOS...).

>>>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. The KEYIN random number generator only advances when waiting for
input, so if a program needs, say, 52 random numbers to shuffle a deck,
it would be impractical to have 200 user interactions to do that.

The usual approach is to have one or more interactions during the game
"startup", like "What's your name?" or "Would you like to read the
instructions?", to get one or more random numbers from KEYIN, then use
them to seed the RND generator so that each game uses a different
"deck".

Of course, any Monte Carlo algorithm will require a lot more random
numbers, so a PRNG is the only practical choice. (But then one might
wish for a better PRNG than the one in ROM.)

-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."
 
Unread 06-05-2008, 09:32 PM   #9
Paul Schlyter
Guest
 
Posts: n/a
Re: Random Number Question

In article <Xns9A967FB84441Fnem@216.196.97.142>, nem <nem@nospam> wrote:
>Michael Black <et472@ncf.ca> wrote in news:
>
>> But since a white noise source isn't something you normally have on
>> hand

>
>I know on the C64 you could use the SID chip to get true random numbers,
>however Commodore BASIC generates pseudo-random numbers exactly like
>Applesoft BASIC.


The Apple II monitor though has a source for true random numbers, although
with only 16 bits of entropy. The source is a 16-bit counter which is
incremented each time the monitor input routine polls the keyboard for
a keypress. So you just let your program ask the monitor for a keypress
and then read these 16 bits whenever there is a keypress - it's next to
impossible for the operator to control the value of this 16-bit counter.


--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stjarnhimlen dot se
WWW: http://stjarnhimlen.se/
 
Unread 06-05-2008, 09:32 PM   #10
Paul Schlyter
Guest
 
Posts: n/a
Re: Random Number Question

Sponsored Links
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/

Sponsored Links
 
 

Thread Tools
Display Modes



< Home - Windows Help - MS Office Help - Hardware Support >


New To Site? Need Help?

All times are GMT. The time now is 10:07 PM.


vBulletin, Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © 2005-2016, TechTalkz.com. All Rights Reserved - Privacy Policy
Valid XHTML 1.0 Transitional