MonadRandom 0.5 and mwc-random: feedback wanted

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!


About Brent

Assistant Professor of Computer Science at Hendrix College. Functional programmer, mathematician, teacher, pianist, follower of Jesus.
This entry was posted in haskell, projects and tagged , . Bookmark the permalink.

9 Responses to MonadRandom 0.5 and mwc-random: feedback wanted

  1. 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.

  2. Naren Sundar says:

    mwc-random is my goto package when writing Gibbs samplers. It’s great the way it is!

    • Brent says:

      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.

    • Dominic Steinitz says:

      What do you use as your proposal distribution?

  3. Pingback: MonadRandom 0.5 released | blog :: Brent -> [String]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s