(j3.2006) (SC22WG5.4108) [ukfortran] Standard intrinsics and coarrays
Thu Oct 22 08:12:12 EDT 2009
Aleksandar Donev wrote:
> Malcolm Cohen wrote:
>> In a "shared" generator there is a single seed and a single sequence.
>> Images take values from that single sequence.
> Presumably if two calls to RANDOM_NUMBER are unordered, what order they
> take from the sequence is undefined. These kinds of things would need to
> be spelled out explicitly.
Unordered references would be the normal case. As Van correctly pointed
out, this mode of operation is essentially useless in many (most?) cases.
On the other hand, one might argue that the SOLE purpose of the
random_number routine is high performance on a benchmark, and as a
result they tend to be very simplistic linear congruential generators.
For some purpose the quality of the default sequence is OK.
>> In a "separate" generator, each image has a seed and a sequence. Each
>> image takes values from its own sequence.
> Are the generators the same on each image (i.e., same sequence for the
> same seed)? Also needs to be spelled out explicitly.
You would want separated sequences on each image. If the generator has
more than one seed, you can choose one seed value to be the same on
every image and another one that is unique on each image. At least some
classes of such generators assure independent sequences on each image in
However, since we say such things (number of seeds, sequence
characteristics) are processor dependent already, you can't really write
portable code that depends on these details. Unless you use a separate,
known library routine.
>> Perhaps we should require that it should be one or the other.
> If we do the choice is obvious: separate generators on each image.
Certainly the cleanest choice. At least in that case it could be used
for at least some applications.
> Isn't there some room in-between. One can have separate streams but that
> get initialized during a call to RANDOM_SEED together so that they are
> independent on each image. Perhap's we should allow for such cases? For
> example, the SPRNG library (http://sprng.cs.fsu.edu/sprng.html) has a
> Modified Lagged Fibonacci Generator generator that:
> "The seed used during initialization for this generator does not move
> one to a different point in the sequence. Rather, it returns a different
> sequence. The seeding algorithms ensures that if the same seed is used
> for all the streams, then the streams obtained are independent. If a
> user initializes different streams with different seeds, then it is
> possible that the same sequence may be assigned to two different streams
> and hence we may no longer have independent streams. Thus it is
> important to use the same seed while initializing all the streams with
> this generator."
My current favorite is the Mersenne Twister generator (with 4 seed
values). It has a very long period, and contiguous blocks of values can
be used as the coordinates in a multi-dimensional space without nasty
planing (critical for some Monte Carlo uses). There are other
non-planing generators, such as ones based on Halton sequences, but the
Mersenne Twister is faster. According to Wikipedia, it is the standard
generator for Maple, Matlab, R, Ruby, and Python. Notably, all cases
where performance is not the typical focus.
> J3 mailing list
> J3 at j3-fortran.org
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3