Issues with rand()

[Juhász P. <pet...@gm...>]

Dear gnuplot developers,

a recent thread[1] in the newsgroup made me play with the rand()
function, and I've found some issues with it:

1) rand() silently accepts string arguments:
gnuplot> print rand("foo")
0.222457440974512

While this is not particularly bad in itself, but it's not consistent
with the behavior of other numerical functions (which reject string
arguments), and it's undocumented. Its effect is the same as that of
rand(0) - which have misled the user in the thread[1], because he
thought that rand("time") sets the random seed to the current time.

2) It is possible to lock the PRNG into a state where the returned
numbers are not random at all:
gnuplot> print rand(0.5)
0.999999999450207
gnuplot> print rand(0)
0.999999999450207
gnuplot> print rand(0)
0.999999999450207
gnuplot> print rand(0)
0.999999999450207
gnuplot> print rand(0)
0.999999999450207

I'll refrain from linking to the relevant xkcd or Dilbert comics.

3) Consider the following plot:

set xrange [0:2**22]
set samples 1000
plot '+' u 1:(rand($1)) w l

The rand() function, when called with a nonzero argument, sets the seeds
based on the argument and returns the first pseudo-random number from
the sequence associated those seeds. As the plot shows, there is a
rather obvious dependence between rand's argument and the returned
number, in fact the dependence is linear if only the lower 21-or-so bits
of the argument are considered.

This is a problem if we want to use the standard trick of initializing
the PRNG with the current time (as the user wanted to in [1]):
gnuplot> print rand(real(system("date +%s")))
0.596925441003784
gnuplot> print rand(real(system("date +%s")))
0.596924809567054
gnuplot> print rand(real(system("date +%s")))
0.596924178130323
gnuplot> print rand(real(system("date +%s")))
0.596923546693592

date +%s returns the time in the Unix time_t format (32 bit integer),
however, the upper bits rarely change in that format.

1) and 2) may be bugs in the implementation that are easy to fix, but 3)
is a deeper problem. Of course, this kind of behavior can be expected
from a linear congruence generator - but then maybe it's time to
consider changing to a different algorithm.

Péter Juhász
ps. Merry Christmas and a Happy New Year to you all!

--------------------------
[1]
http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thread/7e82fdbca70397c7#