(j3.2006) What does "same image" mean?
John Reid
John.Reid
Thu Feb 22 06:05:27 EST 2018
Steve Lionel wrote:
> 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.
I think we have this covered. The "processor" is defined (3.113) as the
"combination of a computing system and mechanism by which programs are
transformed for use on that computing system". I think this means that
any change to the compiler means that the processor has changed.
> 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.)
I think the current words cover the case of multiple calls within a
single program.
>
> It is not clear to me that we have sufficient terms in the standard to
> describe this the way we want.
Do you have any suggestions? I am not wedded to the words I suggested.
Cheers,
John.
>
> Steve
>
> On Wed, Feb 21, 2018 at 2:14 PM, John Reid <John.Reid at stfc.ac.uk
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto:J3 at mailman.j3-fortran.org>
> http://mailman.j3-fortran.org/mailman/listinfo/j3 <http://mailman.j3-fortran.org/mailman/listinfo/j3>
>
>
> --
> Steve
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> <mailto:J3 at mailman.j3-fortran.org>
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> <http://mailman.j3-fortran.org/mailman/listinfo/j3>
>
>
> Bill Long
> longb at cray.com
> <mailto:longb at cray.com>
> Principal Engineer, Fortran Technical Support &
> voice: 651-605-9024 <tel:651-605-9024>
> Bioinformatics Software Development
> fax: 651-605-9143 <tel:651-605-9143>
> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington,
> MN 55425
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org <mailto:J3 at mailman.j3-fortran.org>
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> <http://mailman.j3-fortran.org/mailman/listinfo/j3>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org <mailto:J3 at mailman.j3-fortran.org>
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> <http://mailman.j3-fortran.org/mailman/listinfo/j3>
>
>
> Bill Long
> longb at cray.com <mailto:longb at cray.com>
> Principal Engineer, Fortran Technical Support & voice:
> 651-605-9024 <tel:651-605-9024>
> Bioinformatics Software Development fax:
> 651-605-9143 <tel:651-605-9143>
> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org <mailto:J3 at mailman.j3-fortran.org>
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> <http://mailman.j3-fortran.org/mailman/listinfo/j3>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org <mailto:J3 at mailman.j3-fortran.org>
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> <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
>
More information about the J3
mailing list