Random number in Fortran 90/95
in [Fortran]
|
From: Allamarein on 20 Jun 2010 05:28 I found this code: PROGRAM ranseed IMPLICIT NONE ! ----- variables for portable seed setting ----- INTEGER :: i_seed INTEGER, DIMENSION(:), ALLOCATABLE :: a_seed INTEGER, DIMENSION(1:8) :: dt_seed ! ----- end of variables for seed setting ----- REAL :: r ! ----- Set up random seed portably ----- CALL RANDOM_SEED(size=i_seed) ALLOCATE(a_seed(1:i_seed)) CALL RANDOM_SEED(get=a_seed) CALL DATE_AND_TIME(values=dt_seed) a_seed(i_seed)=dt_seed(8); a_seed(1)=dt_seed(8)*dt_seed(7)*dt_seed(6) CALL RANDOM_SEED(put=a_seed) DEALLOCATE(a_seed) ! ----- Done setting up random seed ----- CALL RANDOM_NUMBER(r) WRITE(6,*) 'random number is ',r END PROGRAM ranseed If I didn't misunderstand the code registers the seed in vector *a_seed* (in my case SIZE=4, hence *i_seed* = 4) Then it replaces the first and last position of the original seed with a muddle coming from my clock. Therefore I should have a different seed at each run and afterwards a different random number. Have I realized?
From: steve on 20 Jun 2010 12:27 On Jun 20, 2:28 am, Allamarein <matteo.diplom...(a)gmail.com> wrote: > ! ----- Set up random seed portably ----- > CALL RANDOM_SEED(size=i_seed) > ALLOCATE(a_seed(1:i_seed)) > CALL RANDOM_SEED(get=a_seed) > CALL DATE_AND_TIME(values=dt_seed) > a_seed(i_seed)=dt_seed(8); > a_seed(1)=dt_seed(8)*dt_seed(7)*dt_seed(6) > CALL RANDOM_SEED(put=a_seed) > DEALLOCATE(a_seed) > If I didn't misunderstand the code registers the seed in vector > *a_seed* (in my case SIZE=4, hence *i_seed* = 4) > Then it replaces the first and last position of the original seed with > a muddle coming from my clock. > Therefore I should have a different seed at each run and afterwards a > different random number. > Have I realized? dt_seed(8) will be in the range [0:999]. The product of dt_seed(8)*dt_seed(7)*dt_seed(6) will be the range of [0:3536460]. If the quality of implement of the PRNG in your compiler depends on higher bits in the seeds or has pathlogical behavior for a value of 0, then the above may not produced the desired effect. I would at least add 1 to both to prevent the 0 case, and possibly use the hour, day, and month to increase the ranges and maybe mix in a little system_clock(count). -- steve
From: Gib Bogle on 20 Jun 2010 18:04 Ian Bush wrote: > On 20 June, 08:21, Gib Bogle <g.bo...(a)auckland.no.spam.ac.nz> wrote: >> Allamarein wrote: >>> I would get random (maybe it is more correct 'pseudorandom') numbers >>> with distribution [0,1] >> ... >> For some applications it's useful to specify the seed for the RV generator. >> Then if you record the seed value you can rerun your simulation later, to >> reproduce the results (this doesn't work when multi-processing). > > Nitpick: This MAY not work when multi-processing. It depends on what > you do, and probably the implementation as well, > > Ian True. I thought of that as I wrote, but chose laziness.
From: Uno on 27 Jun 2010 18:07 Richard Maine wrote: > Tobias Burnus <burnus(a)net-b.de> wrote: > >> Well, there are two different philosophies: One is, that one should get >> by default the same sequence of pseudo-random numbers as this makes >> programs more deterministic. The other one is that one always wants to >> have different numbers, matching some "true" random results. >> >> As neither of the choices is better, the standard did not specify what a >> compiler has to do. > > More like because the person who wrote the words in that bit of the > standard was sloppy about making sure that he actually wrote what he > intended to, and the oversight did not get corrected during review. Said > person later tried to fix it by a retroactive "correction" to the > standard, but it was way too late for that, considering that multiple > implementations already were in use and the only data supporting the > claim that this was done in error was his word about his personal > intentions in writing it. > It sounds like an opportunity squandered. I'd be curious what you would like it to have said. In C, random numbers are ints between 0 and RAND_MAX. Keith Thompson writes that it simply underlaid the process that these numbers were to be random. It's not written in their standard anywhere. Do pseudorandoms in fortran have to have a flat pdf on [0,1) according to the fortran standard? -- Uno
From: Richard Maine on 27 Jun 2010 18:57
Uno <merrilljensen(a)q.com> wrote: [about the vagueness in Fortran's definition of random numbers] > It sounds like an opportunity squandered. I'd be curious what you would > like it to have said. I have not bothered to try to craft appropriate words that aren't going to get used. Nor do I plan to. It seems like a pointless exercise. For similar reasons, I haven't even wasted much time in thinking about how I would have liked Fortran's random number stuff to have worked. I don't even recall for sure exactly what the author of the words in the Fortran standard said that he intended. There are at least some arguments on multiple sides (at least 2 - maybe more). The only thing I have to say that is that I would have liked for whatever it said to have been unambiguous. > In C, random numbers are ints between 0 and RAND_MAX. Keith Thompson > writes that it simply underlaid the process that these numbers were to > be random. It's not written in their standard anywhere. Keith is normally more precise than that. I suppose that he might have been sloppy enough to refer to numbers being "random", but that would at least minorly surprise me. I'd guess it more likely that you are misquoting him. Note that "pseudorandom" is not the same thing as "random." > Do pseudorandoms in fortran have to have a flat pdf on [0,1) according > to the fortran standard? Is there some reason you don't just look in the standard or one of the references about it instead of asking me? It isn't as though this particular information isn't in other that the most obvious place or is stated in other than the most obvious manner. I often try to give answers to questions of subtle (or even not-so-subtle) interpretation or of just finding something that is buried in an obscure place in the standard. Those kinds of questions take advantage of my experience/expertise/whatever. But I don't see why I should provide straightforward reading service. If I wanted to make sure that my answer was actually correct, I'd have to go look it up, just like you would. On doing so, I do see that my recollection was correct, but doing the same check as I did is left as an exercise for the student on the principle of teaching him how to fish. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |