(j3.2006) What does "same image" mean?
Steve Lionel
steve
Wed Feb 21 17:15:02 EST 2018
We need to be careful not to prevent an implementer from changing or
improving their random number generator. If we're not careful, the
standard's words could be interpreted as requiring that a given processor
(compiler) always initializes to the same sequence, forever and ever. The
thing we want to get across is that executing the SAME program repeatedly
will get the same sequence. But that's not all - if the program calls
RANDOM_INIT with REPEATABLE=.TRUE. multiple times (in the same image if
IMAGE_DISTINCT is also .TRUE.), the sequence starts over at the same point.
It's not JUST about running the program multiple times (though that is the
primary case of interest.)
It is not clear to me that we have sufficient terms in the standard to
describe this the way we want.
Steve
On Wed, Feb 21, 2018 at 2:14 PM, John Reid <John.Reid at stfc.ac.uk> wrote:
>
>
> Bill Long wrote:
>
>> ?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.}
>>
>
> Yes, we do. It qualifies "every execution". It says that when you do
> another run on the same processor, you get the same value.
>
> Otherwise, I am happy with your suggestions.
>
> Cheers,
>
> John.
>
>
>
>> 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
>>
>>
>> _______________________________________________
>> 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
>
--
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.j3-fortran.org/pipermail/j3/attachments/20180221/0f3c0d88/attachment-0001.html>
More information about the J3
mailing list