KISS4691, a potentially top-ranked RNG.
in [Fortran]
|
Prev: solutions book
Next: real kind declaration
From: robin on 30 Jul 2010 10:11 "Uno" <merrilljensen(a)q.com> wrote in message news:8beshqFmk7U1(a)mid.individual.net... | I think of 3.5 billion as a value that busts types in C. I would have | thought that was going on except for the second error: It doesn't "bust" types in C, because it is a valid unsigned number for a 32-bit machine. | geo1.f90:72.32: | | unsigned_result = 2224631993 | 1 | Error: Integer too big for its kind at (1). This check can be disabled | with the option -fno-range-check Same as above. It's valid unsigned number.
From: Ron Shepard on 30 Jul 2010 12:04 In article <i2tvn7$ldf$1(a)smaug.linux.pwf.cam.ac.uk>, nmm1(a)cam.ac.uk wrote: > In article <ron-shepard-969C9C.22130629072010(a)news60.forteinc.com>, > Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: > >In article <i2ssst$nfi$1(a)speranza.aioe.org>, > > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > > >> In a large fraction of the cases, 2 billion different seeds > >> are enough, but one can still desire the appropriate randomness > >> from those different seeds. > > > >My understanding is that pseudorandom number generators return a > >sequence of values with some period. The numbers in that sequence > >eventually repeat with some, hopefully long, cycle. The put=array > >argument gives the starting point within that sequence, but it doesn't > >affect the cycle length or the "randomness" of the values, those things > >are determined by the underlying algorithm, not by the initial seed. > > > >The situation that needs to be avoided is to run the code once with one > >seed, and then run it again with another seed that results in an overlap > >of the sequences of values for the two runs. In some applications this > >is unimportant, but in other applications it would be bad for two > >supposedly independent runs to have a long sequence of identical values. > > No, no, a thousand times, NO! That is NOT enough, though FAR too many > Web pages, published papers and books claim that it is. Disjointness > isn't even a poor relation of randomness. That may be correct, but without specifying the PRNG algorithm, that may be all that could be expected for a "good" choice of initial seeds. I guess my earlier question wasn't clear enough, so I will try to rephrase it. What I'm looking for is whether there is a practical way to define a subroutine like call RANDOM_NEW_SEED( old_seed, n, new_seed ) new_seed(:) and old_seed(:) are integer arrays of the appropriate length for the (unspecified) PRNG algorithm. old_seed(:) was some old seed that was used elsewhere, perhaps in some previous execution of the same code, or perhaps in some other initialization of the PRNG on another node of a parallel machine. The integer n is the number of values that will be generated, or some estimate thereof. new_seed(:) is the new seed that is guaranteed to result in a sequence of values that do not overlap with the previous run (assuming the cycle length is long enough, of course). I guess one might be able to impose other conditions on the values that will be generated, such as those you mention, but again, without actually specifying the PRNG algorithm, it isn't clear to me how that could be done generally. > Parallel random number generation is not easy, and 99% of the stuff > published on it is somewhere between grossly misleading and complete > nonsense. I think in the parallel case, one would want to be able to generate a seed to produce values that are guaranteed not to overlap with any other node. Maybe something like call RANDOM_NEW_SEED( old_seed, n, new_seed, my_node ) would be a sufficient interface. new_seed(:) would depend on my_node in such a way that the generated sequence would not overlap with that produced by any other possible value of my_node (again, assuming the cycle length is long enough to satisfy that request). $.02 -Ron Shepard
From: Gib Bogle on 30 Jul 2010 20:49 P.S. I'm still hoping to hear from George, either telling me that the difference between the C-generated and Fortran-generated sequences is immaterial (from the randomness point of view), or how to make the Fortran work in exactly the same way as the C code. Anyone else is free to contribute in his place ...
From: orz on 30 Jul 2010 21:34 On Jul 29, 12:28 pm, Uno <merrilljen...(a)q.com> wrote: > glen herrmannsfeldt wrote: > > In comp.lang.fortran n...(a)cam.ac.uk wrote: > >> In article <fa9dd141-823a-4179-a80b-18d214a3e...(a)t2g2000yqe.googlegroups.com>, > >> Harald Anlauf <anlauf.2...(a)arcor.de> wrote: > > (snip) > > >>> Does this mean that using different seeds will lead to > >>> streams that are always statistically independent > >>> (as long as one does not exhaust the RNG's period)? > >>> Or are there restrictions on the possible combinations > >>> of seeds? > > >> No. Without checking it more carefully, I can't say definitely, > >> but it looks as if you would be very unlikely to notice a PRACTICAL > >> association with two different seeds, provided that you throw > >> away the first 10,000 or so numbers - and even that qualification > >> may be unnecessary. But, unless I have some missed some subtlety, > >> the sequences cannot be guaranteed to be pseudo-independent. > > > My biggest complaint about the current standard RANDOM_SEED > > is that it doens't provide a way to get a reliably good > > seed from a default (likely 32 bit) integer. > > > There are many generators with extrememly long periods, > > and correspondingly long state. As the designers of the RNG > > are the ones likely to know how to choose a good seed, it > > would seem they would be the best ones to supply a good > > seed generator. > > >> The only two methods I know of of guaranteeing pseudo-independence > >> are using coprime sequences and by choosing them using the spectral > >> test or equivalent. Even then, there are some qualifications on > >> what is meant by pseudo-independence. However, in practice, it's > >> rare to have trouble with high-quality generators. > > > Now, one can supply an array of the appropriate length to > > RANDOM_SEED(PUT=...), but how to generate such an array > > from a smaller seed? There is no way to know. > > So for the put= values in fortran, you need a vector of pseudorandom > integers, which is as good as it gets without truly random devices, > making--one hopes-a period that is large with respect to the interval > you're interested in. > > It doesn't seem like a problem with epistemology as much a mathematical > ceiling on how much randomness you can create by a handful of values. > -- > Uno I think you have part of it backwards: elseif (x < 0) then tLTx = 1 elseif (t < 0) then tLTx = 0 endif should be: elseif (x < 0) then tLTx = 0 elseif (t < 0) then tLTx = 1 endif ....if you want to produce an sequence of numbers identical to his C code. Though the way you have it written produces significantly higher quality output according to some statistical tests. Another issue to worry about is the rightshift must be an unsigned rightshift, but a quick googling suggests that fortran ISHFT is unsigned anyway.
From: orz on 30 Jul 2010 21:35
Whoops, I quoted the wrong previous post in my reply... that was intended to be a reply to Gib Bogle's most recent post. |