(j3.2006) (SC22WG5.4109) [ukfortran] Standard intrinsics and coarrays

[N.M. Maclaren]

Ouch.  I will draft some alternative wording that addresses Bill's and
Van's non-random-number comments.  I don't think that it's critical
which approach is taken, as they all strike me as acceptable.  That's
the easy bit.



Random numbers are hairier.  Malcolm has given the main reasons that
I said what I did, but here is more detail.  I will draft some new
alternative wording on this one, too.

There are two reasons I took the hard line on forbidding RANDOM_SEED in
a segment that is unordered with one that includes either RANDOM_SEED or
RANDOM_NUMBER.

    Specifying what is defined and what is not is very hard when
you need to allow for two different models.  POSIX makes a right
royal mess of it, and I should rather not do the same.  At best, it
would be a lot more wording.

    Systems with suitable compare-and-swap hardware can implement
parallel use of a shared RANDOM_NUMBER safely without locking.  Adding
RANDOM_SEED to the mix makes that much trickier, and it's not something
that any sane programmer would do, anyway.

See also Aleks's point at the end.  It wasn't one of my reasons, but
I should now add it to them.

The matter of parallelism is more 'interesting'.  Malcolm is right,
and there are two approaches that I know of to quasi-independence:

    The use of generators with coprime sequences (usually, but not
always, multiplicative congruential).  I published this in 1989,
and it has been separately reinvented by some Russians.

    Choosing starting points so that the sub-sequences are quasi-
independent across as well as along sub-sequences.  Pierre L'Ecuyer
et al. are the experts here - do not, repeat NOT, trust ANY other
group.  Most methods produce mere disjointness, and I can provide
trivial examples of when that leads to near-perfect correlation.

I agree with him.  This is not something that a programming language
should stick its fingers into (as C has, in its loathesome example).
It's like defining the algorithms used for MATMUL or complex
exponentiation.



Van  raised this point:
> It looks like Hobson's choice, but we ought either to choose, to
> provide a mechanism for a program to choose, or require the processor
> to provide a mechanism, outside the language, to choose.

It's a fair point, but that would mean specification changes.  I am
trying to do this without any - as is procedurally correct!  Also,
I noted the same for CPU_TIME, and omitted that for the same reason.
Here is what I suggest (but not for Fortran 2008):

    RANDOM_SEED ([SEED, PUT, GET, PER_IMAGE, STAT])
    CPU_TIME (TIME [, PER_IMAGE, STAT])

    If PER_IMAGE is .True., the CPU_TIME is per-image, if .False.,
    per-process; the default is processor dependent.  STAT returns
    non-zero for "can't".



Here are some specific comments on one posting of Aleks's.

> > Perhaps we should require that it should be one or the other.
> 
> If we do the choice is obvious: separate generators on each image.

Oh, no, it isn't!  It's HAIRY designing decent quasi-independent
generators, and most of the methods aren't scalable.

> 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:

My original wording does, indeed, allow for that case.  Fortuitously,
but still :-)

> "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."

Well, I am reluctant to say that is bullshit, but I can find no evidence
in either their TOMS paper or their Web pages that it isn't, and some
evidence that it is.  I am a bit too rusty to say for certain off the
top of my head, and don't have time to do the analysis now.


Regards,
Nick.