Hi, I'm looking for a good random generator. Randomize and Random does not seem safe enougth. Can someone help?

Thanks.

Jordi.

(Please, use the list if you can answer, otherwise I won't receive it)

jordi wrote

Hi, I'm looking for a good random generator. Randomize and Random does not seem safe enougth. Can someone help?

The built-in random of 1.0.x is one of the best random generators you can find (although it's very slow). How is it not safe? The one in 1.9.x is a little worse, but it's three times faster (it's the Mersenne twister).

Jonas

jordi wrote

Hi, I'm looking for a good random generator. Randomize and Random does not seem safe enougth. Can someone help?

Hi Jordi, in what sense is it not safe enough? If you really need something "safe", only a hardware solution is probably good enough.

Best regards Preben

Sorry, there are a few things that I don't understand... and I am not so good in mathematics... and I can't explain it in English quite well.

The same seed generates the same random sequence... or not?
and why I can randomize as often as I want in the same program?
A loop like this generates the same numbers:
for loop := 1 to 100 do begin
  randomize;
  writeln (random (1000) +1);
end;
How can I re-seed in the same program?

Thanks:

(Please, use the list if you can answer, otherwise I won't receive it)

Yes.

and why I can randomize as often as I want in the same program?

Randomize is simply a procedure, the compiler does not know it is special or so.

You are using random/randomize wrong here. The correct way is

randomize;
for loop := 1 to 100 do begin
   writeln (random (1000) +1);
end;

Randomize initialises the random number generator based on the current system time. So if you call it multiple times in a short time period, you will get a similar (or even the same) randseed.

How can I re-seed in the same program?

randomize;
org_seed := randseed;
for loop := 1 to 100 do begin
   writeln (random (1000) +1);
end;
randseed := org_seed;
for loop := 1 to 100 do begin
   writeln (random (1000) +1);
end;

Now you will get twice the same 100 numbers. Do not call randomize more than once during a program run, it will only make the numbers you get "less random".

Jonas

I know that this is the correct way, mine was only one bad example to re-seed.

Randomize initialises the random number generator based on the current system time. So if you call it multiple times in a short time period, you will get a similar (or even the same) randseed.

With this, you have answered perfectly my question, to get a diferent sequence can I set randseed in a diferent way? for example:

Procedure set_new_random_seed;
  begin
    randseed := who knows yet...
  end;
For loop := 1 to 100 do begin
  set_new_random_seed;
  writeln (random (1000) +1);
end;

Thank you very much.

Jordi.

There are no different sequences. All pseudo-random generators have one circular sequence. The better the generator, the longer this sequence is.

You mean you want to write something like the "first" random number of 100 "different sequences"?

Thank you very much.

Note that you *cannot* save randseed in the middle of a sequence, and later restore it again to continue that particular sequence. The reason is that the random generator internally uses 3 random seeds (in 1.0.x) and several more in 1.1. If you change randseed, the random generator is reinitialised with this new seed, but the resulting sequence is different from what you would have gotten if you just continued previously (since only one of the randseeds is initialised by you, the rest is based on that one value).

This is different from TP/Delphi, which use only one randseed, so saving/restoring this one randseed is enough to save/restore the whole of the random generator. However, it still allows for perfectly reproducible random number sequences (if you set randseed to 5, print some random number and then set randseed again to 5, the following numbers will be the same as the first ones, because the newly calculated state will be the same as the first one).

Jonas

Jonas Maebe wrote

You mean you want to write something like the "first" random number of 100 "different sequences"?

Yes, I'd like something like this. A sequence of numbers very difficult (imposible) to re-do.

Thanks, for your help.You are very kind.

Jordi.

As long as you use pseudo-random number generators, you will not be able to generate sequences that are very hard to redo. They are per definition easy to reproduce, even if you mix 100 different sequences. If you want to encrypt something or authenticate, you have to look into encryption respectively authentication methods, and not at pseudo-random generators.

Jonas

Ok, thanks.

Jordi

My version of Linux includes a /dev/random. Is there any way to use this to get better random sequences. When I cat this device, it looks like it runs out of data pretty quickly, but I bet it would make a series of fairly random seeds...

-Alan

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Alan Mead wrote

My version of Linux includes a /dev/random. Is there any way to use this to get better random sequences. When I cat this device, it looks like it runs out of data pretty quickly, but I bet it would make a series of fairly random seeds...

/dev/random is very random, it's gets it's data from an "entropie pool" which is filled using the random times when hardware interrupts are triggered. Because this pool has a limited size and only a few hardware interrupts per second happen, this random generator runs quite fast out of data. There is also a "non"-blocking random device which uses a usual random generator when the entropie pool runs out of data, but I don't remember it's name.

This reply is vary long.

After I posted this, I looked into these devices. They were written by Theodore T'so of kerberos fame and, I have to imagine, intended to produce crypotgraphically-secure randomness. As you say, /dev/random produces data that should be close to truely random but in fits and not very much. The other device is /dev/urandom. Some people may also have a /dev/hwrandom which may, or may not, work. It sounds like Intel included a hardware RNG on some chips. There were several sites that described generating random numbers from sound card white noise. I also looked into hardware RNG's. It looked like these would be a (small) project and cost at least 80-140 USD.

Here is a comparison of the FPC 1.0.10 random number generator and the system devices:

irt]$ uname -a
Linux alan 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown ent]$ fpc -v
Free Pascal Compiler version 1.0.10 [2003/06/26] for i386 Copyright (c) 1993-2003 by Florian Klaempfl
Fatal: No source file name in command line
ent]$ ./ent fpcrandom.txt
Entropy = 7.982320 bits per byte.

Optimum compression would reduce the size
of this 10000 byte file by 0 percent.

Chi square distribution for 10000 samples is 244.81, and randomly would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bytes is 128.9561 (127.5 = random). Monte Carlo value for Pi is 3.142857143 (error 0.04 percent). Serial correlation coefficient is 0.005214 (totally uncorrelated = 0.0).
ent]$ ./ent urandom.txt
Entropy = 7.999914 bits per byte.

Optimum compression would reduce the size
of this 2252800 byte file by 0 percent.

Chi square distribution for 2252800 samples is 269.51, and randomly would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bytes is 127.5270 (127.5 = random). Monte Carlo value for Pi is 3.141578731 (error 0.00 percent). Serial correlation coefficient is -0.000061 (totally uncorrelated = 0.0).
ent]$ ./ent random.txt
Entropy = 7.892939 bits per byte.

Optimum compression would reduce the size
of this 1477 byte file by 1 percent.

Chi square distribution for 1477 samples is 212.05, and randomly would exceed this value 97.50 percent of the times.

Arithmetic mean value of data bytes is 127.6141 (127.5 = random). Monte Carlo value for Pi is 3.186991870 (error 1.45 percent). Serial correlation coefficient is 0.000579 (totally uncorrelated = 0.0).

I would discount the chi-square because it varys a lot when you repeat this experiment. Also, I think of it having a one-tailed distribution whereas the ent author interprets it as two-tailed. Also, note that the samples vary enormously in their size. I got the /dev/random and /dev/urandom samples by cat'ing the devices and redirecting into a file (and then breaking). So the /dev/urandom sample is quite large and the /dev/random sample is pretty small. For the FPC generator, I wrote a very simple program that generated 10,000 random bytes, cast these as chars, and wrote them to disk.

The compression forecast and Monte Carlo estimation of Pi strike me as the best indicators of how the RNG's operate relative to my needs. Way back, I used to plot this Pi test with the BGI unit and visually inspect it for patterns. By whichever method, clearly /dev/random wouldn't work well as a random number generator although it might provide good random seed values. Is the FPC RandSeed 16 of 32 bits? Either way, you could probably re-seed from /dev/random every 30 seconds. To use the device in a Pascal program, just open '/dev/random' or '/dev/urandom' as a text file and 'read(ran,ch)', given 'ch:char;'.

-Alan

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Alan Mead wrote

Is the FPC RandSeed 16 of 32 bits?

3 seeds of 32 bit each.

Jonas