Since 2013 or so I have been the maintainer of the MonadRandom package, which provides an mtl-style type class for monads with support for generation of pseudorandom values, along with a concrete random monad transformer RandT. As of this writing it has 89 reverse dependencies on Hackage—a healthy number, and one that makes me think carefully about any breaking changes to the package.
Recently I got a number of pull requests, and have been working on putting together an 0.5 release which adds a few functions, adds lazy- and strict-state variants of RandT, and reorganizes things to be closer to standard practice of the transformers package. Since this release will include some technically breaking changes already, it’s a good time to think about potentially including others.
The one thing I am not sure what to do about is this issue: Allow MonadRandom interface for MWC-random. mwc-random is a very nice package for psuedorandom number generation, but apparently it does not fit into the MonadRandom abstraction. First of all, I would like to understand why—I am not very familiar with mwc-random. Second of all, I’d love to figure out a solution, but ideally one that causes as little breakage to existing code as possible.
Leave a comment (either here or on the github issue) if this is something you know/care about, and let’s see if we can figure out a good solution together!
blog :: Brent -> [String] 
Hi Brent I maintain random-fu which does now have an interface to mwc-random. I’d love to discus this with you but I am currently on a cycling tour not returning til the weekend and only my phone with me.
Thanks! No rush, I will look forward to discussing it with you when you return.
mwc-random is my goto package when writing Gibbs samplers. It’s great the way it is!
To be clear, I’m not proposing to change the mwc-random package at all. Indeed, I have no control over that package. I’m proposing to possibly change the MonadRandom package so that it can work with mwc-random.
Hi! Maintainer of mwc-random is here.
I think current approaches to creating uniform API for PRNGs are using wrong abstraction. PRNG produces uniformly distributed bitvector of fixed length, Word32 or Word64 usually. This is not enough for practical uses so minimal helpers are added for generating uniform distributions and maybe something more advanced.
Right structure for _the_ package for generating random numbers is:
1. PRNG itself
2. Primitive generators like uniform distributions. They aren’t trivial. And if we really concerned about performance doubly so. Say we want to generate vector of Word8 and PRNG produces Word32. Naive approach is to generate 1 word per sample. But we can generate 4 word per sample! Implementing such optimization is difficult should be done only once.
3. More complicated generators for various distributions. Again they will benefit from concentrated effort.
So in my opinion way forward is assimilating every major PRNG package into single package/set of packages with common API.
I use random-fu heavily for work and I also maintain it. It separates the complicated generators from the PRNG itself. For example, from random-source you can use mwc or mersenne twister and easily add other methods (the former might only be available in github rather than on hackage but I will remedy that today). And then you can sample from any number of distributions: https://hackage.haskell.org/package/random-fu and https://hackage.haskell.org/package/random-fu-multivariate.
Would this be a good starting point?
I hope so. I have very limited knowledge of random-fu. Unfortunately I don’t have much time at the moment to dig into it,
What do you use as your proposal distribution?
Pingback: MonadRandom 0.5 released | blog :: Brent -> [String]