Yitzchak Gale wrote:
> Since they weren't mentioned in this thread, I'll point out that there
> are better sources of entropy than /dev/random, /dev/urandom, and the
> Windows API.
>
> For example, the two sites
>
> https://random.org/integers
> https://www.fourmilab.ch/hotbits/secure_generate.ht
Since they weren't mentioned in this thread, I'll point
out that there are better sources of entropy than
/dev/random, /dev/urandom, and the Windows API.
For example, the two sites
https://random.org/integers
https://www.fourmilab.ch/hotbits/secure_generate.html
both offer free random bits via a
I have now had a chance to experiment with these a bit, and have come up with
some changes that bring random-fu's speed in these tests into line with
Control.Monad.Random's when compiled with ghc-6.12.1, although it is still a
bit slower when using GHC 6.10.4. This is partially because one of t
Thanks for the clues, I'll try and make some time this weekend to track it
down. I do have some gentoo x64 systems to play with. My first impulse is
actually that it is likely due to differences in inlining and/or rewrite rule
processing between the GHC versions, but we'll see what turns up.
mo...@deepbondi.net writes:
> are you using the hackage-released version of random-fu or the darcs
> one?
I was using the hackage version, but since then I switched to the darcs
version. (Btw, began using it in some of my projects and I'm really
happy about it.)
> In the above case, I was using
> Is there a way to get multiple random numbers without having to
> replicateM?
>
> While comparing the random-fu interface with Control.Monad.Random (both
> using StdGen), I noticed that while performance is comparable, using
> getRandomRs to get a list of random numbers is a lot faster than
> rep
James Cook writes:
> As the maintainer of random-fu, I'd be interested to know whether you
> find it useful after further inspection.
Is there a way to get multiple random numbers without having to
replicateM?
While comparing the random-fu interface with Control.Monad.Random (both
using StdGen)
As the maintainer of random-fu, I'd be interested to know whether you
find it useful after further inspection. It does, in fact, support
using /dev/random as its entropy source. I don't know what exact sort
of things you're wanting to do, but very basic usage (random Int in IO
from DevRan
Looking over the random-fu package, I think it might have what I'm looking
for (and a lot that I'm not).
On Sat, Apr 3, 2010 at 6:27 PM, Gökhan San wrote:
> Alex Rozenshteyn writes:
>
> > The Rand monad you linked seems to be a step in the right direction
> > for what I want, but it uses getStd
Alex Rozenshteyn writes:
> The Rand monad you linked seems to be a step in the right direction
> for what I want, but it uses getStdGen, which appears to end up using
> cpu time to seed the generator.
There's the random-stream package but looks like it's subject to code
rot. Its RandomGen instan
The Rand monad you linked seems to be a step in the right direction for what
I want, but it uses getStdGen, which appears to end up using cpu time to
seed the generator.
On Sat, Apr 3, 2010 at 9:21 AM, Ertugrul Soeylemez wrote:
> Matthew Hayden wrote:
>
> > What's wrong with the System.Random.S
Matthew Hayden wrote:
> What's wrong with the System.Random.StdGen implementation of
> RandomGen?[1] (I'm not sure if it's cryptographically safe)
It's a poor PRNG. And no, it's not anywhere near suitable for
cryptographic applications.
> Someone (Cale IIRC) has already implemented a Rand mon
Hello Christopher,
unfortunately this is not a "better StdGen", because it still uses the
poor PRNG algorithm of StdGen. You can get better statistic properties
by using a package like mwc-random or mersenne-random.
However, if you want (an approximation of) truely random numbers, you
need to re
13 matches
Mail list logo
