Random is not random at startup
Hi, (cc-ing Robert Withers as he seems to be working with cryptography and security... as this seems related and may have some implications, but I am likely wrong about the implications) yesterday I've encountered a very surprising behavior I executed the same script `10 atRandom` on the same image without saving it and got the same output: while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom' done 10 10 10 10 10 10 Not so random⦠not random at all. Apparently the default random generator uses SharedRandom pool, that is initialized only once⦠so every time you start an image you get the EXACT same random seed... I think this is stupid, and I am not sure what are the security implications of this (e.g. when opening an SSL connection⦠having fixed world-wide initial seed seems like an awful, awful idea), but whatever⦠So instead I tried to explicitly specify the Random generator⦠which I can do while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: Random new' done 5 5 5 5 5 Still not random⦠what? while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval 'Random new instVarNamed: #seed' done 426306047 426305545 426305546 426306010 So the seed is different but thanks to the magic of masking the seed, I always get the same first several bits⦠thus the same result for small numbers. So if I actually want what seems like a random value⦠I have to at least once run the generator⦠while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: (Random new next; yourself)' done 7 3 4 9 6 7 Once I start to use it the properties of the algo kick in so it's pseudo-random⦠but I need to run it once to initialize it, which is wtf. My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup? Peter
Thanks for cc-ing me. I don't have much exposure to random, so I am cc-ing the Cryptography list, in hopes they might help. This doesn't very random, you're right. Here were Peter's questions: My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup? Rob On 05/18/2016 07:05 PM, Peter Uhnák wrote:
Hi,
(cc-ing Robert Withers as he seems to be working with cryptography and security... as this seems related and may have some implications, but I am likely wrong about the implications)
yesterday I've encountered a very surprising behavior
I executed the same script `10 atRandom` on the same image without saving it and got the same output:
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom' done 10 10 10 10 10 10
Not so random⦠not random at all.
Apparently the default random generator uses SharedRandom pool, that is initialized only once⦠so every time you start an image you get the EXACT same random seed... I think this is stupid, and I am not sure what are the security implications of this (e.g. when opening an SSL connection⦠having fixed world-wide initial seed seems like an awful, awful idea), but whateverâ¦
So instead I tried to explicitly specify the Random generator⦠which I can do
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: Random new' done 5 5 5 5 5
Still not random⦠what?
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval 'Random new instVarNamed: #seed' done 426306047 426305545 426305546 426306010
So the seed is different but thanks to the magic of masking the seed, I always get the same first several bits⦠thus the same result for small numbers.
So if I actually want what seems like a random value⦠I have to at least once run the generatorâ¦
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: (Random new next; yourself)' done 7 3 4 9 6 7
Once I start to use it the properties of the algo kick in so it's pseudo-random⦠but I need to run it once to initialize it, which is wtf.
My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup?
Peter
Hi Peter, You are absolutely correct. There is a lot that can be done to improve gathering entropy on cryptography. We have discussed this a number of times. At 3DICC use the croquet plugin and #gatherEntropy: by Andreas. That works great for us. We have very specific random needs including replicated randoms. it uses /dev/urandom on linux and MacOS and SystemFunction036 in Advapi32.dll on windows In general you hit on the issue. We should have an implementation for #gatherEntropy: in crypto. It should fire off for seeding PRNG during startup, The makeSeed in UUIDGenerator seems insufficient unless you are on linux. It queries the sound system and then defaults to a time calculation. How good that is for you really depends on your specific needs for random. 1) do we really want to have global fixed seed? [Ron Teitelbaum] No 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value [Ron Teitelbaum] Yes it should call gatherEntropy to seed the PRNG 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup? [Ron Teitelbaum] No we should either implement a proper gatherEntropy method or use SystemFunction036 in Advapi32.dll for windows like we do in CroquetPlugin. Chris previously pointed out the gatherEntropy requirements from http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/dp/0471223573/re... <http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/dp/0471223573/re...> &qid=1385152889&sr=8-1&keywords=schneier+practical+cryptography that would be a good place to start or we should support the croquet plugin method gatherEntropy in cryptography. All the best, Ron Teitelbaum From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Wednesday, May 18, 2016 7:26 PM To: Peter Uhnák; Pharo Development List; Cryptography Mailing List Subject: Re: [Pharo-dev] Random is not random at startup Thanks for cc-ing me. I don't have much exposure to random, so I am cc-ing the Cryptography list, in hopes they might help. This doesn't very random, you're right. Here were Peter's questions: My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup? Rob On 05/18/2016 07:05 PM, Peter Uhnák wrote: Hi, (cc-ing Robert Withers as he seems to be working with cryptography and security... as this seems related and may have some implications, but I am likely wrong about the implications) yesterday I've encountered a very surprising behavior I executed the same script `10 atRandom` on the same image without saving it and got the same output: while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom' done 10 10 10 10 10 10 Not so random⦠not random at all. Apparently the default random generator uses SharedRandom pool, that is initialized only once⦠so every time you start an image you get the EXACT same random seed... I think this is stupid, and I am not sure what are the security implications of this (e.g. when opening an SSL connection⦠having fixed world-wide initial seed seems like an awful, awful idea), but whatever⦠So instead I tried to explicitly specify the Random generator⦠which I can do while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: Random new' done 5 5 5 5 5 Still not random⦠what? while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval 'Random new instVarNamed: #seed' done 426306047 426305545 426305546 426306010 So the seed is different but thanks to the magic of masking the seed, I always get the same first several bits⦠thus the same result for small numbers. So if I actually want what seems like a random value⦠I have to at least once run the generator⦠while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: (Random new next; yourself)' done 7 3 4 9 6 7 Once I start to use it the properties of the algo kick in so it's pseudo-random⦠but I need to run it once to initialize it, which is wtf. My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup? Peter
(Hey Rob, long time no Smalltalk!) I suggest some changes we did in Cuis. First, for Park-Miller you can do a small change to #initialize, insert a hashMultiply somewhere when initializing the seed. I did experiments in Cuis, drawing histograms to see if it looks like a uniform distribution, and ended up doing something like seed _ (Time millisecondClockValue + self identityHash) hashMultiply \\ m Another issue with Random that we addressed in Cuis is related to the bit size of each output. Random>>nextValue returns Floats with 31 random bits (or 30). It doesn't return a uniformly distributed Float between 0 and 1 (some Float values don't have a chance to be output). Similarly, Random>>nextInt: n will not really return an integer between 1 and n if n is large enough, for example (1 << 64) atRandom returns always odd integers (not very random uh). So I suggest to think of Random as a generator of random "bits" or "blocks of bits", and to generate a Float it should actually build it from 52 randomly generated bits (to fill out the mantissa), and nextInt: n should also be implemented from random bits (or chunks of bits). On Wed, May 18, 2016 at 11:25 PM, Robert Withers <robert.w.withers@gmail.com
wrote:
Thanks for cc-ing me. I don't have much exposure to random, so I am cc-ing the Cryptography list, in hopes they might help. This doesn't very random, you're right. Here were Peter's questions:
My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup?
Rob
On 05/18/2016 07:05 PM, Peter Uhnák wrote:
Hi,
(cc-ing Robert Withers as he seems to be working with cryptography and security... as this seems related and may have some implications, but I am likely wrong about the implications)
yesterday I've encountered a very surprising behavior
I executed the same script `10 atRandom` on the same image without saving it and got the same output:
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom' done 10 10 10 10 10 10
Not so random⦠not random at all.
Apparently the default random generator uses SharedRandom pool, that is initialized only once⦠so every time you start an image you get the EXACT same random seed... I think this is stupid, and I am not sure what are the security implications of this (e.g. when opening an SSL connection⦠having fixed world-wide initial seed seems like an awful, awful idea), but whateverâ¦
So instead I tried to explicitly specify the Random generator⦠which I can do
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: Random new' done 5 5 5 5 5
Still not random⦠what?
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval 'Random new instVarNamed: #seed' done 426306047 426305545 426305546 426306010
So the seed is different but thanks to the magic of masking the seed, I always get the same first several bits⦠thus the same result for small numbers.
So if I actually want what seems like a random value⦠I have to at least once run the generatorâ¦
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: (Random new next; yourself)' done 7 3 4 9 6 7
Once I start to use it the properties of the algo kick in so it's pseudo-random⦠but I need to run it once to initialize it, which is wtf.
My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup?
Peter
_______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
2016-05-22 0:44 GMT+02:00 Luciano Notarfrancesco <luchiano@gmail.com>:
(Hey Rob, long time no Smalltalk!)
I suggest some changes we did in Cuis. First, for Park-Miller you can do a small change to #initialize, insert a hashMultiply somewhere when initializing the seed. I did experiments in Cuis, drawing histograms to see if it looks like a uniform distribution, and ended up doing something like seed _ (Time millisecondClockValue + self identityHash) hashMultiply \\ m
Another issue with Random that we addressed in Cuis is related to the bit size of each output. Random>>nextValue returns Floats with 31 random bits (or 30). It doesn't return a uniformly distributed Float between 0 and 1 (some Float values don't have a chance to be output). Similarly, Random>>nextInt: n will not really return an integer between 1 and n if n is large enough, for example (1 << 64) atRandom returns always odd integers (not very random uh).
So I suggest to think of Random as a generator of random "bits" or "blocks of bits", and to generate a Float it should actually build it from 52 randomly generated bits (to fill out the mantissa), and nextInt: n should also be implemented from random bits (or chunks of bits).
Yes, that's in Squeak for more than a year now. Still, a 30bits Park Miller does not have enough different states, and one should not be amazed that among the 2^53 possible Float values, most have a probability of exactly 0. Worse for LargeIntegers...
On Wed, May 18, 2016 at 11:25 PM, Robert Withers < robert.w.withers@gmail.com> wrote:
Thanks for cc-ing me. I don't have much exposure to random, so I am cc-ing the Cryptography list, in hopes they might help. This doesn't very random, you're right. Here were Peter's questions:
My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup?
Rob
On 05/18/2016 07:05 PM, Peter Uhnák wrote:
Hi,
(cc-ing Robert Withers as he seems to be working with cryptography and security... as this seems related and may have some implications, but I am likely wrong about the implications)
yesterday I've encountered a very surprising behavior
I executed the same script `10 atRandom` on the same image without saving it and got the same output:
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom' done 10 10 10 10 10 10
Not so random⦠not random at all.
Apparently the default random generator uses SharedRandom pool, that is initialized only once⦠so every time you start an image you get the EXACT same random seed... I think this is stupid, and I am not sure what are the security implications of this (e.g. when opening an SSL connection⦠having fixed world-wide initial seed seems like an awful, awful idea), but whateverâ¦
So instead I tried to explicitly specify the Random generator⦠which I can do
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: Random new' done 5 5 5 5 5
Still not random⦠what?
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval 'Random new instVarNamed: #seed' done 426306047 426305545 426305546 426306010
So the seed is different but thanks to the magic of masking the seed, I always get the same first several bits⦠thus the same result for small numbers.
So if I actually want what seems like a random value⦠I have to at least once run the generatorâ¦
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: (Random new next; yourself)' done 7 3 4 9 6 7
Once I start to use it the properties of the algo kick in so it's pseudo-random⦠but I need to run it once to initialize it, which is wtf.
My questions: 1) do we really want to have global fixed seed? 2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value 3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup?
Peter
_______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
On 05/21/2016 06:44 PM, Luciano Notarfrancesco wrote:
(Hey Rob, long time no Smalltalk!)
Hi Luciano, I'm grateful to hear you. I've got a feeling, you know. I got a feeling down deep there deep inside. and a got a feeling you got this feeling too! Do you know this feeling? do you know the resurrection mythtales of Icarus? The Phoenix? Lilith the Vampire? OpenSmalltalk is getting ready to rise up: all domains. Hang on. 'cause I got thisfeeling, you know. ;)
[1] http://pharo.org/success On 05/22/2016 09:46 AM, Robert Withers wrote:
On 05/21/2016 06:44 PM, Luciano Notarfrancesco wrote:
(Hey Rob, long time no Smalltalk!)
Hi Luciano, I'm grateful to hear you. I've got a feeling, you know. I got a feeling down deep there deep inside. and a got a feeling you got this feeling too! Do you know this feeling? do you know the resurrection mythtales of Icarus? The Phoenix? Lilith the Vampire? OpenSmalltalk is getting ready to rise up: all domains. Hang on. 'cause I got thisfeeling, you know. ;)
On Thu, May 19, 2016 at 7:05 AM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi,
(cc-ing Robert Withers as he seems to be working with cryptography and security... as this seems related and may have some implications, but I am likely wrong about the implications)
yesterday I've encountered a very surprising behavior
I executed the same script `10 atRandom` on the same image without saving it and got the same output:
while true; do pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom' done 10 10 10 10 10 10
Not so random⦠not random at all.
Obligitory cartoon... https://xkcd.com/221/ cheers -ben
On Thu, May 19, 2016 at 07:57:37AM +0800, Ben Coman wrote:
On Thu, May 19, 2016 at 7:05 AM, Peter Uhn??k <i.uhnak@gmail.com> wrote:
Not so random??? not random at all.
Obligitory cartoon... https://xkcd.com/221/
Perfect :-)
On 05/18/2016 04:05 PM, Peter Uhnák wrote:
My questions: 1) do we really want to have global fixed seed?
No!
2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value
Yes.
3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup?
Yes. Though this only works on Unix, so on Windows it uses the current time as a seed. It might get better results using #microsecondClockValue instead of #millisecondClockValue. And I'd think about just taking the microsecond value and sending it #hashMultiply instead of the weird things it's doing now. (bitXor with the identity hash of the UUIDGenerator instance? That depends on the randomness of identity hashes, which may or may not be very good.) It seems likely that Windows has a built-in random number generator, as well, which would probably be better. While we're at it, the class Random is a Park-Miller generator, which has quite poor randomness by modern standards. Most other Smalltalks have upgraded -- GemStone uses CMWC (pure Smalltalk, very simple and quite fast; I wrote that one), VW I believe uses Lagged Fibonacci, and Squeak has moved to Mersenne Twister last I heard. I've tested all three against statistical tests of randomness -- generated about 650GB of random bytes from each, ran them through the tests (which require that much data to get good statistics). All three are pretty good, only failing a few tests. The only generator I tested that passed *all* tests was Linux /dev/urandom. Which is also fast. If you're on Linux, and don't need a repeatable random sequence, I'd use /dev/urandom. If you do need to be able to have a repeatable sequence with good randomness properties, I'd use one of the three generators I mentioned above. Of the three, the simplest and fastest is CMWC. Regards, -Martin
Though this only works on Unix, so on Windows it uses the current time as a seed. It might get better results using #microsecondClockValue instead of #millisecondClockValue. And I'd think about just taking the microsecond value and sending it #hashMultiply instead of the weird things it's doing now. (bitXor with the identity hash of the UUIDGenerator instance? That depends on the randomness of identity hashes, which may or may not be very good.)
I agree less magic is better. And, more specifically, why would applying basically a linear transformation on a RNG seed produce "better random"? Note both xor and hashMultiply are essentially linear transformations. What is going on with how the RNG is using the seed to set itself up? If the RNG seeds are assumed / preferred to be uniformly distributed over some range of values, I'd consider crypto-pre-digesting the seed candidate (because crypto hashes are engineered to uniformly spread small bit changes over the entire output, roughly speaking --- so one might even use consecutive values starting at 1 without penalty). Or, if /dev/urandom or equivalent is available, how about using it for the initial seed as well? Andres.
On 19 May 2016, at 02:07, Martin McClure <martin@hand2mouse.com> wrote:
On 05/18/2016 04:05 PM, Peter Uhnák wrote:
My questions: 1) do we really want to have global fixed seed?
No!
2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value
Yes.
3) Should we switch to what UUIDGenerator is using⦠reading /dev/urandom for the initial seed setup?
Yes.
Though this only works on Unix, so on Windows it uses the current time as a seed. It might get better results using #microsecondClockValue instead of #millisecondClockValue. And I'd think about just taking the microsecond value and sending it #hashMultiply instead of the weird things it's doing now. (bitXor with the identity hash of the UUIDGenerator instance? That depends on the randomness of identity hashes, which may or may not be very good.) It seems likely that Windows has a built-in random number generator, as well, which would probably be better.
While we're at it, the class Random is a Park-Miller generator, which has quite poor randomness by modern standards. Most other Smalltalks have upgraded -- GemStone uses CMWC (pure Smalltalk, very simple and quite fast; I wrote that one), VW I believe uses Lagged Fibonacci, and Squeak has moved to Mersenne Twister last I heard. I've tested all three against statistical tests of randomness -- generated about 650GB of random bytes from each, ran them through the tests (which require that much data to get good statistics).
All three are pretty good, only failing a few tests. The only generator I tested that passed *all* tests was Linux /dev/urandom. Which is also fast. If you're on Linux, and don't need a repeatable random sequence, I'd use /dev/urandom. If you do need to be able to have a repeatable sequence with good randomness properties, I'd use one of the three generators I mentioned above. Of the three, the simplest and fastest is CMWC.
Martin, Would you be willing to contribute your implementation to Pharo ? Possibly with some tests ? Sven
Regards,
-Martin
On 05/18/2016 10:42 PM, Sven Van Caekenberghe wrote:
Martin,
Would you be willing to contribute your implementation to Pharo ? Possibly with some tests ?
I'll ask GemTalk management if they're OK with that. I imagine it'll be OK. But you might be better off taking the Squeak implementation, or reading and understanding the CMWC papers and implementing from scratch. My implementation is based on reference implementations and constants for 32-bit numbers in C. This works well if your SmallIntegers are 64-bit, as they are in GemStone. A straight port to Pharo would be handling large integers all the time. This might be OK, but is something to think about. Transposing it to 29-bit numbers would be possible, but would require finding new prime numbers with the appropriate properties. I consider that fairly heavy lifting, but perhaps you've got somebody with better numerical methods chops than I've got. My API is a bit unconventional, too, though *I* think it makes sense. :-) Example code: | random foo | random := Random new. foo := random integerBetween: 4 and: 27. "works until you get close to 2**32" foo := random integer. "[0..2**32-1]" foo := random float. "Double in [0..1)" Tests: I don't recall what automated tests we have. Some, I'm sure. The tough thing is testing a generator for randomness -- you need something like 650GB of free disk space and a couple of days to generate the random numbers and run the tests over them. I did all that manually. Those tests come from here: http://simul.iro.umontreal.ca/testu01/tu01.html They're the most complete randomness tests of which I'm aware. Regards, -Martin
Though this only works on Unix, so on Windows it uses the current time as a seed. It might get better results using #microsecondClockValue instead of #millisecondClockValue. And I'd think about just taking the microsecond value and sending it #hashMultiply instead of the weird things it's doing now. (bitXor with the identity hash of the UUIDGenerator instance? That depends on the randomness of identity hashes, which may or may not be very good.) It seems likely that Windows has a built-in random number generator, as well, which would probably be better.
While we're at it, the class Random is a Park-Miller generator, which has quite poor randomness by modern standards. Most other Smalltalks have upgraded -- GemStone uses CMWC (pure Smalltalk, very simple and quite fast; I wrote that one), VW I believe uses Lagged Fibonacci, and Squeak has moved to Mersenne Twister last I heard. I've tested all three against statistical tests of randomness -- generated about 650GB of random bytes from each, ran them through the tests (which require that much data to get good statistics).
All three are pretty good, only failing a few tests. The only generator I tested that passed *all* tests was Linux /dev/urandom. Which is also fast. If you're on Linux, and don't need a repeatable random sequence, I'd use /dev/urandom. If you do need to be able to have a repeatable sequence with good randomness properties, I'd use one of the three generators I mentioned above. Of the three, the simplest and fastest is CMWC.
In Polymath random there are several alternate random generators but I do not if there is CMWC
Regards,
-Martin
I checked and CMWC Marsaglia is part of polymath PMNumberGenerator allSubclasses an OrderedCollection(PMBernoulliGenerator PMBinomialGenerator PMConstantGenerator PMExponentialGenerator PMGaussianGenerator PMPoissonGenerator) PMRandomGenerator allSubclasses an OrderedCollection(PMMarsagliaKissRandom PMLehmerRandomGenerator PMLinearCongruentialRandomGenerator PMMersenneTwisterRandomGenerator PMParkMillerMinimumRandomGenerator) So we could pick one of them for Pharo. Stef
On 05/21/2016 01:56 PM, stepharo wrote:
I checked and CMWC Marsaglia is part of polymath
PMNumberGenerator allSubclasses an OrderedCollection(PMBernoulliGenerator PMBinomialGenerator PMConstantGenerator PMExponentialGenerator PMGaussianGenerator PMPoissonGenerator)
PMRandomGenerator allSubclasses an OrderedCollection(PMMarsagliaKissRandom PMLehmerRandomGenerator PMLinearCongruentialRandomGenerator PMMersenneTwisterRandomGenerator PMParkMillerMinimumRandomGenerator)
So we could pick one of them for Pharo. Stef
I don't see CMWC in PolyMath. The only Marsaglia algorithm I see there is KISS (which from my reading of the literature is both more complex than and inferior to CMWC). But the Mersenne Twister is there, and though complex (possibly unnecessarily so) it is good, AFAICT. Regards, -Martin
participants (12)
-
Andres Valloud -
Ben Coman -
Bob Clark -
David T. Lewis -
Luciano Notarfrancesco -
Martin McClure -
Nicolas Cellier -
Peter Uhnák -
Robert Withers -
Ron Teitelbaum -
stepharo -
Sven Van Caekenberghe