You can subscribe to this list here.
2001 
_{Jan}

_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}


2002 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}

2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}
(83) 
_{Nov}
(57) 
_{Dec}
(111) 
2004 
_{Jan}
(38) 
_{Feb}
(121) 
_{Mar}
(107) 
_{Apr}
(241) 
_{May}
(102) 
_{Jun}
(190) 
_{Jul}
(239) 
_{Aug}
(158) 
_{Sep}
(184) 
_{Oct}
(193) 
_{Nov}
(47) 
_{Dec}
(68) 
2005 
_{Jan}
(190) 
_{Feb}
(105) 
_{Mar}
(99) 
_{Apr}
(65) 
_{May}
(92) 
_{Jun}
(250) 
_{Jul}
(197) 
_{Aug}
(128) 
_{Sep}
(101) 
_{Oct}
(183) 
_{Nov}
(186) 
_{Dec}
(42) 
2006 
_{Jan}
(102) 
_{Feb}
(122) 
_{Mar}
(154) 
_{Apr}
(196) 
_{May}
(181) 
_{Jun}
(281) 
_{Jul}
(310) 
_{Aug}
(198) 
_{Sep}
(145) 
_{Oct}
(188) 
_{Nov}
(134) 
_{Dec}
(90) 
2007 
_{Jan}
(134) 
_{Feb}
(181) 
_{Mar}
(157) 
_{Apr}
(57) 
_{May}
(81) 
_{Jun}
(204) 
_{Jul}
(60) 
_{Aug}
(37) 
_{Sep}
(17) 
_{Oct}
(90) 
_{Nov}
(122) 
_{Dec}
(72) 
2008 
_{Jan}
(130) 
_{Feb}
(108) 
_{Mar}
(160) 
_{Apr}
(38) 
_{May}
(83) 
_{Jun}
(42) 
_{Jul}
(75) 
_{Aug}
(16) 
_{Sep}
(71) 
_{Oct}
(57) 
_{Nov}
(59) 
_{Dec}
(152) 
2009 
_{Jan}
(73) 
_{Feb}
(213) 
_{Mar}
(67) 
_{Apr}
(40) 
_{May}
(46) 
_{Jun}
(82) 
_{Jul}
(73) 
_{Aug}
(57) 
_{Sep}
(108) 
_{Oct}
(36) 
_{Nov}
(153) 
_{Dec}
(77) 
2010 
_{Jan}
(42) 
_{Feb}
(171) 
_{Mar}
(150) 
_{Apr}
(6) 
_{May}
(22) 
_{Jun}
(34) 
_{Jul}
(31) 
_{Aug}
(38) 
_{Sep}
(32) 
_{Oct}
(59) 
_{Nov}
(13) 
_{Dec}
(62) 
2011 
_{Jan}
(114) 
_{Feb}
(139) 
_{Mar}
(126) 
_{Apr}
(51) 
_{May}
(53) 
_{Jun}
(29) 
_{Jul}
(41) 
_{Aug}
(29) 
_{Sep}
(35) 
_{Oct}
(87) 
_{Nov}
(42) 
_{Dec}
(20) 
2012 
_{Jan}
(111) 
_{Feb}
(66) 
_{Mar}
(35) 
_{Apr}
(59) 
_{May}
(71) 
_{Jun}
(32) 
_{Jul}
(11) 
_{Aug}
(48) 
_{Sep}
(60) 
_{Oct}
(87) 
_{Nov}
(16) 
_{Dec}
(38) 
2013 
_{Jan}
(5) 
_{Feb}
(19) 
_{Mar}
(41) 
_{Apr}
(47) 
_{May}
(14) 
_{Jun}
(32) 
_{Jul}
(18) 
_{Aug}
(68) 
_{Sep}
(9) 
_{Oct}
(42) 
_{Nov}
(12) 
_{Dec}
(10) 
2014 
_{Jan}
(14) 
_{Feb}
(139) 
_{Mar}
(137) 
_{Apr}
(66) 
_{May}
(72) 
_{Jun}
(142) 
_{Jul}
(70) 
_{Aug}
(31) 
_{Sep}
(39) 
_{Oct}
(98) 
_{Nov}
(133) 
_{Dec}
(44) 
2015 
_{Jan}
(70) 
_{Feb}
(27) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2

3

4
(1) 
5

6

7
(1) 
8
(2) 
9
(15) 
10
(5) 
11

12
(8) 
13
(3) 
14
(8) 
15

16

17

18

19

20

21
(1) 
22

23

24

25

26

27

28
(4) 
29
(14) 
30

31


From: Daniel J Sebald <daniel.sebald@ie...>  20101228 23:56:09

Ethan Merritt wrote: > On Tuesday, December 28, 2010, Juhász Péter wrote: [snip] > > 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 > > > Here I agree that the documentation should state that seeds are > required to be nonzero integers, although it is then tricky to > explain that the way to set both seed values is > rand( i + j*{0,1} ) > > It's fair to consider acceptance of a seed value (0 < seed < 1) as a > bug, since it will immediately be converted to an integer value 0 > which is not a valid seed. This might be an adequate fix: > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >  gnuplot/src/specfun.c 20101021 22:28:24.000000000 0700 > +++ gnuplotcvs/src/specfun.c 20101228 13:23:20.000000000 0800 > @@ 1098,7 +1098,7 @@ ranf(struct value *init) > > /* Construct new seed values from input parameter */ > /* FIXME: Ideally we should allow all 64 bits of seed to be set */ >  if (real(init) > 0.0) { > + if (real(init) > 1.0) { > if (real(init) >= (double)(017777777777UL)) > int_error(NO_CARET,"Illegal seed value"); > if (imag(init) >= (double)(017777777777UL)) > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Note that the FIXME comment is out of date. You can indeed set 64 bits > of seed by using rand(i + j*{0,1}) as noted above. The "value" type is double floats for real and imaginary, then? Well, that should hold 32 bits within a 52 bit fractional. (seed1 and seed2 are longs.) A couple odd things however. Why is the limiting value 017777777777UL? Is that some bad way of obtaining the maximum 32 value of 2^321, i.e., 4294967295? If not, then it should be if (real(init) >= (double)(04294967295UL)) int_error(NO_CARET,"Illegal seed value"); if (imag(init) >= (double)(04294967295UL)) int_error(NO_CARET,"Illegal seed value"); And what is with this? seed1 = (int)real(init); seed2 = (int)imag(init); That's a potential bug for compilers in which the default integer is 16 bits. First casting to int and then casting to long could lose something. Regarding the out of date comment, did it mean that seed1 and seed2 should be 64bit, i.e., long long? Dan 
From: Daniel J Sebald <daniel.sebald@ie...>  20101228 22:36:45

Thanks Péter. The rand() function should probably be revisited with your comments in mind. More below. Juhász Péter wrote: > 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. Actually, my observation is that functions having real arguments will reject string inputs while functions with optional complex arguments will not reject string inputs. For example gnuplot> print gamma("test") gnuplot> print gamma("test") ^ undefined value gnuplot> print erfc("test") 1.0 Perhaps the gnuplot code needs to be altered to also reject strings if the argument is possibly complex, unless a string is a valid input argument. (But I don't know of any, off hand.) > 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. Are you proposing there should be an input argument "time"? The command line documentation says nothing about using the current time as a seed. > 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. Well, here is where gnuplot is deficient in my opinion. The documentation doesn't indicate what the input value should be, a float or an integer. Here's the code to illustrate why this is important: /* Construct new seed values from input parameter */ /* FIXME: Ideally we should allow all 64 bits of seed to be set */ if (real(init) > 0.0) { if (real(init) >= (double)(017777777777UL)) int_error(NO_CARET,"Illegal seed value"); if (imag(init) >= (double)(017777777777UL)) int_error(NO_CARET,"Illegal seed value"); seed1 = (int)real(init); seed2 = (int)imag(init); if (seed2 == 0) seed2 = seed1; } FPRINTF((stderr,"ranf: seed = %lo %lo %ld %ld\n", seed1,seed2)); Comparing floating point with an integer cast to a double is slightly dodgy: real(init) >= (double)(017777777777UL) Hence the uneasy FIXME statement in the comments. More than that, casting floating point quantities to integer quantities for the seed is problematic. This means that any input 0 < x < 1 will put the random number generator in the "zero" state, i.e., stuck. For example, try plot rand(0.5) plot rand(0.34) plot rand(0.789) The thing is, reading the documentation, there is no indication that 0 < x < 1 is invalid. In fact, it's not illogical for the user to assume the value should be in (0,1) since that is what the rand function outputs. There are a couple ways to fix this. (Both methods require giving more detailed description of what numeric type the seed can be.) It seems to be the input of the function can't be either float or integer, it has to be one or the other. If the input is a float, then perhaps 0 < x < 1 and x should be cast to its equivalence in terms of seed. (But it probably isn't a unique equivalence, and therein lies a problem with random number generation with this method when the core algorithm is integer based. Even the existing method of casting loses resolution and has the same problem.) If the input is an integer, then the values should be translated directly to the seeds of the random number generator. (My fear is that the gnuplot code, designed to be generic, has no way of preserving full integer resolution because everything is cast to a float from the command line.) > 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 pseudorandom 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 21orso bits > of the argument are considered. This may be true, but I don't know if this is a measure of randomness. > 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. I'm not sure this is that important. This is just initializing the random number generator. So long as the function's output changes for different inputs, it is effectively starting the random number generator in a different state and the very first step should appear to have randomness. If you are doing an experiment in which trials should have "random"ly independent first values, simply drop the first outcome of the random number generator after the seed (or only seed once, not for each new trial). (Probably good advice no matter what method is used to seed the random number generator...The random number generator is designed to look independent across outcomes, but starting each trial with a seed constructed from exterior isn't necessarily going to have good random properties.) > 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. To me, what's problematic is the loss of resolution because of the way gnuplot is programmed. In other words, we need to go back and address this comment: /* FIXME: Ideally we should allow all 64 bits of seed to be set */ which likely means allowing integer inputs. Do we need some kind of numeric representation which is either a float or an integer, whichever allows the input value to be stored without rounding of some form? Also, the "rand" documentation should be changed to indicate exactly what numeric type the seed should be. Dan 
From: Ethan Merritt <merritt@u.washington.edu>  20101228 22:27:13

On Tuesday, December 28, 2010, Juhász Péter wrote: > 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. I am not terribly concerned that passing a string to a numeric function produces a garbage result, but it would be easy enough to do the same thing in specfun.c that is already done in internal.c and standard.c internal.c:#define pop(x) pop_or_convert_from_string(x) standard.c:#define pop(x) pop_or_convert_from_string(x) > 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 Here I agree that the documentation should state that seeds are required to be nonzero integers, although it is then tricky to explain that the way to set both seed values is rand( i + j*{0,1} ) It's fair to consider acceptance of a seed value (0 < seed < 1) as a bug, since it will immediately be converted to an integer value 0 which is not a valid seed. This might be an adequate fix: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  gnuplot/src/specfun.c 20101021 22:28:24.000000000 0700 +++ gnuplotcvs/src/specfun.c 20101228 13:23:20.000000000 0800 @@ 1098,7 +1098,7 @@ ranf(struct value *init) /* Construct new seed values from input parameter */ /* FIXME: Ideally we should allow all 64 bits of seed to be set */  if (real(init) > 0.0) { + if (real(init) > 1.0) { if (real(init) >= (double)(017777777777UL)) int_error(NO_CARET,"Illegal seed value"); if (imag(init) >= (double)(017777777777UL)) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Note that the FIXME comment is out of date. You can indeed set 64 bits of seed by using rand(i + j*{0,1}) as noted above. > 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 pseudorandom 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 21orso bits > of the argument are considered. Now I'm out of my depth. Pseudorandom number generation is fraught with pitfalls. Is it necessarily a bad thing that the first number is related to the seed? The primary requirement is that successive numbers within a generated sequence be sufficiently independent, or so I understand it. A requirement that related seeds produce unrelated starting values for the sequence seems like a quite different thing. I can imagine that such a property may be desirable for cryptography, but it seems unrelated to uses in gnuplot. Consider the following script: # Tabulate first 1000 numbers in sequences generated by successive seeds set samples 1000 set table '1.dat' print rand(101) plot '+' using 0:(rand(0)) set table '2.dat' print rand(102) plot '+' using 0:(rand(0)) # Compare the paired elements within the two sequences system("join 1.dat 2.dat > 1_2.dat") plot "1_2.dat" using 2:4 No correlation is evident in the two sequences, even though they are seeded with successive integers and thus the numerical difference between their initial elements is small. > > 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 I don't see why this is a problem. Explain, please? If the idea is to generate different streams of random numbers, I think that it succeeds at that. True, the initial values of sequences generated in close succession are similar, but again I have to ask why this is a problem? If it bothers you, can't you just start with the second value of each sequence? > date +%s returns the time in the Unix time_t format (32 bit integer), > however, the upper bits rarely change in that format. So why not use system("date +%N")? > 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! 
From: Juhász Péter <peter.juhasz83@gm...>  20101228 19:17:55

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 pseudorandom 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 21orso 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# 