On Aug 1, 2009, at 2:06 PM, Paul Moore wrote:

Is the issue with random numbers just the implementation, or is it
something inherent in the non-pure nature of a random number generator
that makes it hard for Haskell to implement efficiently? If the
latter, that probably makes Haskell a somewhat poor choice for
simulation-type programs.


Well, I'm not sure of the details, but in your original implementation, you're performing IO to pull the seed out of a ref at every iteration. Pekka Karjalainen's doesn't do that, which probably helps with the speedup. Along with that, Haskell has a fairly slow random implementation. As I recall however, this is partially because it hasn't received a great deal of optimization, but mainly because the algorithm itself fulfills some rather strong properties -- in particular it must be fairly statistically robust, and it must provide a "split" function which produces generators that are independently robust [1]. This limits algorithm choice quite a bit.

For other random numbers, with different properties (faster, but with tradeoffs in robustness, or ability to split, or both), you can check hackage for at least mersenne-random and gsl-random. There may be others that I don't recall.

Cheers,
Sterl.

[1] http://www.haskell.org/onlinereport/random.html
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to