Re: Random Numbers



dpb <dpbozarth@xxxxxxxx> wrote:

Calling RANDOM_SEED w/o any arguments resets the seed based on the
current CPU date and time.

That is *NOT* guaranteed by the standard. The standard just says that it
assigns a processor-dependent seed. There is no requirement or even
implication that it is based on the data and time. I think that might
have been the intent of the original author of that part of the
standard; I think I recall him once saying so. But unfortunately, he
didn't manage to write it down that way or even communicate that to the
rest of the committee. By the time he noticed that the written words
didn't say what he intended, it was way too late because multiple
implementations had followed what was actually written in the standard.
There's a lesson somewhere in here about technical writing. Some (maybe
even most; I don't have all the data handy) compilers do it that way. I
regard that as desireable behavior, but it is not guaranteed. You could
well find that it is set to the same starting seed each time, which
isn't at all what you want.

The two most popular methods of assuring that you get a new seed eith
each run are:

1. Set the starting seed yourself based on date/time. See the
date_and_time and random_seed intrinsics in any text. It isn't hard to
throw together something using those two intrinsics, and for the
described purpose, you aren't likely to be too picky about the
statistical properties.

2. Save the seed to a file somewhere. Initialize the seed from the file
when you start (with a default action in case the file doesn't exist).
Save the latest seed to the file when you terminate (or after you are
otherwise done with it for a run). This does require access to the file,
which might be an issue if multiple people are running the program.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.



Relevant Pages

  • Re: [gfortran43] opening file twice...
    ... The odds of the standard talking specifically about disk files seem... ... "availability of multiple file connections is system dependent by type ... multiple connections in the language standard. ...
    (comp.lang.fortran)
  • Re: Help understanding audio sampling
    ... And of course multiple high components will make resultant tones or beats in the audible range. ... In all other situations, 48KHz is the minimum accceptable srate (with 24bit samples being also preferred, not least so engineers can employ more pseudo-analog headroom above the nominal 0dB mark). ... So for all formats other than the technically obsolete CD, the new standard is at least 24/48, with 24/96 increasingly popular for audio DVD combined with lossless data compression. ...
    (comp.dsp)
  • Re: [gfortran43] opening file twice...
    ... The odds of the standard talking specifically about disk files seem... ... "availability of multiple file connections is system dependent by type ... multiple connections in the language standard. ...
    (comp.lang.fortran)
  • Re: AVR Harvard architecture -- worst of both worlds?
    ... I haven't read through the new standard yet, but it will be good to get ... sale that view ISO C90 as the bees knees. ... memory, and it could give you conflicts if the bus is shared with other ... ISO 18037 has multiple sections. ...
    (comp.arch.embedded)
  • Re: AVR Harvard architecture -- worst of both worlds?
    ... ISO/IEC 18037 adds named address space that makes multiple ... It is not a standard, it is a Technical Report so it can safely be ignored. ... portability is certainly not assured. ... a common way to specify interrupt functions and other non-standard ABI ...
    (comp.arch.embedded)