(j3.2006) RANDOM_INIT question

Bill Long longb
Mon Sep 21 08:46:58 EDT 2015


On Sep 20, 2015, at 10:03 AM, John Reid <John.Reid at stfc.ac.uk> wrote:

> Bill Long wrote:
>> 
>> On Sep 20, 2015, at 4:39 AM, John Reid <John.Reid at stfc.ac.uk> wrote:
>> 
>>> 
>>> 
>>> Bill Long wrote:
>>>> 
>>>> On Sep 17, 2015, at 7:22 PM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:
>>>> 
>>>>> No.
>>>>> 
>>>>> The description (I'm not going to copy it) says that RANDOM_INIT sets the
>>>>> seed.  That is all it does!  Saying "the concept of seed [has no] meaning"
>>>>> w.r.t. RANDOM_INIT flies directly in the face of the specification in the
>>>>> standard.
>>>>> 
>>>>> Calling RANDOM_INIT once and then RANDOM_SEED (PUT=) is not any different in
>>>>> action from calling RANDOM_SEED (PUT=) once, and RANDOM_SEED (PUT=) a second
>>>>> time.
>>>>> 
>>>>> More to the point, you can call RANDOM_INIT (REPEATABLE=.FALSE.) once, then
>>>>> RANDOM_SEED(GET=), and thus save away the seed that RANDOM_INIT set for
>>>>> later use!
>>>> 
>>>> The actual question reduces to whether we can allow, for the non-repeatable case, for random_number to use any generation scheme that does not use a seed.  While random_init does set a seed, it only implies that the corresponding random_number actually uses that seed.
>>> 
>>> If you look at the definitions of RANDOM_NUMBER and RANDOM_SEED
>>> together, I do not see how a generation scheme that does not use a seed
>>> could possibly conform to the standard.
>>> 
>> 
>> That is fine with me. I?m just trying to clarify what to answer when we get a request to use RDRAND for the repeatable = .false. case.  The question is whether it is just the initial seed that is not repeatable between runs, but thereafter random_number produces a repeatable (deterministic) sequence, or whether the entire sequence is not repeatable between runs.   Since this is new territory, it might be useful to include a Note to say which case we intend by the word ?repeatable?.  I?m assuming you intend that the sequence itself is repeatable for a given seed, which is fine, and simplifies usage and implementation.
> 
> I think J3/15-007r2 is already unambiguous. In the description of 
> RANDOM_INIT, we have
> "Initialize the pseudorandom number generator."
> and under REAPEATABLE, we have
> "If it has the value true, the seed accessed by the pseudorandom number 
> generator is set to a processor-dependent value that is the same each 
> time RANDOM_INIT is called from the same image. If it has the value 
> false, the seed is set to a processor-dependent, unpredictably different 
> value on each call."
> 
> Would it help to add "of RANDOM_INIT" at the end of this text?

It would not hurt, but seems unnecessary.  I think the critical wording is "initialize *the* pseudorandom number generator?, where *the* implies that there is only one.  Thus, the implementation is not allowed to set a mode switch that causes a different generator to be used for the repeatable =.true. and repeatable=.false. cases.  Since ?repeatable?  can be used to describe whether a generator would generate the same sequence given a particular starting seed,  there is possibility of confusion.  A Note to say that there is only one generator, and we don?t mean that usage of ?repeatable?,  might be clarifying. 

Cheers,
Bill


> 
> Cheers,
> 
> John.
> 
> 
>> 
>> 
>>> Cheers,
>>> 
>>> John.
>>> 
>>> 
>>>>> 
>>>>> There is no contradiction or any kind of conflict in the descriptions as far
>>>>> as I can see...
>>>>> 
>>>>> As for RDRAND, it does not return a pseudo-random number sequence so is
>>>>> completely unsuitable for implementing RANDOM_NUMBER(*), especially when
>>>>> many values are required in a short space of time.  However, it is Very
>>>>> Suitable for providing entropy to go into the seed value.  (Though one might
>>>>> wish to use other entropy sources as well.)
>>>> 
>>>> 
>>>> Intel separately provides that with RDSEED.
>>>> 
>>>> Cheers,
>>>> Bill
>>>> 
>>>>> 
>>>>> (*) Completely unsuitable in that it literally cannot provide the actual
>>>>> semantics of the RANDOM_* family as specified in Fortran standard.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Bill Long
>>>>> Sent: Thursday, September 17, 2015 10:44 PM
>>>>> To: fortran standards email list for J3
>>>>> Subject: (j3.2006) RANDOM_INIT question
>>>>> 
>>>>> 
>>>>> Suppose the program calls RANDON_INIT with the REPEATABLE argument having
>>>>> the value false.   In this case, does the concept of a ?seed? have any
>>>>> meaning?  Would a call to RANDOM_SEED have any effect for a non-repeatable
>>>>> generator?  More particularly, would it be conforming to use the RDRAND
>>>>> instruction on recent Intel chips to create the random number returned by
>>>>> RANDOM_NUMBER,  and just ignore the seed value set by RANDOM_SEED?
>>>>> 
>>>>> Cheers,
>>>>> Bill
>>>>> 
>>>>> Bill Long
>>>>> longb at cray.com
>>>>> Fortran Technical Support  &                                  voice:
>>>>> 651-605-9024
>>>>> Bioinformatics Software Development                     fax:  651-605-9142
>>>>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> J3 mailing list
>>>>> J3 at mailman.j3-fortran.org
>>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>>> 
>>>>> ________________________________________________________________________
>>>>> This e-mail has been scanned for all viruses by Star.
>>>>> ________________________________________________________________________
>>>>> 
>>>>> --
>>>>> ........................Malcolm Cohen, Nihon NAG, Tokyo.
>>>>> 
>>>>> _______________________________________________
>>>>> J3 mailing list
>>>>> J3 at mailman.j3-fortran.org
>>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>> 
>>>> Bill Long                                                                       longb at cray.com
>>>> Fortran Technical Support  &                                  voice:  651-605-9024
>>>> Bioinformatics Software Development                     fax:  651-605-9142
>>>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>>>> 
>>>> 
>>>> _______________________________________________
>>>> J3 mailing list
>>>> J3 at mailman.j3-fortran.org
>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>> 
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at mailman.j3-fortran.org
>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> 
>> Bill Long                                                                       longb at cray.com
>> Fortran Technical Support  &                                  voice:  651-605-9024
>> Bioinformatics Software Development                     fax:  651-605-9142
>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101





More information about the J3 mailing list