> 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*
> spli
On Wed, Aug 17, 2011 at 12:27 PM, Ryan Newton 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 PRNG is to cr
>
> 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
On Wed, Aug 17, 2011 at 11:10 AM, Ryan Newton 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
> splitting reas
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
generat
On Wed, Aug 17, 2011 at 8:56 AM, Ryan Newton 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.
Ryan Newton 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 debatable not-quite-
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
an
Brandon Allbery 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 generating rand
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 alternative.
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 altern
On Tue, Aug 16, 2011 at 17:07, James Cook 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 usually mean
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 genera
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
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 p
15 matches
Mail list logo
