Random number question?

[Paul Panks]

How does HLA's random number generator differ from traditional BASIC's version? I've long based much of my adventure gaming on random numbers, especially during player/monster fighting. Does seeding a number truly make it random, or only quasi-random?

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,

Paul Panks
[email protected]

[Michael Mattias]

Series of random numbers <> series of unique numbers.

Random means random, meaning "might repeat"

[Ian Cairns]

The numbers provided by a random number generator are not truly random, but that doesn't necessarily affect a short-term number series.
If you are only doing a heads/tails choice, it shouldn't matter. If you are doing a series of choices, like shuffling a deck, then create an array, randomize the array and run through the array with a pointer to pick up the next number in the series.
If you want to avoid having the same number twice in a row, then pre-scan the array and delete or replace duplicates.
It seems to me (not thoroughly investigated) that the randomness of a numerical sequence deteriorates over time, so I like to re-seed the random number generator after about 50 iterations. I would suggest to do this by adding a number to the original seed number rather than by using "RANDOMIZE" or "RANDOMIZE TIMER" since due to the speed of the compiled program, we might not have advanced to the next seed number and would just repeat the previous series.

regards,

------------------
ian[dot][email protected]

[Bob Zale]

In PowerBASIC, "randomness" does not deteriorate until about 2^32 iterations. Much larger than 50. {smile}

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

Regards,

Bob Zale
PowerBASIC Inc.


------------------

[Fred Katzel]

Hi

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



------------------

[David J Venable]

any rng that doesn't get input from some external source will,
of course, be pseudo-random (not really random). most PRNG's in
compilers are linear congruential generators (LCG) which take the
form of:

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

as far as randomness goes, LCG's are not very random at all. bob
referred to the randomness "deteorating" but most LCD's will just
begin to repeat after Y digits (depends on the values of a, b
and M) (Y is usually not as large as 2^32, so I'm kind of
curious as to what type of rng pb uses). additionally, there
are combined lcg's which use multiple LCG's in conjunction which
will increase the period. but it's still cryptographically
weak.

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.

the nice thing about the Blum Blum Shub generator is that it is
unpredictable in both directions so it's perfect for security
applications.

------------------