(j3.2006) Rationale for RANDOM_INIT?

[Steven G. Kargl]

On Wed, Jan 03, 2018 at 06:37:30PM -0500, Steve Lionel wrote:
> On 1/3/2018 6:16 PM, Steven G. Kargl wrote:
> > I'm trying to understand the rationale behind the
> > new RANDOM_INIT subroutine, and in particular why
> > is the second argument, IMAGE_DISTINCT, not an
> > optional argument?  It seems that its purpose is
> > to be used in a program that uses co-arrays where
> > multiple instances of the program will be executed.
> > This then suggests that the argument is of no use
> > with programs that will never use co-arrays.
> >
> > Is there a Nxxx.pdf document that I sould read?
> >
> The paper you want is J3 14-184r4 
> (http://j3-fortran.org/doc/year/14/14-184r4.txt) . N2013 
> (https://wg5-fortran.org/N2001-N2050/N2013.txt) is also relevant. Even 
> though I wrote the spec, I don't recall exactly why IMAGE_DISTINCT 
> wasn't optional. I think there was sentiment that there was no obvious 
> choice for a default behavior and there are only two arguments (at this 
> time.) This intrinsic arose from a UK country comment. We noted at the 
> time that implementations differed in how they interpreted a call to 
> RANDOM_SEED with no arguments (left unspecified by the standard), and 
> that there was a need to also allow specification of how the RNG 
> operated across images.
> 

Well, I orginally misread the F2018 Standard, and now I think
RANDOM_INIT is insufficiently defined.  There are three issues,
and I suspect that it is too late to address them.  The problem
lies with IMAGE_DISTINCT, where the Standard states

   IMAGE_DISTINCT shall be a logical scalar. It is an INTENT(IN)
   argument.  If it has the value true, the seed accessed by the
   pseudorandom number generator is set to a processor-dependent
   value that is distinct from the value that would be set by a
   call to RANDOM_INIT by another image.  If it has the value false,
   the value to which the seed is set does not depend on which
   image calls RANDOM_INIT.

1) IMAGE_DISTINCT should be an optional argument.  I suspect that
   if a survey were conducted, one would find that a significant
   majority of programs, when compiled and executed, cause a single
   image to be instantiated.  IMAGE_DISTINCT is irrelevant in this
   case.

Now, suppose that the executable instantiates two images, and for
this discussion call them image0 and image1.

2) IMAGE_DISTINCT=.true. means *distinct* seeds are used to seed
   the PRNG in image0 and image1.  This suggests that there is an
   implied assumption that the *distinct* seeds will lead to
   *distinct* sequences of RN.  Is this the intent of the Standard?
   If yes, then the Standard should remove the assumption and state
   the expected behavior.

   Compilers likely use a PRNG with some long period.  The seed 
   initializes the PRNG by essentially pointing to a particular
   member in the sequence of all RN.  It is then possible that
   *distinct* seeds lead to a sequence for image0 of [A B C D E ...]
   and for image1 of [C D E ...].  That is, the two sequences have
   a significant overlap.  Here, a question of how much overlap 
   should be permissable arises.

   So, what does *distinct* mean?  

3) Given the requirement of *distinct* seeds, this eliminates a class
   of PRNG that can use a single seed to select a particular member in
   the sequence of all RN, and then use a transform to select independent
   subsequences.  For example, internally, xform(0) would cause image0
   to select subsequence 0 and xform(1) causes image1 to select
   the subsequence 1.  A description of this class of generator can
   be found at http://vigna.di.unimi.it/ftp/papers/xorshift.pdf.

It seems to me that the Standard should not require *distinct* seeds
when IMAGE_DISTINCT=.true., but rather require independent sequences.
The level of independence can be some statistical metric.

-- 
Steve