posted June 21, 2004 02:07 AM            

Let's say I have a number between 1 and 35. What guarantee do I have that the computer won't habitually (or accidentally) pick the same range of numbers twice? Or the same individual number twice?

To find out, I wrote a simple QBasic program below:

1 CLEAR
5 CLS : PRINT "Random Number test"
10 FOR x = 1 TO 10
20 RANDOMIZE TIMER
30 i = INT(RND * 35) + 1
40 PRINT i
45 NEXT x

The program was run three separate times, with the following results:

Test #1
Random Number test
27
25
17
31
24
18
27
34
23
22

Test #2
Random Number test
32
29
21
35
29
22
32
4
27
27

Test #3
Random Number test
21
18
10
24
17
11
21
28
16
16

Ah oh...the last two tests repeated the last two sets of numbers not once but TWICE! That's not good!

Now for the same program in HLA:

program random;
#include ("console.hhf");
#include ("stdlib.hhf");
#include ("math.hhf");
static
i:int32:=0;
x:int32:=0;
begin random;
console.cls();
stdout.put("Random number test",nl);
start:
add(1,x);
rand.randomize();
rand.urange(1,35); // pick a random number, 1 through 35
mov(eax,i); // move it into i variable
mov(i,eax); // set i to eax value
stdout.put(i,nl);
if(x<10) then
jmp start;
endif;
end random;

The HLA version gives the following 3 results:

Test #1
Random number test
29
24
11
19
22
8
27
33
27
28

Test #2
Random number test
19
4
32
30
23
34
24
20
20
30

Test #3
Random number test
35
26
29
17
26
18
33
29
19
1

Some repeats, but not as bad as before.

Is there a way to truly limit the number of repeats during a set of random number generation? I can foresee a lot of random numbers in my own mind, but they have to be truly, truly random for the random number generator to be doing a good job.

Any ideas as to why both sets of random number generators seem different in functionality?

Sincerely,

posted June 21, 2004 08:44 AM            

Random means random, meaning "might repeat"

posted June 21, 2004 12:00 PM            

regards,

posted June 21, 2004 03:03 PM            

In fact, excessive use of RANDOMIZE (or any other changes) will cause deterioration.

Regards,

Bob Zale
PowerBASIC Inc.

posted July 02, 2004 06:46 PM            

I developed the following random number generator back in the '70s to use in developing
question for my engineering students. The statements maked with a '*' before them are all
the random number generator consist of, the rest of the statements are to give a visual
picture of the distrubution of the number in sets of 0.1 from 0.0 to 1.0. The first number
on line 2 gives the k value you should use as part of a random number generator. The next
number gives the fluctualation. The lower this number is, the closer it is to an even
distrubution of random numbers. This program is also good for when you wish a skewed
distrubution of random numbers.

Fred Katzel.
'RANDOM NUMBER ANALYER
SCREEN 12: WINDOW (0, 0)-(639, 479)
FOR k = 2 TO 8 STEP .05
FOR i = 1 TO 10: c(i) = 0: NEXT
f = 0
*a = RND(1) 'Equivalent to RANDOMIZE
c(0) = 0
FOR j = 1 TO 1000
*a = a * k
*IF a > 1 THEN
*b = INT(a)
*a = a - b
END IF
IF a <= .1 THEN c(1) = c(1) + 1
IF a <= .2 and a > .1 THEN c(2) = c(2) + 1
IF a <= .3 and a > .2 THEN c(3) = c(3) + 1
IF a <= .4 and a > .3 THEN c(4) = c(4) + 1
IF a <= .5 and a > .4 THEN c(5) = c(5) + 1
IF a <= .6 and a > .5 THEN c(6) = c(6) + 1
IF a <= .7 and a > .6 THEN c(7) = c(7) + 1
IF a <= .8 and a > .7 THEN c(8) = c(8) + 1
IF a <= .9 and a > .8 THEN c(9) = c(9) + 1
IF a > .9 THEN c(10) = c(10) + 1
NEXT
FOR i = 1 TO 9
f = f + ABS(c(i) - c(i + 1))
NEXT
CLS
LOCATE 2, 35: ROUND(k, 2); f
LOCATE 14, 15: FOR n = 1 to 9: PRINT c(n); SPC(1): NEXT: PRINT PRINT c(10)
LINE (104, 440) - (104, 40): LINE - (620, 40)
FOR i = 0 TO 200 STEP 40: LOCATE (240 - i) / 8 - 2, 8: PRINT i: NEXT
FOR i = 0 TO 9: LOCATE 29, i * 6 + 12: PRINT i / 10
LINE (104 + i * 48, 40) - (104 + (i + 1) * 48, c(i + 1) * 2 + 40), 14, B
NEXT
LINE (104, 240) - (600, 240), 14
LOCATE 29, 74: PRINT "1"
INPUT " Continue (y/n)"; a$
IF a$ = "n" THEN END
NEXT
END

posted July 21, 2004 06:36 PM            

   X[n] = a * X[n-1] + b mod M

for those of you concerned with security LCG's are *not* the way
to go. LCG's are easily predictable, and linear feedback shift
registers (LFSR) are pretty bad too (unless designed correctly
which is a pretty difficult feat). there are several PRNG's
that are cryptographically secure, such as Blum Blum Shub which
is essentially:

seeding:
   X[0] = x^2 mod n
where x is relatively prime to n.
generator:
   X[n] = X[n-1]^2 mod n
where n is the product of 2 large primes which are congruent
to 3 mod 4.