Random number generators
in [Fortran]
|
Prev: pointer and allocatable arrays
Next: f95 to windows dll
From: Richard Maine on 17 Nov 2009 21:42 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: [about the Fortran standard's random number generator spec] > Well, if I wrote the standard I would have had different options > for restoring and initial seeding. Of course, that assumes that you sucessfully got your intention into the written words. :-( The person who did mostly write the random number part of the standard claimed that he had intended to specify things about the issue of when the initial seed was the same for each run and when it was different, but he accidentally failed to put his intent into the written words. I take that as a precautionary tale worth noting - something about good ideas not being worth much if you don't manage to communicate them. (No, I'm not meaning to imply anything about posts or people in this thread; it is just a more general precautionary tale that the thread brought to mind.) I don't actually recall what the intended specification was because the answer to an interp request basically said that his unstated (and thus undiscussed in committee) intent did not matter and that the words of the standard ruled instead. Those words are the ones that allowed the choice to be vendor-dependent. Different vendors had already implemented different choices in released compilers before the interpretation request came back. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: David Jones on 18 Nov 2009 05:21 steve wrote: > On Nov 16, 6:04 pm, frank <fr...(a)example.invalid> wrote: >> On Mon, 16 Nov 2009 16:05:14 -0800, steve wrote: >>>> I have a question regarding the subroutine RANDOM_NUMBER, does it >>>> generate a list of uniformly distributed numbers, between 0 and 1, >>>> and an average of 0.5? >> >>> The description for RANDOM_NUMBER is given in 13.14.85 of the >>> Fortran 95 standard. It states >> >>> Description. Returns one pseudorandom number or an array of >>> pseudorandom numbers from the uniform distribution over the range 0 >>> <= x < 1. >> >>> Note, it says nothing about an average of 0.5. If you only draw 2 >>> values from the distribution is highly unlikely that the average is >>> 0.5. OTOH, if you draw hundred or thousands or millions of samples, >>> then >>> the average will be near 0.5. >> >> Isn't there an asymmetry in the unit interval though as to which >> endpoint is included? So if there's N outcomes on one side of .5 >> there would be N +-1 on the other. > > Can you restate your question without a little more detail? <snip> The point centres on the explicit statement of the range in the standard as 0<= x < 1. Thus an exact value of zero is allowed as an output. while an exact value of one is not. So there is asymmetry on this point. For some uses, the question of whether or not exact zeroes and ones are ever returned is important and is sometimes addressed by testing for such values and re-generating another as necessary. Obviously such testing should be avoided if the zero or one case is guaranteed not to occur. Random number generators are such as to naturally include zero as a possible output, and to avoid this would involve slowing the code down. A description of a RNG should explicity state the range and discretisation of the values that might be reurned, so that it would be possible to see whether just rejecting zero values would leave the set of allowed values symmetric about zero. David Jones
From: glen herrmannsfeldt on 18 Nov 2009 07:03 David Jones <dajxxxx(a)ceh.ac.uk> wrote: > steve wrote: >> On Nov 16, 6:04 pm, frank <fr...(a)example.invalid> wrote: (snip) >>> Isn't there an asymmetry in the unit interval though as to which >>> endpoint is included? So if there's N outcomes on one side of .5 >>> there would be N +-1 on the other. >> Can you restate your question without a little more detail? > <snip> > The point centres on the explicit statement of the range in the > standard as 0<= x < 1. Thus an exact value of zero is allowed > as an output. while an exact value of one is not. So there is > asymmetry on this point. For some uses, the question of whether > or not exact zeroes and ones are ever returned is important and > is sometimes addressed by testing for such values and re-generating > another as necessary. Obviously such testing should be avoided if > the zero or one case is guaranteed not to occur. Random number > generators are such as to naturally include zero as a possible > output, and to avoid this would involve slowing the code down. Consider a true random number generator (not a pseudo-random number generator, as is usually used) generating an IEEE double with a 53 bit significand generating uniformly 2**53 possible values, 0<=x<1. The expected standard deviation of the mean after averaging N values is 1/sqrt(N). To notice a deviation of 1 in 2**53, the offset due to the asymmetry, requires N of about 2**104, or about 1e31. At 1GHz, that takes 1e22 seconds, or, if I did it right, about 6e14 years. Good PRNG generate enough additional bits internally that it will be about as hard to notice. > A description of a RNG should explicity state the range and > discretisation of the values that might be reurned, so that > it would be possible to see whether just rejecting zero values > would leave the set of allowed values symmetric about zero. If processor speeds double every year for the next 100 years then you might have a chance to notice. If by then the generators switch to a longer return value then you won't. -- glen
From: Ron Shepard on 18 Nov 2009 15:05 In article <ab2053c6-0fcf-4c46-ac07-e67c192630a3(a)i12g2000prg.googlegroups.com>, steve <kargls(a)comcast.net> wrote: > Note, there are numerous Fortran implementations of PRNG. Try > searching on 'metcalf KISS' and 'ranlux' to name just two. There > are others. As always, you should test whatever PRNG you choose > to determine if it is adequate for your application. Most of my applications involving random numbers do not place stringent requirements on the PRNG. Almost anything would work in these situations. If I do something more sophisticated that does require long cycles, etc., then I would use ranlux or something similar where I knew the algorithm and could verify that it met whatever requirements where necessary. The fortran standard does not specify very much about the intrinsic PRNG, RANDOM_NUMBER(). But if it did, then what kind of requirements should it meet? What are the most commonly needed requirements? Should it be required to have a cycle that is at least as long as the number of floating point numbers between 0 and 1, or should it be allowed to be restricted only to the number of values with a fixed exponent? What kind of restrictions might be imposed on correlations between the numbers that are generated? $.02 -Ron Shepard
From: Ron Shepard on 18 Nov 2009 15:10
In article <7meelsF3g7qejU1(a)mid.individual.net>, frank <frank(a)example.invalid> wrote: > Isn't there an asymmetry in the unit interval though as to which endpoint > is included? So if there's N outcomes on one side of .5 there would be N > +-1 on the other. There are more floating point values between 0 and .5 than there are between .5 and 1. It is not just a difference of +-1 value. Should all such values occur in the pseudorandom sequence, or only a subset of such values? $.02 -Ron Shepard |