Repository navigation
skip and mix methods in Random typeclass? #39
Description
Activity
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 | nseqkseqgseqFalse = undefined
go n k g | n < 0 = g
go n k g = go (n - 1) k (testBit K npicksplit 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- added a commit that references this issue
on May 5, 2020 - added a commit that references this issue
on May 19, 2020 @Zemyla do you have any particular PRNGs in mind (ideally already existing in Haskell ecosystem)?
Since
nextis deprecated, I'm in favor of closing this, unless there is an evidence that this is an important feature.idontgetoutmuch#7 is closely related in the sense that
splitis also a method that some PRNGs support and some don't.Introducing an extra class for
splitwas 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
splitare instances ofSplittable, those which haveskipimplementSkippable, etc.I think it wouldn't hurt to brainstorm what an API with explicit PRNG "features" like
skip,split,mixetc. could look like, keeping in mind that it may turn out in the end not to be worth it.I think any PRNG with a fast (O(log n))
skipcould besplittable. You generate a large random number, thenskipone of the PRNGs by that much. You can do the same formix: 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, thenskipthe first RNG by that much.I think any PRNG with a fast (O(log n))
skipcould besplittable. You generate a large random number, thenskipone of the PRNGs by that much. You can do the same formix: 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, thenskipthe first RNG by that much.Those sound like reasonable approaches to me, but the
skipimplementation 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 badsplitfunctions again.However, my understanding of this issue was that it was about exposing an API for
mixandskip, which seems like a good idea to me -- see #39 (comment).
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:
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:
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.