Random number generators
in [Fortran]
|
Prev: pointer and allocatable arrays
Next: f95 to windows dll
From: Maciej Marek on 17 Nov 2009 14:58 Gordon Sande writes: > The standard is even less demanding than that as it says absolutely > nothing about the quality of the random numbers. If it always > returned 0.33 it would be standard conforming and under some definitions > of randomness as surprise it would even be of high quality because > such a sequence would be highly surprising. ;-) It would surely draw > many user complaints about the poor quality of implementation. That reminds me a Dilbert strip: - And here's our random number generator. - 9,9,9,9,9,9,9,9.... - Are you sure that's random? - That's the problem with randomness. You can never be sure. Regards, Maciej Marek
From: steve on 17 Nov 2009 15:24 On Nov 17, 11:32 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > steve <kar...(a)comcast.net> wrote: > > (snip, I wrote) > > >> It would be nice to have a way to generate a good seed based > >> on a single default kind integer. ?Again, duplicating to fill > >> the seed array is likely not the best choice. > > gfortran's random_seed() in principle has a mechanism in > > place to help prevent a user from making a bad choice of > > seeds. Whether the mechanism is effective, I do not know. > > How does it know if it is a user supplied seed value, or a > previously stored seed from RANDOM_SEED? I think what I would > most like to see is separate ways for restoring a previous seed > and specifying a new seed. For a new seed, the routine should > generate a good seed based on user supplied data. When restoring > a seed, it should not be changed. With the assumption that all > seed values are possible, there is no way to tell the difference. > > I suppose one could put a CRC on the stored seed, and test it > on reloading. For a given CRC size, that makes it very unlikely > to be accidentally specified by the user. I don't understand your question. A call to random_seed() manipulates the seeds and then initializes the prng. A call to random_number() simply uses the current values. http://gcc.gnu.org/ml/fortran/2008-02/msg00261.html
From: glen herrmannsfeldt on 17 Nov 2009 16:05 steve <kargls(a)comcast.net> wrote: (snip) > I don't understand your question. A call to random_seed() > manipulates the seeds and then initializes the prng. A call > to random_number() simply uses the current values. There are two ways random_seed(put=...) can be used: 1) Initialize the seed based on some user supplied data. (Constant, time of day, phase of moon, etc.) 2) Restore a seed previously retrieved using random_seed(get=...) In the first case, the supplied data should be used to generate a good quality seed. In the second case, the data should be used as-is, such that a previous seed is restored exactly. I have done problems before where I needed to restart part way though, and verify that the results were the same as previous. (That was in R, which does have separate restore seed and initial seed options.) How do you determine if case 1 or case 2 applies? -- glen
From: steve on 17 Nov 2009 16:27 On Nov 17, 1:05 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > steve <kar...(a)comcast.net> wrote: > > (snip) > > > I don't understand your question. A call to random_seed() > > manipulates the seeds and then initializes the prng. A call > > to random_number() simply uses the current values. > > There are two ways random_seed(put=...) can be used: > > 1) Initialize the seed based on some user supplied data. > (Constant, time of day, phase of moon, etc.) > > 2) Restore a seed previously retrieved using random_seed(get=...) > > In the first case, the supplied data should be used to generate > a good quality seed. In the second case, the data should be used > as-is, such that a previous seed is restored exactly. > > I have done problems before where I needed to restart part way > though, and verify that the results were the same as previous. > (That was in R, which does have separate restore seed and initial > seed options.) > > How do you determine if case 1 or case 2 applies? > It appears as if you did not read the message in the fortran @ gnu mailing list archive that I pointed you at with URL. Your question doesn't make sense (to me). Random_seed() scrambles the seeds when called with PUT= and it unscrambles the seeds when called with GET=. If called with no argument, the default set of seeds isused. You can use GET= and PUT= with the default set of seeds, but the scrambling and unscrambling of the seeds still occurs. For more details, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812
From: glen herrmannsfeldt on 17 Nov 2009 16:56
steve <kargls(a)comcast.net> wrote: (snip, I wrote) >> There are two ways random_seed(put=...) can be used: >> 1) Initialize the seed based on some user supplied data. >> ? ?(Constant, time of day, phase of moon, etc.) >> 2) Restore a seed previously retrieved using random_seed(get=...) >> In the first case, the supplied data should be used to generate >> a good quality seed. ?In the second case, the data should be used >> as-is, such that a previous seed is restored exactly. (snip) > It appears as if you did not read the message in the fortran @ gnu > mailing list archive that I pointed you at with URL. Your question > doesn't make sense (to me). Random_seed() scrambles the seeds > when called with PUT= and it unscrambles the seeds when called > with GET=. If called with no argument, the default set of seeds > isused. You can use GET= and PUT= with the default set of seeds, > but the scrambling and unscrambling of the seeds still occurs. > For more details, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812 To quote from the mentioned site: "This doesn't make miracles (i.e. provide you with a good seed when you input a particularly poor one), but at least it makes using the VALUES of DATE_AND_TIME less frustrating (by generating visibly different streams of PRN)." It would be nice to have high quality seeds for all possible values of DATE_AND_TIME when used to generate seeds. Different generators have different requirements on what makes a good seed. I suppose I agree that for a sufficient amount of scrambling it works, assuming the scrambling can be inverted. -- glen |