(j3.2006) (SC22WG5.4120) [ukfortran] Parallel random numbers

[N.M. Maclaren]

> The word "common" might be misinterpreted as "same algorithm" or even
> "ordinary". Maybe "shared" would be better.

Fine.

> This seems sufficiently vague to be backward compatible with F03 and any
> current implementation.

That was part of the intent :-)

> We typically discuss in normative text results of execution, rather than
> the method of computing the results. Maybe the whole bit should be a
> NOTE in the RANDOM_NUMBER subclause. Or maybe word this as
> 
>   "It is processor dependent whether the sequence of values returned by
> RANDOM_NUMBER is separate for each image, or is taken from a shared
> sequence.  If separate, then calls to RANDOM_SEED affect only the
> sequence on the same image."
> 
> [Wording could use some polish, but you get the idea...]

Yes, but that's precisely what we MUSTN'T do!

The problem is that defining the effects of a shared sequence opens a
covert channel between images, where one image can inspect the order of
execution of others.  What's worse, the implication is that execution
must be sequentially consistent.  Now, that is very likely to be true
for most implementations that use a shared sequence, but I don't think
the standard should specify it.

I didn't explain it at all well, but it's this class of problem that I
was trying to control by forbidding RANDOM_SEED to be called in
unordered segments.  Allowing even RANDOM_NUMBER leaks some information,
but it's vastly less likely to cause problems.

It is tempting to require each image to use separate generators, but I
don't like that at all.  The reason is that it is HARD to design
reasonably independent ones, most implementations will end up with
separate generators that are horribly correlated, and Fortran will be
damned for being statistically sub-standard.

It's a nasty problem.  In the light of this thread, I think that it
needs a proper paper, setting out the options.

Regards,
Nick.