(j3.2006) RANDOM_INIT question

[Bill Long]

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. 

Cheers,
Bill



> 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