skip and mix methods in Random typeclass?

[Zemyla]

There are RNGs that can skip n values in less than O(n) time, and they should have the opportunity to expose this to the user. And the ones that don't still have a sensible default:

skip :: (RandomGen g) => Int -> g -> g
skip n g | n <= 0 = g
skip n g = case next g of (_, g') -> skip (n - 1) g'

There are also RNGs that allow the user to mix in entropy to the generator, and this also has a sensible default for generators without that operation:

pick :: Bool -> (a, a) -> a
pick False (f, s) = f
pick True (f, s) = s

mix :: (RandomGen g) => Int -> g -> g
mix = go (finiteBitSize (0 :: Int)) where
  go n k g | n `seq` k `seq` g `seq` False = undefined
  go n k g | n < 0 = g
  go n k g = go (n - 1) k (testBit K n `pick` split g)

These methods should be part of the typeclass so they can be available to both consumers of random numbers and those who want to create generators that modify other generators.

[cartazio]

Indeed!

Have you looked at the pcg random?

Also the chacha csprng / stream cipher has a similar thing.

On Tuesday, May 10, 2016, Zemyla [email protected] wrote:

There are RNGs that can skip n values in less than O(n) time, and they should have the opportunity to expose this to the user. And the ones that don't still have a sensible default:

skip :: (RandomGen g) => Int -> g -> g skip n g | n <= 0 = g skip n g = case next g of (_, g') -> skip (n - 1) g'

There are also RNGs that allow the user to mix in entropy to the generator, and this also has a sensible default for generators without that operation:

pick :: Bool -> (a, a) -> a pick False (f, s) = f pick True (f, s) = s mix :: (RandomGen g) => Int -> g -> g mix = go (finiteBitSize (0 :: Int)) where go n k g | n seq k seq g seq False = undefined go n k g | n < 0 = g go n k g = go (n - 1) k (testBit K n pick split g)

These methods should be part of the typeclass so they can be available to both consumers of random numbers and those who want to create generators that modify other generators.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/haskell/random/issues/39

[Bodigrim]

@Zemyla do you have any particular PRNGs in mind (ideally already existing in Haskell ecosystem)?

Since next is deprecated, I'm in favor of closing this, unless there is an evidence that this is an important feature.

[curiousleo]

https://github.com/idontgetoutmuch/random/issues/7 is closely related in the sense that split is also a method that some PRNGs support and some don't.

Introducing an extra class for split was something we considered and then decided against for 1.2.0, because it would have been a compatibility nightmare.

There are probably nice ways to model PRNGs better such that only those which implement split are instances of Splittable, those which have skip implement Skippable, etc.

I think it wouldn't hurt to brainstorm what an API with explicit PRNG "features" like skip, split, mix etc. could look like, keeping in mind that it may turn out in the end not to be worth it.

[Zemyla]

I think any PRNG with a fast (O(log n)) skip could be splittable. You generate a large random number, then skip one of the PRNGs by that much. You can do the same for mix: hash the input with the next output from the PRNG, perhaps use that as a seed for another RNG to generate a large random number, then skip the first RNG by that much.

[curiousleo]

I think any PRNG with a fast (O(log n)) skip could be splittable. You generate a large random number, then skip one of the PRNGs by that much. You can do the same for mix: hash the input with the next output from the PRNG, perhaps use that as a seed for another RNG to generate a large random number, then skip the first RNG by that much.

Those sound like reasonable approaches to me, but the skip implementation in random v1.1 probably also seemed reasonable to the people who implemented it. I want to be careful and not encourage or enable accidentally creating bad split functions again.

However, my understanding of this issue was that it was about exposing an API for mix and skip, which seems like a good idea to me -- see https://github.com/haskell/random/issues/39#issuecomment-649292727.