[swift-users] Sampling collections

[Milos Rankovic]

Thanks, Jacob, for the links. Apple did take steps in this direction by spoiling us with a choice of random sources in the GameplayKit. I’m sure that after that initial effort, the GameplayKit team will continue to bring more power to the randomisation part of the framework. 

Only, that is not what I had in mind. Once you care about the distinction between congruential and Mersenne sources, you are likely not to mind having to deal with a more involved framework. My point is that this is VERY often far too involved! That the “middle ground” Apple is striking with ARC4 algorithm and a publicly accessible system source is indicative that there is a more “popular” need for such functionality where random merely has to look random… Much joy is to be found below that low bar. For example, I believe that a small family of basic sampling properties and methods would quickly become favourite among the learners of Swift and those that are teaching them.

milos

> On 11 Apr 2016, at 02:42, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
> 
> I encourage anyone thinking about PRNG APIs to check out what C++ STL has to offer: http://en.cppreference.com/w/cpp/numeric/random <http://en.cppreference.com/w/cpp/numeric/random>
> 
> And this analysis/extension of it: http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html <http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html>
> 
> Jacob
> 
> On Sun, Apr 10, 2016 at 6:40 PM, Brent Royal-Gordon via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
> >     import Foundation
> >
> >     (1..<4).sample
> >     [1,2,3].sample
> >     "abc".characters.sample
> >     ["a": 1, "b": 2, "c": 3].sample
> >
> > Like so many users of Swift, I have extensions of IntegerType, ClosedInterval and CollectionType that avail me of the above methods and their family, but I’d much rather if such extensions came with Darwin or at least Foundation.
> 
> I don't think a `sample` property or method is the right approach here. It would be using some sort of global source of random numbers, which means that:
> 
> * It's not testable or repeatable
> * It needs to be synchronized with other threads
> * It can't be configured to use a different random number generator
> 
> Personally, I would eventually like to see something like this in the standard library:
> 
>         protocol RandomizerProtocol {
>                 mutating func randomBytes(_ n: Int) -> [UInt8]
>                 // or possibly something involving a generic-length tuple, for speed
>         }
>         extension RandomizerProtocol {
>                 // for coin flips
>                 mutating func randomChoice() -> Bool { ... }
>                 // for choosing a random element
>                 mutating func randomChoice<CollectionType: RandomAccessCollection>(from collection: CollectionType) -> CollectionType.Element { ... }
>                 // for choosing a random value from an uncountable range (e.g. Range<Double>)
>                 mutating func randomChoice<Element: Strideable>(from range: Range<Element>) -> Element { ... }
>         }
>         struct Randomizer: RandomizerProtocol {
>                 init(state: [UInt8]) { ... }
>                 init() { self.init(state: somethingToMakeAGoodRandomState()) }
> 
>                 mutating func randomBytes(_ n: Int) -> [UInt8] {
>                         // akin to arc4random()
>                 }
>         }
> 
> This would allow you to confine a random number generator to a particular thread, swap one implementation for another, or inject one with a fixed starting state as a dependency to make tests predictable. A design like this one works around the problems I described nicely.
> 
> However, I don't think this is a high enough priority to address right now. This is borderline out-of-scope as "major new library functionality", and there's so much stuff to do that is truly core to the language, this simply seems like a distraction.
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org <mailto:swift-users at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160411/440d9ece/attachment.html>