Random Number Update

[Carter Schonwald]

the fuzzy and slightly out of date task list in
https://github.com/haskell/random/issues/31
sketches out some of the basic stuff (though theres more confusion than
clarity in the discussion thread on that ticket)

for my own peace i'm doing most of the v2 work over at
https://github.com/cartazio/random, and i've been focusing on internals
before sussing

the API will have a breaking change even if we were types compatible
because the meaning of the seed stats will no long provide the same
computations

the v2 series will provide splitmix and pcg RNGs, a MonadRandom class that
doesn't require a PrimMonad constraint for pure generators.

per commit CI will end up running small crush and determinism checking
tests once its at a stable/more mature point, and per RELEASE CI will do a
big crush run or several on various permutations of the tools

thats ignoring having good benchmarks for how well different RNGS and
implementation strategies thereof

I've also had some productive chats with tomdb of Galois about what the end
state should be.

I think for all practical purposes this thread is a waste of time.

On Wed, Jan 25, 2017 at 2:55 PM, Sven Panne <svenpanne at gmail.com> wrote:

2017-01-25 13:47 GMT+01:00 Dominic Steinitz <dominic at steinitz.org>:

[...] I can’t say I agree with the reasoning that it is better to carry on
using something that could be giving incorrect results silently rather than
breaking things so that people can take action. [...]


This is not what I have proposed: My proposal was: Add any number of RNGs
in one or more packages, but keep the current API of System.Random in
package "random". It should probably use (= re-export, perhaps with a shim)
one of the other, better RNGs to address the problems you've mentioned.

Breaking/removing fundamental packages should not be done light-heartedly,
it wreaks havoc in the ecosystem. Look e.g. at the reverse dependencies of
"random" (http://packdeps.haskellers.com/reverse/random): There are 845
packages affected, and I'm not even sure if that page takes transitive
dependencies into account. Assuming that hundreds of package maintainer
will happily update their packages in a short time frame just to use
something "better" (where "better" is probably very dependent on one's POV)
is overly optimistic. And in addition, doing such breaking changes
obsoletes documentation, tutorials etc. out there. Yes, I'm repeating
myself, but this is a point which seems to be forgotten quite often.

Is there something in System.Random's API which is fundamentally broken?
I'm not sure, and I'm by no means an expert in RNGs. If yes, we should
nevertheless keep it for now, probably deprecating the broken parts and
phase them out slowly. Processes like this are quite slow (measured in
years), and there are many good reasons for this. Looking e.g. at Java's
java.lang.Thread.stop() one can see that it is still in the latest JDK,
although it has been deprecated for almost 2 decades now. Another example
is C++'s horrible pre-exception I/O standard library, something which
everybody hates, but it is still there, after an even longer time.

Cheers,
   S.

_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170126/85c592fd/attachment.html>