<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I'm not sure how much background you have into this thread, but the idea of sources and distributions was rejected months ago as almost always too cumbersome given that people overwhelmingly want uniform random numbers.<div class=""><div class=""><br class=""></div><div class="">I agree that random() is better as a method. I also think that the default Random implementation should be in a class, not a struct. If a generator has value semantics, I would expect that two copies would return an identical sequence of numbers.</div><div class=""><br class=""></div><div class="">I think that it'll be hard to make a RandomValue<T> that nicely converts to T. The best way to discourage modulo is probably to make T.random/T(randomSource:) as cumbersome as possible, and Range.random as nice as possible.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 2 janv. 2018 à 11:19, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Just skimmed through the updated proposal and am weighing in with my naïve opinions:<div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">I’m still highly skeptical of a static “T.random” API. I’ve yet to see a convincing example where it’d be useful to pick a value from the range of all possible values. The only truly useful one I’ve seen is “pick a random bool”, which could easily be done via “[true, false].random()"<br class=""><br class=""></li><li class="">I much prefer the GameplayKit API[0], which breaks the idea of randomness up in to 2 separate concepts:</li><ul class=""><li class="">A “Source” → Where the random numbers come from</li><li class="">A “Distribution” → Initialized with a source, it makes sure the produced numbers exhibit a specific distribution over multiple samplings. Ie, a uniform distribution vs a Gaussian distribution, or something like “I want to pick a card from a deck but bias choices towards Spades or Aces”. I’m also reminded of the anecdote of how iTunes had to modify their “playlist shuffle” algorithm to be less random[1], because the true randomness would do weird things that made it seem not random. Spotify had the same problem and solution[2].</li><li class="">Breaking things up like this would also make it easier to test randomness (by using a replay-able source) but that still follow the parameters of your app (that it has a bell-curve distribution of probabilities, for example)<br class=""><br class=""></li></ul><li class="">I’d still really really really like to see how this could be done as two separate things:</li><ul class=""><li class="">A minimal implementation in the Standard Library (like, defining the base Source and Distribution protocols, with a single default implementation of each)</li><li class="">A proposal for a more complete “non-standard library” where the larger array of functionality would be contained. For example, IMO I don’t think the shuffling stuff needs to be in the standard library. This is also where all the cryptographically secure stuff (that your typical app developer does not need) would live.<br class=""><br class=""></li></ul><li class="">The “random” element of a collection/range should be “func random() → Element?”, not “var random: Element?”. Property values shouldn't change between accesses. Ditto the static “Randomizable.random” property.<br class=""><br class=""></li><li class="">What do you think about actively discouraging people from using the modulo operator to create a range? It could be done by having the RNGs return a “RandomValue<T>” type, then defining a mod operator that takes a RandomValue<T> and a T (?), and then giving it a deprecation warning + fixit. Not sure if that’d be worth the type overhead, but I’m very much in favor of encouraging people towards better practices.<br class=""><br class=""></li><li class="">I’m +1 on crashing if we can’t produce a random number. <br class=""><br class=""></li><li class="">What do you think about the philosophical difference of Type.random(using:) vs Type.init(randomSource:)?</li></ul><div class=""><br class=""></div><div class="">Dave</div><div class=""><br class=""></div><div class="">[0]: <a href="https://developer.apple.com/documentation/gameplaykit/gkrandom" class="">https://developer.apple.com/documentation/gameplaykit/gkrandom</a></div><div class="">[1]: <a href="https://www.youtube.com/watch?v=lg188Ebas9E&feature=youtu.be&t=719" class="">https://www.youtube.com/watch?v=lg188Ebas9E&feature=youtu.be&t=719</a></div><div class="">[2]: <a href="https://labs.spotify.com/2014/02/28/how-to-shuffle-songs/" class="">https://labs.spotify.com/2014/02/28/how-to-shuffle-songs/</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 2, 2018, at 1:35 AM, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<title class=""></title>
<div class="">
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
Hello swift evolution once again, I’ve been hard at work considering every email and revising the proposal. I’ve made lots of changes and additions to the proposal to discuss some problems we’ve had (T.random), and walks through detailed design. You can see
the proposal here: <a href="https://github.com/apple/swift-evolution/pull/760" class="">https://github.com/apple/swift-evolution/pull/760</a> .
<div class=""><br class="">
</div>
<div class="">A big issue that lots of people pointed out was `T.random %` and to remove it completely from the API. To give a gist of why I continue to support T.random:</div>
<div class=""><br class="">
</div>
<div class="">1. Modulo bias misuse is only a problem to types that conform to `BinaryInteger`. Why remove this functionality if only a portion of the types have the ability of misuse. `Double.random % 10` is a good example of where modulo isn’t implemented here as
it produces the error, “'%' is unavailable: Use truncatingRemainder instead”.</div>
<div class=""><br class="">
</div>
<div class="">2. `Int.random(in: Int.min … Int.max)` doesn’t work. For developers that actually rely on this functionality, the work around that was discussed earlier simply doesn’t work. `Int.min … Int.max`’s count property exceeds that of `Int`’s numerical range.
A working work around would be something along the lines of `Int(truncatingIfNeeded: Random.default.next(UInt.self))` which creates a pain point for those developers. As the goal of this proposal to remove pain points regarding random, this change does the
opposite.</div>
<div class=""><br class="">
</div>
<div class="">I’m interested to hear if anymore discussion around this, or any other issues come up.</div>
</div>
<div name="messageSignatureSection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<br class="">
- Alejandro</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<br class="">
On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>, wrote:<br class="">
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;" class="">
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
Hello swift evolution, I would like to propose a unified approach to `random()` in Swift. I have a simple implementation here <a href="https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5" class="">https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5</a>.
This implementation is a simple wrapper over existing random functions so existing code bases will not be affected. Also, this approach introduces a new random feature for Linux users that give them access to upper bounds, as well as a lower bound for both
Glibc and Darwin users. This change would be implemented within Foundation.
<div class=""><br class="">
</div>
<div class="">I believe this simple change could have a very positive impact on new developers learning Swift and experienced developers being able to write single random declarations.</div>
<div class=""><br class="">
</div>
<div class="">I’d like to hear about your ideas on this proposal, or any implementation changes if need be.</div>
<div class=""><br class="">
</div>
<div class="">- Alejando</div>
</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<br class="">
<div class=""></div>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>