Re: Reinitialising random number generator

On 22 mei, 16:46, Dave Seaman <dsea...@xxxxxxxxxxxx> wrote:
On Thu, 22 May 2008 05:23:42 -0700 (PDT), Arjen Markus wrote:

I interpreted it as meaning that the _code_ of the
example is standard Fortran 95, but if the _method_ is
standard as well, then that is very useful indeed.

I don't know what you mean by that.  The statement

        CALL RANDOM_SEED(PUT = seed)

has an implementation-defined meaning.  Different processors may treat
the PUT array in different ways, even if the size happens to be the same.

(I had not seen documentation of the seeding before - I always
assumed that it was left to the implementors of the compiler,
hence the contents of the array used for seeding should be
treated as opaque.)

The contents of the PUT array is under the programmer's control, as long
as it is a default integer array of rank one and has the correct size, as
determined by a previous call.  However, the exact way the array is
treated by the call is up to the implementor.


Okay, to make this as explicit as I can:
- The code in the documentation for gfortran (this
routine init_random_seed) is standard Fortran 95.
- The code has a meaning that is specific to gfortran, though:
the way it uses the system clock as an initialisation parameter
is specific to gfortran
- From Thomas's posting I conclude that this method is likely
but not guaranteed to produce (very) reasonable results
for other compilers as well.

I may reiterating previous postings here, but in my opinion
it is important to make it very clear what is meant (at least
it is to me :)).

It is the finer details (too fine?) that are at stake here.

My question was inspired by a part of my Flibs project
- http://flibs.sf.net - that intends to provide a set
of programs that test various aspects of Fortran,
those aspects that allow the implementor of a compiler
some freedom. They can influence the portability of
a program.

In the case of random numbers, there are these aspects:
- The quality and variation of the implementation of the PRNG.
Solvable by using a custom PRNG [*], but that is not always
required and it might be slower than.
- Whether a PRNG always produces the same sequence or whether
at start-up some randomisation is taking place. Knowing
that this variation exists can be important for the
success of a program.
- If it is necessary to set the PRNG to a specific sequence
(so as to guarantee repeatability of the run), how to do
that?

[*] Custom PRNGs are by no means trivial. I would only recommend
well-known and well-tested algorithms and implementations.
Especially since I am not an expert on PRNGs at all - one
reason to rely on the builtin one too :).

Oh dear, this post has become rather long ... time to finish it.

Regards,

Arjen

.

Relevant Pages

  • Re: [Q] how to type case from POSITION to int?
    ... // nothing left in the array ... this only makes sense if you really ARE the implementor of an abstraction that ... MVP Tips: http://www.flounder.com/mvp_tips.htm ...
    (microsoft.public.vc.mfc)
  • Re: Choose k random lines from file
    ... >> Well, no, it's not true that there is no such algorithm, at least if I ... I meant N-N' times (for a PRNG of course). ... the two specifies an array index. ... The cost is bounded ...
    (comp.programming)
  • Re: Q: Algorithm M vs. P of Knuths book
    ... >>more random by shuffling it through an array according to Algorithm M of Knuth ... > PRNG, then outputs them in a scrambled order. ...
    (comp.programming)
  • Re: [] [] eq => true??
    ... makes no difference between dictionaries and arrays in the definition ... array 1 array eq ... these will clearly be the same pointer (since there is only one array ... (But an implementor MIGHT do it anyway). ...
    (comp.lang.postscript)
  • Re: Q: Algorithm M vs. P of Knuths book
    ... > more random by shuffling it through an array according to Algorithm M of Knuth ... PRNG, then outputs them in a scrambled order. ...
    (comp.programming)