KISS4691, a potentially top-ranked RNG.
in [Math]
|
From: Gib Bogle on 30 Jul 2010 00:56 Uno wrote: > Gib Bogle wrote: > >> OK, here's the Fortran. I've removed almost all the comments to save >> space. >> If you uncomment the line in MWC(): >> c = c_this_works >> you'll see how to reproduce the C code results. > > Alright, thx, gib, looks like there's a couple rough corners: > > $ gfortran geo1.f90 -o out > geo1.f90:63.32: > > unsigned_result = 3740121002 > 1 > Error: Integer too big for its kind at (1). This check can be disabled > with the option -fno-range-check > > So, do I ask for something bigger than the default integer, use the > iso_c_binding, or disable the warning? > > 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: > > 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 > > > Then there's this. It looks like the bitshifting capabilities that > fortran and C have, but neither MR&C nor my slightly-inappropriate C > reference have a SHIFTL. Do you have a definition for it? > geo1.f90:55.16: > > xs = XOR(xs,SHIFTL(xs,13)) > 1 > Error: Function 'shiftl' at (1) has no IMPLICIT type > > Beautiful night with the cicadas humming. I don't know that I've ever > seen one which makes them, aesthetically, my favorite bug. Cheers, Uno, the only reason for putting those lines in with unsigned_integer is to show that the result that you see when x is written is actually the same as the C-generated number. The Intel Fortran compiler is happy with the code, not even issuing a warning. I suggest using -fno-range-check, or alternatively subtract 2^31 from the big numbers (I think). Or you could just take my word for it. I didn't realize that SHIFTL and SHIFTR were not standard Fortran. You can use ISHFT: result = ISHFT (i,shift) i (Input) Must be of type integer. shift (Input) Must be of type integer. The absolute value for shift must be less than or equal to BIT_SIZE( i). Results The result type is the same as i. The result has the value obtained by shifting the bits of i by shift positions. If shift is positive, the shift is to the left; if shift is negative, the shift is to the right. If shift is zero, no shift is performed. Bits shifted out from the left or from the right, as appropriate, are lost. Zeros are shifted in from the opposite end. ISHFT with a positive shift can also be specified as LSHIFT (or LSHFT). ISHFT with a negative shift can also be specified as RSHIFT (or RSHFT)with | shift |. I'm very surprised to hear you say you've never seen a cicada. In the summer they are impossible to miss here. Sparrows catch them on the wing. But what you are hearing at night are not cicadas, I think. As far I know they are active only in daylight hours. The night shift (here) is taken by crickets, whose song I find very musical. You don't get to see them much. They tend to hide in cracks in the ground, which open up in the dry season. Sometimes crickets come inside, black ones here.
From: glen herrmannsfeldt on 30 Jul 2010 02:28 In comp.lang.fortran Gib Bogle <g.bogle(a)auckland.no.spam.ac.nz> wrote: (snip) >> unsigned_result = 3740121002 1 >> Error: Integer too big for its kind at (1). This check can be disabled >> with the option -fno-range-check You can subtract 2**32, or find two values to IOR together. (And remember that this is all twos-complement specific.) -- glen
From: glen herrmannsfeldt on 30 Jul 2010 02:37 In comp.lang.fortran orz <cdhorz(a)gmail.com> wrote: (snip) > If an RNG has a large number of possible states (say, 2^192) then it's > unlikely for any two runs to EVER reach identical states by any means > other than starting from the same seed. This RNG has a period vastly > in excess of "large", so for practical purposes it just won't > happen. That is true, but there are some assumptions. Since the standard doesn't say much at all about the underlying algorithm, it isn't so reliable a statement as it seems. For one, many PRNGs have poor performance with some starting seeds, or poor performance for some cycles, especially as viewed from the low bits. > However, because this is a combination of multiple component RNGs > there is the related issue of overlapping within the period of one or > more component RNGs. MWC has essentially zero chance of being in an > identical state for any reason other than identical seeding, but both > XS and CNG will frequently have identical states in two different > runs. There does not seem to be any detectable correlation however > unless (either MWC or (both XS and CNG)) have identical states between > two different runs. Which is rather uncommon, though it does happen > often enough to see it in the real world on occasion. My previous comments were regarding the Fortran standard RANDOM_SEED routine. I haven't thought about the seeding of the RNG recently mentioned here. -- glen
From: Gib Bogle on 30 Jul 2010 02:39 glen herrmannsfeldt wrote: > In comp.lang.fortran Gib Bogle <g.bogle(a)auckland.no.spam.ac.nz> wrote: > (snip) > >>> unsigned_result = 3740121002 > 1 >>> Error: Integer too big for its kind at (1). This check can be disabled >>> with the option -fno-range-check > > You can subtract 2**32, or find two values to IOR together. > (And remember that this is all twos-complement specific.) Ah, of course.
From: nmm1 on 30 Jul 2010 03:41
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. This is easiest to see with a simple multiplicative congruential generator, but many classes of generator have similar properties. A sequence can be written as A.B^k, for k = 1...n, where B is fixed by the properties of the generator but A also depends on the seed. Two sequences X1 and X2 will always have the property that A2.X1+A1.X2 = 0 modulo M. So A1 and A2 need to be large and different, but you also need to consider offset sequences - e.g. with A2 replaced by A2.B^p, for all values of p < n. The spectral test theory tells you that you will always have some values of p for which Q2.X1+Q1.X2 = 0 modulo M and both Q1 and Q2 are very small. That's Bad News for many analyses. This problem was a significant driving force behind the development of the highly non-linear algorithms and composite algorithms. Both are resistant to it, and the combination is very resistant. KISS4691 is one such. Parallel random number generation is not easy, and 99% of the stuff published on it is somewhere between grossly misleading and complete nonsense. Regards, Nick Maclaren. |