On Dec 5, 2:32 pm, "Mark H." <[EMAIL PROTECTED]> wrote: > On Dec 4, 12:07 am, "don.aman" <[EMAIL PROTECTED]> wrote: > > > Since we're being all high-level, it'd be good for a random function > > which allows us to specify the range of numbers, since % doesn't > > promise an even spread of probabilities (especially for large ranges). > > Sure it does, as long as you get enough random bits that scaling the > output of the number to an arbitrary range doesn't lose more random > bits than it promises to give. It's not the PRNG's responsibility to > do that, it's the responsibility of the function doing the scaling. > Furthermore, if you're in floating-point arithmetic, then scaling by > powers of two doesn't lose any bits as long as the numbers don't > overflow or underflow. You'll lose a bit or two from going from the > powers of two to the range you want, but you can always get a few > extra random bits to account for that if you're concerned.
btw this suggests an interface analogous to Java's separation of "streams" and "readers" for I/O. In this case, a "stream" would be a source of uniformly distributed bits, and a "reader" would be the particular range (addressing your concern above, which could be a problem for bignum ranges if people don't know to take enough random bits) and distribution (uniform, gaussian, etc.). Both Intel's MKL and AMD's ACML use this style of interface in their PRNG libraries: http://www.intel.com/cd/software/products/asmo-na/eng/307757.htm http://developer.amd.com/cpu/libraries/acml/Pages/default.aspx A reader may take more or less elements from the stream than it produces in this case: for example, Knuth's "reader" producing Gaussian pseudorandom numbers alternates between taking two uniformly distributed numbers and taking none. Thus the reader should tell users its expected period, which could be different than the period of the underlying stream. Fun fact: in 2007, use of a linear congruential PRNG with an unlucky choice of input size caused the LINPACK benchmark to crash (unnecessarily) on a huge supercomputer after wasting 20 hours of compute time: http://www.netlib.org/lapack/lawnspdf/lawn206.pdf (There's a nice analysis in the paper.) mfh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
