Re: Random Number in PRG: example

[Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>]

Well, this is true, but also consider, you are limited by the range of
the seed value anyway.  If your seed variable is a 16 bit value, you only
have a possible combination of 65535 random number sequences.  If your
seed variable is 32 bit (which is most likely) you have quite a bit more
possible sequences, but you are still limited (4 billion or 4 trillion, 
I don't remember which).

If you use a time value, even, there are only so many seconds in a day.
Or even milliseconds.  So you are again limiting your possible random
sequences.

The problem is, you need to generate a random number to seed the random
number generator!  And, if you are trying to "hack" the random numbers,
if you can find a quantity of random numbers in a row you can determine
what the seed was, and generate them yourself to match.

If you are trying to generate a random number that you don't want anyone
to be able to "hack" the sequence of, you have a number of options.  I
would write a function for this to return a random number and do all the
tricky stuff inside:

1. Generate a random number and save the last number generated as the next
   seed.
2. Generate a different random number using the time (milliseconds if 
   possible) as a seed.
3. Generate a third random number using the job number as the seed.
4. Add these 3 random numbers together, and return the average.

Are there disadvantages to this system?  Yes.  The main one being the 
distribution of the random numbers will not be equal.  You will get more
of a bell curve.  Keeping the random numbers to their most significant places
as long as you can will help reduce this curve, but it will still be there.
But, it will be next to impossible to determine what the next random number
generated is going to be.  You have to find the seeds for all 3 random number
sequences.  Also, it will be next to impossible for sequences to start repeating
themselves.

There have been books written on random number generators, and the fact that it
is impossible to generate a truly random number using electronic means.  Using
mechanical means, it is relatively easy (roll the dice, flip a coin, pick a card
any card don't let me see it).

Regards,

Jim Langston

Me transmitte sursum, Caledoni!

"DeLong, Eric" wrote:
> 
> Hi Jim,
> 
> This idea occurred to me too, but again the problem is predictable usage.
> Under certain conditions, its possible for the same seed values to be
> recurring. That is, if:
> 1) the program always retrieves the same number of "random" values (lets say
> 100),
> 2) since the returned values are not truly "random", if you ever supply the
> same seed again, you will loop through the same sequence of values, and
> again store the last returned value, which itself duplicates a prior
> sequence of "random" numbers.
> 
> It's sort of a feedback loop, and all it takes is one recurrence of the seed
> to stick you in a loop. Now, is this really going to happen in the real
> world? Who knows, but I wouldn't want to make any bets on it. Personally,
> I'd rather look at some non-related value to act as seed. Scott's job
> number/microsecond combo are pretty random, and should generally produce
> good seed values....
> 
> With all that said, I haven't had any need for random numbers in any program
> for years. This is all very interesting to me, but I can't say that this is
> really that critical........
> 
> Eric DeLong
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---