Hi DAVID.

01-Nov-02 07:58:44, DAVID WILLIAMS wrote to JASEN BETTS


->> if you want more-random numbers couunt quicly while waiting for a
->> keypress
 DW>
 DW> I wonder how random that would be. Suppose you wrote:
 DW>
 DW> N& = 0
 DW> DO
 DW>   N& = N& + 1
 DW>   K$ = INKEY$
 DW> LOOP UNTIL K$ > ""
 DW> R% = N& MOD 10
 DW>
 DW> (I used K$ so the same keypress would be available for the program to
 DW> use later, if it's needed.)

it'll be more random if you put

   while inkey$  "":wend

before the DO to clear the keyboard buffer.

 DW> R% would be an integer between 0 and 9, and its value would depend on
 DW> how long the user waited before pressing a key. But how
"random" would
 DW> it be? It would depend on the user's habits.

on a even a slow machine that loop can execute many thousand times per second
my 100Mhz 486 for example counts more than 20000 times per second running that
loop in QBasic, it's probably be faster in QB, and faster still in assembler
(actually in assembler you could read the 1.17Mhz counters in the timer
chip or the CPU's cycle counter (where available) for a really fast count
and a more-random result :)

IMO unless the user has a reaction that's consistent to the sub millisecond
level it'd be random enough.

giving the user something to read before pressing the key, or asking them to
press a different key each time will increase the randomness too, because
ten it becomes a combination of reaction and congnition time.

hmm, the counter counts over 250 times faster than the screen refresh,
even if the user responds immeiately upon seeing the prompt there's
still a random component due to the position of the scan when the the
prompt was sent to the video ram.

on a single-tasking system you could hook the keyboard interrupt and probe
the timer chip whenever there's a keyboard event (keypress/keyup) and just
XOR the result with the seed used by RND... (or the seeed used by a better
random number generator)

I think linux does something like that to produce /dev/random

 -=> Bye <=-

---