<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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. <div class=""><br class=""></div><div class="">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.<div class=""><br class=""></div><div class="">milos<br class=""><div class=""><br class=""></div><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On 11 Apr 2016, at 02:42, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I encourage anyone thinking about PRNG APIs to check out what C++ STL has to offer: <a href="http://en.cppreference.com/w/cpp/numeric/random" class="">http://en.cppreference.com/w/cpp/numeric/random</a><div class=""><br class=""></div><div class="">And this analysis/extension of it: <a href="http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html" class="">http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html</a></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Sun, Apr 10, 2016 at 6:40 PM, Brent Royal-Gordon via swift-users <span dir="ltr" class=""><<a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> import Foundation<br class="">
><br class="">
> (1..<4).sample<br class="">
> [1,2,3].sample<br class="">
> "abc".characters.sample<br class="">
> ["a": 1, "b": 2, "c": 3].sample<br class="">
><br class="">
> 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.<br class="">
<br class="">
</span>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:<br class="">
<br class="">
* It's not testable or repeatable<br class="">
* It needs to be synchronized with other threads<br class="">
* It can't be configured to use a different random number generator<br class="">
<br class="">
Personally, I would eventually like to see something like this in the standard library:<br class="">
<br class="">
protocol RandomizerProtocol {<br class="">
mutating func randomBytes(_ n: Int) -> [UInt8]<br class="">
// or possibly something involving a generic-length tuple, for speed<br class="">
}<br class="">
extension RandomizerProtocol {<br class="">
// for coin flips<br class="">
mutating func randomChoice() -> Bool { ... }<br class="">
// for choosing a random element<br class="">
mutating func randomChoice<CollectionType: RandomAccessCollection>(from collection: CollectionType) -> CollectionType.Element { ... }<br class="">
// for choosing a random value from an uncountable range (e.g. Range<Double>)<br class="">
mutating func randomChoice<Element: Strideable>(from range: Range<Element>) -> Element { ... }<br class="">
}<br class="">
struct Randomizer: RandomizerProtocol {<br class="">
init(state: [UInt8]) { ... }<br class="">
init() { self.init(state: somethingToMakeAGoodRandomState()) }<br class="">
<br class="">
mutating func randomBytes(_ n: Int) -> [UInt8] {<br class="">
// akin to arc4random()<br class="">
}<br class="">
}<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
--<br class="">
Brent Royal-Gordon<br class="">
Architechies<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
_______________________________________________<br class="">
swift-users mailing list<br class="">
<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class="">
</div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></div></div></body></html>