(j3.2006) What does "same image" mean?
Bill Long
longb
Wed Feb 21 13:50:44 EST 2018
?that depends on the index in the initial team? is correct only if the IMAGE_DISTINCT argument has the value true. To reuse your words below, there are 3 cases:
If the value of REPEATABLE is true and the value of IMAGE_DISTINCT is true, the seed accessed by the pseudorandom number generator is set to a processor-dependent value that depends on the index in the initial team of the executing image but is otherwise the same for every execution of RANDOM_INIT. {We don?t need the ?on the processor? bit since it is already stated to be processor dependent.}
If the value of REPEATABLE is true and the value of IMAGE_DISTINCT is false, the seed accessed by the pseudorandom number generator is set to a processor-dependent value that is the same for every execution of RANDOM_INIT.
If the value of REPEATABLE is false, the seed accessed by the pseudorandom number generator is set to a processor-dependent value that is unpredictably different for every execution of RANDOM_INIT.
Given this requirement when REPEATABLE is false, it is not clear that the value of IMAGE_DISTINCT matters in that case.
Cheers,
Bill
> On Feb 21, 2018, at 3:20 AM, John Reid <John.Reid at stfc.ac.uk> wrote:
>
> Bill,
>
> OK, this is the intent. How do we change the words in the standard to make it unambiguous? Here is another (rather clunky) attempt.
>
> "If it (the argument repeatable) has the value true, the seed accessed by the pseudorandom number generator is set to a processor-dependent value that depends on the index in the initial team of the executing image but is otherwise the same for every execution of RANDOM_INIT on the processor."
>
> Cheers,
>
> John.
>
>
> Bill Long wrote:
>> The earlier post from Steve Lionel correctly reflects the intent here. Each image is an instance of executing the program. If you execute in parallel, you have multiple images in that ?run?. Or if you run the program serially then each time you run it is an instance of executing the program. It is the same program being executed each time. The whole point of REPEATABLE = .true. and IMAGE_DISTINCT = .false. is that the same sequence is generated each time you execute the program.
>>
>> Cheers,
>> Bill
>>
>>
>>> On Feb 20, 2018, at 4:46 PM, Steven G. Kargl <kargl at troutmask.apl.washington.edu> wrote:
>>>
>>> John,
>>>
>>> I agree that there is an ambiguity in the language of the
>>> Standard. I disagree with the assessment that the below
>>> behavior is non-conforming (at least with regards to the
>>> draft of F2018 that I had).
>>>
>>> The crux of the problem is 3.84
>>> image
>>> instance of a Fortran program
>>>
>>> Execution of a program causes an image to occur (ie., an
>>> instance of the Fortran program). RANDOM_INIT(.true., .false.)
>>> will use a processor-dependent value of the seed. If
>>> RANDOM_INIT(.true., .false.) were called again in image, then
>>> the Standard requires that the same seed value to be used.
>>>
>>> Now, when the image completes and exits, the instance of
>>> the Fortran program no longer exists. Execution of the program
>>> a second time will cause a new different image to occur. As thisr
>>> is a new, different image, it cannot possibly be the *same image*
>>> as an image that no longer exists. In this new different image,
>>> RANDOM_INIT(.true., .false.) will use a processor-dependent value
>>> of the seed. The Standard (at least the draft I had) does not
>>> require that this new seed be the same as the previous.
>>>
>>> For the record, I do believe the Standard ought to say what I
>>> preceive to be your preference.
>>>
>>> --
>>> steve
>>>
>>>
>>> On Tue, Feb 20, 2018 at 07:50:12PM +0000, John Reid wrote:
>>>> Steven,
>>>>
>>>> I would say that this behaviour does not conform, but there does appear
>>>> to be an ambiguity. Should we add "on the same processor" at the
>>>> sentence end so that it reads "If it (the argument repeatable) 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 on the same processor."?
>>>>
>>>> John Reid.
>>>>
>>>>
>>>>
>>>> Steven G. Kargl wrote:
>>>>> Bill,
>>>>>
>>>>> I agree with your assessment with the observation that I'm
>>>>> concern with what a mere mortal user thinks the standard
>>>>> says. As far as I know, the following conforms
>>>>>
>>>>> program foo
>>>>> real x(3)
>>>>> call random_init(.true., .false.)
>>>>> call random_number(x)
>>>>> write(*,'(3F15.7)') x
>>>>> end program foo
>>>>>
>>>>> % gfcx -o z c.f90
>>>>> % ./z
>>>>> 0.9166497 0.0343677 0.9250018
>>>>> % ./z
>>>>> 0.3294057 0.3634282 0.6506106
>>>>> % ./z
>>>>> 0.8441532 0.5690981 0.7679952
>>>>>
>>>>> but, is this what a user expects and wants? As the person that
>>>>> made 'call RANDOM_SEED()' return the same sequence of RN with
>>>>> gfortran, I am well aware that a number of users were unhappy
>>>>> because other vendors choose a different behavior.
>>>>>
>>>> _______________________________________________
>>>> J3 mailing list
>>>> J3 at mailman.j3-fortran.org
>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>
>>> --
>>> Steve
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at mailman.j3-fortran.org
>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>
>> Bill Long longb at cray.com
>> Principal Engineer, Fortran Technical Support & voice: 651-605-9024
>> Bioinformatics Software Development fax: 651-605-9143
>> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
>>
>>
>> _______________________________________________
>> 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
Principal Engineer, Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9143
Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
More information about the J3
mailing list