Skip to content

skip and mix methods in Random typeclass? #39

Description

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

Activity

  1. cartazio commented on May 10, 2016

    @cartazio
    Contributor

    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
    #39

  2. added a commit that references this issue on May 5, 2020
  3. added a commit that references this issue on May 19, 2020
  4. Bodigrim commented on Jun 24, 2020

    @Bodigrim
    Contributor

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

  5. curiousleo commented on Jun 25, 2020

    @curiousleo
    Contributor

    idontgetoutmuch#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.

  6. Zemyla commented on Jun 25, 2020

    @Zemyla
    Author

    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.

  7. curiousleo commented on Jun 30, 2020

    @curiousleo
    Contributor

    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 #39 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions