KISS4691, a potentially top-ranked RNG.

[glen herrmannsfeldt]

(snip, I wrote)
(snip)

So for the put= values in fortran, you need a vector of pseudorandom
integers, which is as good as it gets without truly random devices,
making--one hopes-a period that is large with respect to the interval
you're interested in.

In a large fraction of the cases, 2 billion different seeds
are enough, but one can still desire the appropriate randomness
from those different seeds.

It doesn't seem like a problem with epistemology as much
a mathematical ceiling on how much randomness you can create
by a handful of values.

Given a default integer, one might fill an array with that
integer and use that as a seed. That might be good for some,
not so good for others. Even more, for standard Fortran such
should be done without knowing the range of values of an integer
variable.

R has two seeding functions, one that takes a full length state
array, and the other takes a single integer. That makes sense
to me.

-- glen

 

[Uno]

That produces different c values from those generated by the method
based on the value of (t<x), therefore it deviates from the C code.
This is what I used:

m = shiftl(x,13) + c
if (sign(1,m) == sign(1,x)) then
c = sign(1,x) + shiftr(x,19)
else
c = 1 - sign(1,m) + shiftr(x,19)
endif

Gib, can you post your entire fortran version?

 

[Gib Bogle]

Gib, can you post your entire fortran version?

OK, here's the Fortran. I've removed almost all the comments to save space.
If you uncomment the line in MWC():
c = c_this_works
you'll see how to reproduce the C code results.

Gib

module kiss_mod
implicit none

integer :: xs = 521288629
integer :: xcng = 362436069
integer :: Q(0:4690)

contains

integer function MWC()
integer :: m, x, i
integer, save :: c = 0, j = 4691
integer :: t, tLTx, c_this_works

if (j < 4690) then
j = j + 1
else
j = 0
endif
x = Q(j)
m = SHIFTL(x,13) + c
Q(j) = m + x
t = Q(j)

! This is the laborious determination of c
if ((t >= 0 .and. x >= 0) .or. (t < 0 .and. x < 0)) then
if (t < x) then
tLTx = 1
else
tLTx = 0
endif
elseif (x < 0) then
tLTx = 1
elseif (t < 0) then
tLTx = 0
endif
c_this_works = tLTx + SHIFTR(x,19)

! This c gives results inconsistent with the C code
if (sign(1,m) == sign(1,x)) then
c = sign(1,x) + SHIFTR(x,19)
else
c = 1 - sign(1,m) + SHIFTR(x,19)
endif

! c = c_this_works
MWC = Q(j)
end function

subroutine test_RNG4691
integer :: i, x, unsigned_result
integer :: n = 1000000000
do i = 0, 4690
xcng = 69069 * xcng + 123
xs = XOR(xs,SHIFTL(xs,13))
xs = XOR(xs,SHIFTR(xs,17))
xs = XOR(xs,SHIFTL(xs,5))
Q(i) = xcng + xs
enddo
do i = 1, n
x = MWC()
enddo
unsigned_result = 3740121002
write(*,*) "MWC result=3740121002 ?: ",unsigned_result,x
do i = 1,n
xcng = 69069 * xcng + 123
xs = XOR(xs,SHIFTL(xs,13))
xs = XOR(xs,SHIFTR(xs,17))
xs = XOR(xs,SHIFTL(xs,5))
x = MWC() + xcng + xs
enddo
unsigned_result = 2224631993
write(*,*) "KISS result=2224631993 ?: ",unsigned_result,x
end subroutine

end module

program main
use kiss_mod
call test_RNG4691
end program

 

[Uno]

OK, here's the Fortran. I've removed almost all the comments to save
space.
If you uncomment the line in MWC():
c = c_this_works
you'll see how to reproduce the C code results.

Alright, thx, gib, looks like there's a couple rough corners:

$ gfortran geo1.f90 -o out
geo1.f90:63.32:

unsigned_result = 3740121002
1
Error: Integer too big for its kind at (1). This check can be disabled
with the option -fno-range-check

So, do I ask for something bigger than the default integer, use the
iso_c_binding, or disable the warning?

I think of 3.5 billion as a value that busts types in C. I would have
thought that was going on except for the second error:

geo1.f90:72.32:

unsigned_result = 2224631993
1
Error: Integer too big for its kind at (1). This check can be disabled
with the option -fno-range-check


Then there's this. It looks like the bitshifting capabilities that
fortran and C have, but neither MR&C nor my slightly-inappropriate C
reference have a SHIFTL. Do you have a definition for it?
geo1.f90:55.16:

xs = XOR(xs,SHIFTL(xs,13))
1
Error: Function 'shiftl' at (1) has no IMPLICIT type

Beautiful night with the cicadas humming. I don't know that I've ever
seen one which makes them, aesthetically, my favorite bug. Cheers,

 

[Ron Shepard]

In a large fraction of the cases, 2 billion different seeds
are enough, but one can still desire the appropriate randomness
from those different seeds.

My understanding is that pseudorandom number generators return a
sequence of values with some period. The numbers in that sequence
eventually repeat with some, hopefully long, cycle. The put=array
argument gives the starting point within that sequence, but it doesn't
affect the cycle length or the "randomness" of the values, those things
are determined by the underlying algorithm, not by the initial seed.

The situation that needs to be avoided is to run the code once with one
seed, and then run it again with another seed that results in an overlap
of the sequences of values for the two runs. In some applications this
is unimportant, but in other applications it would be bad for two
supposedly independent runs to have a long sequence of identical values.
It would be nice if there were some prescription to generate initial
seeds that would avoid this situation. However, I don't really know how
this could be specified in the fortran standard without specifying the
algorithm itself (which is not done, apparently on purpose). Anyone
have any ideas how this could be done?

$.02 -Ron Shepard

 

[glen herrmannsfeldt]

My understanding is that pseudorandom number generators return a
sequence of values with some period. The numbers in that sequence
eventually repeat with some, hopefully long, cycle. The put=array
argument gives the starting point within that sequence, but it doesn't
affect the cycle length or the "randomness" of the values, those things
are determined by the underlying algorithm, not by the initial seed.

The situation that needs to be avoided is to run the code once with one
seed, and then run it again with another seed that results in an overlap
of the sequences of values for the two runs. In some applications this
is unimportant, but in other applications it would be bad for two
supposedly independent runs to have a long sequence of identical values.
It would be nice if there were some prescription to generate initial
seeds that would avoid this situation. However, I don't really know how
this could be specified in the fortran standard without specifying the
algorithm itself (which is not done, apparently on purpose). Anyone
have any ideas how this could be done?

Here is the suggestion. Add to RANDOM_SEED a form that allows
a single integer variable to be supplied as a seed source.

As far as I know, there is no requirement on period or otherwise
on the quality of the PRNG used, but the standard could suggest
that good seeds be selected from that integer. For example,
they could be chosen such that they have a fairly long sequence
before they overlap the sequence generated by another input
value. If the RNG only has 32 bits of state, or maybe less, then
it likely takes it directly.

I don't know the math of the newer PRNGs enough to say, but I
think it is possible to do that.

With the current standard there is no way to even suggest to
RANDOM_SEED that you want a good seed.

OK, here is another suggestion that could be implemented without
any change in the standard. In the case where the supplied
seed array has all except the first element zero, then select
a good seed based on that first element.

-- glen

 

[orz]

My understanding is that pseudorandom number generators return a
sequence of values with some period.  The numbers in that sequence
eventually repeat with some, hopefully long, cycle.  The put=array
argument gives the starting point within that sequence, but it doesn't
affect the cycle length or the "randomness" of the values, those things
are determined by the underlying algorithm, not by the initial seed.

The situation that needs to be avoided is to run the code once with one
seed, and then run it again with another seed that results in an overlap
of the sequences of values for the two runs.  In some applications this
is unimportant, but in other applications it would be bad for two
supposedly independent runs to have a long sequence of identical values.  
It would be nice if there were some prescription to generate initial
seeds that would avoid this situation.  However, I don't really know how
this could be specified in the fortran standard without specifying the
algorithm itself (which is not done, apparently on purpose).  Anyone
have any ideas how this could be done?

$.02 -Ron Shepard

My understanding is that pseudorandom number generators return a
sequence of values with some period. The numbers in that sequence
eventually repeat with some, hopefully long, cycle. The put=array
argument gives the starting point within that sequence, but it doesn't
affect the cycle length or the "randomness" of the values, those things
are determined by the underlying algorithm, not by the initial seed.

The situation that needs to be avoided is to run the code once with one
seed, and then run it again with another seed that results in an overlap
of the sequences of values for the two runs. In some applications this
is unimportant, but in other applications it would be bad for two
supposedly independent runs to have a long sequence of identical values.
It would be nice if there were some prescription to generate initial
seeds that would avoid this situation. However, I don't really know how
this could be specified in the fortran standard without specifying the
algorithm itself (which is not done, apparently on purpose). Anyone
have any ideas how this could be done?

$.02 -Ron Shepard

If an RNG has a large number of possible states (say, 2^192) then it's
unlikely for any two runs to EVER reach identical states by any means
other than starting from the same seed. This RNG has a period vastly
in excess of "large", so for practical purposes it just won't
happen.

However, because this is a combination of multiple component RNGs
there is the related issue of overlapping within the period of one or
more component RNGs. MWC has essentially zero chance of being in an
identical state for any reason other than identical seeding, but both
XS and CNG will frequently have identical states in two different
runs. There does not seem to be any detectable correlation however
unless (either MWC or (both XS and CNG)) have identical states between
two different runs. Which is rather uncommon, though it does happen
often enough to see it in the real world on occasion.

 

[Gib Bogle]

Alright, thx, gib, looks like there's a couple rough corners:

$ gfortran geo1.f90 -o out
geo1.f90:63.32:

unsigned_result = 3740121002
1
Error: Integer too big for its kind at (1). This check can be disabled
with the option -fno-range-check

So, do I ask for something bigger than the default integer, use the
iso_c_binding, or disable the warning?

I think of 3.5 billion as a value that busts types in C. I would have
thought that was going on except for the second error:

geo1.f90:72.32:

unsigned_result = 2224631993
1
Error: Integer too big for its kind at (1). This check can be disabled
with the option -fno-range-check


Then there's this. It looks like the bitshifting capabilities that
fortran and C have, but neither MR&C nor my slightly-inappropriate C
reference have a SHIFTL. Do you have a definition for it?
geo1.f90:55.16:

xs = XOR(xs,SHIFTL(xs,13))
1
Error: Function 'shiftl' at (1) has no IMPLICIT type

Beautiful night with the cicadas humming. I don't know that I've ever
seen one which makes them, aesthetically, my favorite bug. Cheers,

Uno, the only reason for putting those lines in with unsigned_integer is to show
that the result that you see when x is written is actually the same as the
C-generated number. The Intel Fortran compiler is happy with the code, not even
issuing a warning. I suggest using -fno-range-check, or alternatively subtract
2^31 from the big numbers (I think). Or you could just take my word for it.

I didn't realize that SHIFTL and SHIFTR were not standard Fortran. You can use
ISHFT:

result = ISHFT (i,shift)

i (Input) Must be of type integer.

shift (Input) Must be of type integer. The absolute value for shift must be less
than or equal to BIT_SIZE( i).

Results
The result type is the same as i. The result has the value obtained by shifting
the bits of i by shift positions. If shift is positive, the shift is to the
left; if shift is negative, the shift is to the right. If shift is zero, no
shift is performed.

Bits shifted out from the left or from the right, as appropriate, are lost.
Zeros are shifted in from the opposite end.

ISHFT with a positive shift can also be specified as LSHIFT (or LSHFT). ISHFT
with a negative shift can also be specified as RSHIFT (or RSHFT)with | shift |.

I'm very surprised to hear you say you've never seen a cicada. In the summer
they are impossible to miss here. Sparrows catch them on the wing. But what
you are hearing at night are not cicadas, I think. As far I know they are
active only in daylight hours. The night shift (here) is taken by crickets,
whose song I find very musical. You don't get to see them much. They tend to
hide in cracks in the ground, which open up in the dry season. Sometimes
crickets come inside, black ones here.

 

[glen herrmannsfeldt]

(snip)

You can subtract 2**32, or find two values to IOR together.
(And remember that this is all twos-complement specific.)

-- glen

 

[glen herrmannsfeldt]

(snip)

If an RNG has a large number of possible states (say, 2^192) then it's
unlikely for any two runs to EVER reach identical states by any means
other than starting from the same seed. This RNG has a period vastly
in excess of "large", so for practical purposes it just won't
happen.

That is true, but there are some assumptions. Since the
standard doesn't say much at all about the underlying algorithm,
it isn't so reliable a statement as it seems.

For one, many PRNGs have poor performance with some starting seeds,
or poor performance for some cycles, especially as viewed from
the low bits.

However, because this is a combination of multiple component RNGs
there is the related issue of overlapping within the period of one or
more component RNGs. MWC has essentially zero chance of being in an
identical state for any reason other than identical seeding, but both
XS and CNG will frequently have identical states in two different
runs. There does not seem to be any detectable correlation however
unless (either MWC or (both XS and CNG)) have identical states between
two different runs. Which is rather uncommon, though it does happen
often enough to see it in the real world on occasion.

My previous comments were regarding the Fortran standard
RANDOM_SEED routine. I haven't thought about the seeding of
the RNG recently mentioned here.

-- glen

 

[Gib Bogle]

You can subtract 2**32, or find two values to IOR together.
(And remember that this is all twos-complement specific.)

Ah, of course.

 

[nmm1]

My understanding is that pseudorandom number generators return a
sequence of values with some period. The numbers in that sequence
eventually repeat with some, hopefully long, cycle. The put=array
argument gives the starting point within that sequence, but it doesn't
affect the cycle length or the "randomness" of the values, those things
are determined by the underlying algorithm, not by the initial seed.

The situation that needs to be avoided is to run the code once with one
seed, and then run it again with another seed that results in an overlap
of the sequences of values for the two runs. In some applications this
is unimportant, but in other applications it would be bad for two
supposedly independent runs to have a long sequence of identical values.

No, no, a thousand times, NO! That is NOT enough, though FAR too many
Web pages, published papers and books claim that it is. Disjointness
isn't even a poor relation of randomness.

This is easiest to see with a simple multiplicative congruential
generator, but many classes of generator have similar properties.
A sequence can be written as A.B^k, for k = 1...n, where B is fixed
by the properties of the generator but A also depends on the seed.
Two sequences X1 and X2 will always have the property that
A2.X1+A1.X2 = 0 modulo M.

So A1 and A2 need to be large and different, but you also need to
consider offset sequences - e.g. with A2 replaced by A2.B^p, for
all values of p < n. The spectral test theory tells you that you
will always have some values of p for which Q2.X1+Q1.X2 = 0 modulo M
and both Q1 and Q2 are very small. That's Bad News for many analyses.

This problem was a significant driving force behind the development
of the highly non-linear algorithms and composite algorithms. Both
are resistant to it, and the combination is very resistant. KISS4691
is one such.

Parallel random number generation is not easy, and 99% of the stuff
published on it is somewhere between grossly misleading and complete
nonsense.


Regards,
Nick Maclaren.

 

[Uno]

| This doesn't work with systems that have unsigned long as a 64 bit quantity.
|
| I obtain:
|
| MWC result=3740121002 ?
| 4169348530
| KISS result=2224631993 ?
| 1421918629

For a 64-bit machine (using 64-bit integer arithmetic),
you'd need to truncate each result to 32 bits. That not
only applies to the multiplication, it also applies to addition, etc.
On a 32-bit machine, these extra bits are discarded,
but in 64-bit arithmetic, they are retained,
and unless they are similarly discarded,
you won't get the same results.
I suggest using IAND(k, 2*2147483647+1)
for the truncation.

With such modifications in the program,
it should then produce the same results on both 32-bit and
64-bit machines.

P.S. the product 2*2... is best obtained using ISHFT.

| Compiling with 32 bit machine yields:
| MWC result=3740121002 ?
| 3740121002
| KISS result=2224631993 ?
| 2224631993

First of all, I think we're talking to the actual George Marsaglia here.
Thank you so much for posting. You may have displaced Terence as our
senior member.

Are you creating bigger numbers just to accomodate your age?

$ gcc -Wall -Wextra geo1.c -o out
geo1.c: In function ‘MWC’:
geo1.c:5: warning: type defaults to ‘int’ in declaration of ‘c’
geo1.c:5: warning: type defaults to ‘int’ in declaration of ‘j’
geo1.c:5: warning: unused variable ‘i’
geo1.c: In function ‘main’:
geo1.c:21: warning: format ‘%22u’ expects type ‘unsigned int’, but
argument 2 has type ‘long unsigned int’
geo1.c:23: warning: format ‘%22u’ expects type ‘unsigned int’, but
argument 2 has type ‘long unsigned int’
geo1.c:24: warning: control reaches end of non-void function

$ ./out
MWC result=3740121002 ?
3740121002
KISS result=2224631993 ?
2224631993
$ cat geo1.c
static unsigned long xs=521288629,xcng=362436069,Q[4691];

unsigned long MWC(void) /*takes about 4.2 nanosecs or 238 million/
second*/
{unsigned long t,x,i; static c=0,j=4691;
j=(j<4690)? j+1:0;
x=Q[j];
t=(x<<13)+c+x; c=(t<x)+(x>>19);
return (Q[j]=t);
}

#define CNG ( xcng=69069*xcng+123 )
#define XS ( xs^=(xs<<13), xs^=(xs>>17), xs^=(xs<<5) )
#define KISS ( MWC()+CNG+XS ) /*138 million/sec*/

#include <stdio.h>
int main()
{unsigned long i,x;
for(i=0;i<4691;i++) Q=CNG+XS;
for(i=0;i<1000000000;i++) x=MWC();
printf(" MWC result=3740121002 ?\n%22u\n",x);
for(i=0;i<1000000000;i++) x=KISS;
printf("KISS result=2224631993 ?\n%22u\n",x);
}

// gcc -Wall -Wextra geo1.c -o out
$

So, what is all this? In particular, is there something special about
the value of 3.7 billion?

 

[Uno]

Here is the suggestion. Add to RANDOM_SEED a form that allows
a single integer variable to be supplied as a seed source.

As far as I know, there is no requirement on period or otherwise
on the quality of the PRNG used, but the standard could suggest
that good seeds be selected from that integer. For example,
they could be chosen such that they have a fairly long sequence
before they overlap the sequence generated by another input
value. If the RNG only has 32 bits of state, or maybe less, then
it likely takes it directly.

I don't know the math of the newer PRNGs enough to say, but I
think it is possible to do that.

With the current standard there is no way to even suggest to
RANDOM_SEED that you want a good seed.

OK, here is another suggestion that could be implemented without
any change in the standard. In the case where the supplied
seed array has all except the first element zero, then select
a good seed based on that first element.

Ron asks an interesting question, and I think you shoot from the hip and
may have missed on this one.

First of all, when crossposted to clc and sci.math, there is no
"standard" that does not require disambiquity. Given what it is, we
might say "the C standard" when talking about C, or its lurking uncle,
the fortran standard.

I don't agree that you need to "add" to random_seed a form that allows a
single integer variable supplied as a seed source. Any fortran program
that implements this will be fortran-conforming by virtue of there being
little specificity in either standard on this and no appetite to change
it in either community.

"disambiquity:" I kind of like that word.

 

[David Bernier]

Ron Shepard wrote:
[...]

The situation that needs to be avoided is to run the code once with one
seed, and then run it again with another seed that results in an overlap
of the sequences of values for the two runs. In some applications this
is unimportant, but in other applications it would be bad for two
supposedly independent runs to have a long sequence of identical values.

I don't know how likely it would be for two seeds to produce
overlap in a short time. But I like using seeds that I've
almost surely never used before. I happen to use
the Mersenne Twister algorithm, but getting new
"random" seeds is always good for any algorithm.

It would be nice if there were some prescription to generate initial
seeds that would avoid this situation. However, I don't really know how
this could be specified in the fortran standard without specifying the
algorithm itself (which is not done, apparently on purpose). Anyone
have any ideas how this could be done?

[...]

I often want to do just that: use new seeds. I used to go to
http://www.random.org/ and get random bits.

The way I do things now is to have a file "data" and take a sha256 hash value,
which is presented in hexadecimal. To avoid reusing the same seed,
I then append the hash-value to the file "data" .

This can be automated with a script which uses the "bash" shell (popular
in Linux); for a C-shell, something similar should work.

[The next step would be to be to access the script from
a fortran or C program ... ]

listing of rnd.sh file (3 lines long, made executable by: chmod u+x rnd.sh )
#! /bin/bash
sha256sum wcisha >> wcisha
sha256sum wcisha

The rnd.sh file is in my home directory, as well as the "data" file 'wcisha'.

In use:
[ ~]$ ./rnd.sh [Enter]
52897abc80205035b14986dd8d4d7b1549b98dca8c959f944f43b7c535e4f059 wcisha


[ ~]$ ./rnd.sh [Enter]
6822ad1bd1d1e453e66d2b65ea79f82a86a1ae53f90512b08f1feedcce6ae9f0 wcisha

David Bernier

 

[Uno]

|I have been asked to recommend an RNG
| (Random Number Generator) that ranks
| at or near the top in all of the categories:
| performance on tests of randomness,
| length of period, simplicity and speed.
| The most important measure, of course, is
| performance on extensive tests of randomness, and for
| those that perform well, selection may well depend
| on those other measures.

I have already posted a PL/I version using unsigned arithmetic.

Here is another version, this time using signed arithmetic :--

(NOSIZE, NOFOFL):
RNG: PROCEDURE OPTIONS (MAIN, REORDER);

declare (xs initial (521288629), xcng initial (362436069),
Q(0:4690) ) static fixed binary (31);

MWC: procedure () returns (fixed binary (31));
declare (t,x,i) fixed binary (31);
declare (c initial (0), j initial (4691) ) fixed binary (31) static;
declare (t1, t2, t3) fixed binary (31);

if j < hbound(Q,1) then j = j + 1; else j = 0;
x = Q(j);
t = isll(x,13)+c+x;
t1 = iand(x, 3) - iand(t, 3);
t2 = isrl(x, 2) - isrl(t, 2);
if t2 = 0 then t2 = t1;
if t2 > 0 then t3 = 1; else t3 = 0;
c = t3 + isrl(x, 19);
Q(j)=t;
return (t);
end MWC;

CNG: procedure returns (fixed binary (31));
xcng=bin(69069)*xcng+bin(123);
return (xcng);
end CNG;

XXS: procedure returns (fixed binary (31));
xs = ieor (xs, isll(xs, 13) );
xs = ieor (xs, isrl(xs, 17) );
xs = ieor (xs, isll(xs, 5) );
return (xs);
end XXS;

KISS: procedure returns (fixed binary (31));
return ( MWC()+CNG+XXS );
end KISS;

declare (i,x) fixed binary (31);
declare y fixed decimal (11);

Q = CNG+XXS; /* Initialize. */
do i = 1 to 1000000000; x=MWC(); end;
put skip edit (" Expected MWC result = 3740121002", 'computed =', x)
(a, skip, x(12), a, f(11));
y = iand(x, 2147483647);
if x < 0 then y = y + 2147483648;
put skip edit (y) (x(11), f(22)); put skip;
do i = 1 to 1000000000; x=KISS; end;
put skip edit ("Expected KISS result = 2224631993", 'computed =', x)
(a, skip, x(12), a, f(11));
y = iand(x, 2147483647);
if x < 0 then y = y + 2147483648;
put skip edit (y) (x(11), f(22));

end RNG;

If you were to comment out the PL/I command line that compiled this,
what would it be?

 

[robin]

| (snip)
|
| >> unsigned_result = 3740121002
| 1
| >> Error: Integer too big for its kind at (1). This check can be disabled
| >> with the option -fno-range-check
|
| You can subtract 2**32, or find two values to IOR together.

Subtracting 2**32 won't do anything because it is entirely put of range
(i.e., requires 33 bits.
The magic number is to subtract or add 2**31.

 

[robin]

| I think of 3.5 billion as a value that busts types in C. I would have
| thought that was going on except for the second error:

It doesn't "bust" types in C, because it is a valid unsigned number
for a 32-bit machine.

| geo1.f90:72.32:
|
| unsigned_result = 2224631993
| 1
| Error: Integer too big for its kind at (1). This check can be disabled
| with the option -fno-range-check

Same as above. It's valid unsigned number.

 

[Ron Shepard]

No, no, a thousand times, NO! That is NOT enough, though FAR too many
Web pages, published papers and books claim that it is. Disjointness
isn't even a poor relation of randomness.

That may be correct, but without specifying the PRNG algorithm, that
may be all that could be expected for a "good" choice of initial
seeds.

I guess my earlier question wasn't clear enough, so I will try to
rephrase it. What I'm looking for is whether there is a practical
way to define a subroutine like

call RANDOM_NEW_SEED( old_seed, n, new_seed )

new_seed) and old_seed) are integer arrays of the appropriate
length for the (unspecified) PRNG algorithm. old_seed) was some
old seed that was used elsewhere, perhaps in some previous execution
of the same code, or perhaps in some other initialization of the
PRNG on another node of a parallel machine. The integer n is the
number of values that will be generated, or some estimate thereof.
new_seed) is the new seed that is guaranteed to result in a
sequence of values that do not overlap with the previous run
(assuming the cycle length is long enough, of course).

I guess one might be able to impose other conditions on the values
that will be generated, such as those you mention, but again,
without actually specifying the PRNG algorithm, it isn't clear to me
how that could be done generally.

Parallel random number generation is not easy, and 99% of the stuff
published on it is somewhere between grossly misleading and complete
nonsense.

I think in the parallel case, one would want to be able to generate
a seed to produce values that are guaranteed not to overlap with any
other node. Maybe something like

call RANDOM_NEW_SEED( old_seed, n, new_seed, my_node )

would be a sufficient interface. new_seed) would depend on
my_node in such a way that the generated sequence would not overlap
with that produced by any other possible value of my_node (again,
assuming the cycle length is long enough to satisfy that request).

$.02 -Ron Shepard

 

[Gib Bogle]

P.S. I'm still hoping to hear from George, either telling me that the
difference between the C-generated and Fortran-generated sequences is immaterial
(from the randomness point of view), or how to make the Fortran work in exactly
the same way as the C code. Anyone else is free to contribute in his place ...