Paul Moore wrote:
2009/8/5 Yitzchak Gale <g...@sefer.org>:
Or is this with an alternate RNG? Although I think even that
would be fair, since Python uses Mersenne.
I got the impression Dmitry was using Haskell's standard RNG, not
Mersenne Twister. If so, then we'd get further improvements with MT,
but that's still a hit against Haskell, as I'd interpret it as meaning
that Haskell supplies as default a PRNG which costs noticeable
performance in order to provide guarantees that "ordinary" programs
don't need.
I'm not sure how fair that is. For most "ordinary" programs I've written
that use randomness anywhere, they have many different places that want
randomness. Having a single global seed can suffice for this, but it
introduces severe constraints that are seldom noticed.
Namely, these are in fact *P*RNGs. If every place needing randomness is
given its own seed, then it becomes possible to store all those seeds,
allowing for replay. Replay can be good for capturing the history of a
particular run of a simulation/game ---which is difficult at best in
non-Haskell approaches. And more critically the seeds can be stored in a
"core dump" allowing replay as a debugging tool, allowing reproduction
of 'random' bugs which are otherwise quite difficult to track down.
Imperative languages could use the same algorithms as Haskell, but they
do not; which means these benefits of PRNGs are seldom even thought of.
By separating concerns, the Haskell approach not only leads to cleaner
code, but that separation can also be used to add new capabilities. The
invisible manacles of imperativism should not be looked upon lightly.
--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
