Yep, but don't conflate determinism with splitting. In the imperative
world, you normally know how many CPUs you have, so you initialize one PRNG
per CPU, and simply go from there; there's no need for splitting. In the
parallel community, people are going out of their way to *avoid*
Brandon Allbery allber...@gmail.com wrote:
I've noticed there's a convention to put modules having to deal
with randomness into System.Random. I thought System was for OS
interaction? Granted getting a random seed usually means going to
the OS, but isn't the rest of it, like
Hi all,
I'm the maintainer of random. If people could decide on what the
alternative name would be we could put it through the library proposal
process. It seems that one problem at this moment is the lack of a single,
clear right answer. Replacing one debatable not-quite-right choice with
Ryan Newton rrnew...@gmail.com wrote:
I'm the maintainer of random. If people could decide on what the
alternative name would be we could put it through the library proposal
process. It seems that one problem at this moment is the lack of a
single, clear right answer. Replacing one
On Wed, Aug 17, 2011 at 8:56 AM, Ryan Newton rrnew...@gmail.com wrote:
I'm the maintainer of random. If people could decide on what the
alternative name would be we could put it through the library proposal
process. It seems that one problem at this moment is the lack of a single,
clear
The problem with Mersenne twister is that it doesn't split well. The main
reason for crypto prng in this package would not be to advertise to people
that System.Random can be used for security-related apps *but to make
splitting reasonably safe*. It's not good enough to have a known-bad
On Wed, Aug 17, 2011 at 11:10 AM, Ryan Newton rrnew...@gmail.com wrote:
The problem with Mersenne twister is that it doesn't split well. The main
reason for crypto prng in this package would not be to advertise to people
that System.Random can be used for security-related apps *but to make
The more fundamental problem is that splitting is neither well understood
nor generally safe, and as such it should not be in the basic Random class.
Would you mind elaborating? Splitting was not well-understood by the
original authors of System.Random; that much is in the comments. Nor is
On Wed, Aug 17, 2011 at 12:27 PM, Ryan Newton rrnew...@gmail.com wrote:
The more fundamental problem is that splitting is neither well understood
nor generally safe, and as such it should not be in the basic Random class.
Would you mind elaborating?
Certainly. The purpose of splitting a
I've noticed there's a convention to put modules having to deal with
randomness into System.Random. I thought System was for OS
interaction? Granted getting a random seed usually means going to the
OS, but isn't the rest of it, like generating random sequences,
distributions, selecting based on
I think of it as natural for exactly the reason you stated (the data
comes from the OS). It seems even more natural to me in the entropy
package module 'System.Entropy' as I am accustom to the phrase system
entropy. Equally, I would fine a 'Network.Entropy' module acceptable
under the assumption
On Aug 16, 2011, at 4:04 PM, Evan Laforge wrote:
I've noticed there's a convention to put modules having to deal with
randomness into System.Random. I thought System was for OS
interaction? Granted getting a random seed usually means going to the
OS, but isn't the rest of it, like
On Tue, Aug 16, 2011 at 17:07, James Cook mo...@deepbondi.net wrote:
On Aug 16, 2011, at 4:04 PM, Evan Laforge wrote:
I've noticed there's a convention to put modules having to deal with
randomness into System.Random. I thought System was for OS
interaction? Granted getting a random seed
Yeah, fair enough about getting the seed. I think I like the idea of
breaking them into System.Entropy and then Random or Data.Random. It
feels odd to stick pure algorithm packages, which simply accept a
random seed or stream from elsewhere, under System.Random.
There are a fair number of
I don't like the idea of Data.Random because random numbers use
ordinary number types, and the generator itself is not the object of
interest, the numbers are. I'd much prefer Math.Random. As the Math
prefix isn't used in the core libraries maybe Control.Random is the
least unpalatable
15 matches
Mail list logo
