<div dir="ltr">On Sun, Nov 5, 2017 at 8:21 PM, Alejandro Alonso <span dir="ltr"><<a href="mailto:aalonso128@outlook.com" target="_blank">aalonso128@outlook.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
I can agree with mostly everything in here. I think `.random` on `RandomAccessCollection` should mimic the current design with `.first` and `.last` by returning an optional. In terms of the naming of this, we have to look at how python structures the call site.
`random.choice([1, 2, 3, 4])` To me this reads, random choice within this array. This works because of how it’s called. With the proposed solution, we are calling to get a random element directly from the array. So I stick by with naming this random.
<div><br>
</div>
<div>On the subject of bike shedding the names, I can agree to use `RandomNumberGenerator` whole heartily. As for `Randomizable`, I agree there might be a better name for this, but the question is what?</div></div></div></blockquote><div><br></div><div>That is a good question. I don't like `RandomlySamplable`; it might be that `Randomizable` could be the least bad option.</div><div><br></div><div>One more comment that I neglected to make. You don't need to use an `enum` in order to make a type non-initializable. A `struct` can do the same with a private init. There are established singleton patterns for Swift and an `enum` with a single case is...atypical. I'm also not sure why this should be a public type at all. Why expose `Random.default.next()`? Shouldn't the user always use `T.random`? Afaict, `Random` can be an internal type `_Random` that the user never sees at all.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="h5"><div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
On Nov 5, 2017, 7:56 PM -0600, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>, wrote:<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #1abc9c">
<div dir="ltr">I like this particular version. In particular, the choice of algorithms is, afaict, correct and that is incredibly important. I had overlooked that `arc4random` is cryptographically secure past a certain version of macOS, but you are absolutely
right. I am also on board with the fatal error suggestion if random entropy is unavailable; I think it must be amply documented, though.
<div><br>
</div>
<div>I do think, however, that you're overloading too many things into the word "random" when they're not the same. Take a look at Python, which is pretty widely used for numerics. There's `rand` and `random` for getting a random integer or floating-point value,
and there's `choice` and `sample` for choosing one or more values out of a collection without replacement. These are sufficiently different tasks and don't all need to be called "random" or satisfy the same requirement of the same protocol. Put another way,
it's absolutely *not* inconsistent for numeric types to have `random()` while collection types have a differently named method.</div>
<div><br>
</div>
<div>By contrast, I think the great length of text trying to justify naming all of these facilities `random` in order to parallel `first` and `last` shows how the proposed design is comparatively weaker. You have to argue that (a) `Int.random` shouldn't return
an optional value because it'd be unwieldy, and therefore `(0..<5).random` shouldn't either because it would then be inconsistent; but (b) that `(0..<5).random` should be spelled and behave like `(0..<5).first` and `(0..<5).last` even though the user must
handle empty collections totally differently because the return types are not the same. Either `(0..<5).random` should behave analogously to `first` and `last` or it should not. If it should, it only makes sense to return a result of type `T?`. After all,
if a collection doesn't have a `first` item, then it can't have a `random` item. Put another way, having a `first` item is a prerequisite to having a randomly selectable item. The behavior of the Swift APIs would be very consistent if `first` returns `T?`
but `random` returns `T`. However, I agree that unwrapping `Int.random` every time would be burdensome, and it would not make sense to have a type support `random` but not have any instantiable values; therefore, returning an optional value doesn't make sense,
and it follows that `Int.random` *shouldn't* behave like `first` or `last`.</div>
<div><br>
</div>
<div>Once you stop trying to make what Python calls `rand/randint` and `choice/sample` have the same names, then finding a Swifty design for the distinct facilities becomes much easier, and it suggests a pretty elegant result (IMO):</div>
<div><br>
</div>
<div>```</div>
<div>[1, 2, 3, 4].choice // like `first` or `last`, this gets you a value of type Int?</div>
<div>[1, 2, 3, 4].sampling(2) // like `prefix(2)` or `suffix(2)`, this gets you a subsequence with at most two elements</div>
<div><br>
</div>
<div>Int.random // this gets you a random Int; or it may trap</div>
<div>Float.random // this gets you a random Float; or it may trap</div>
<div>```</div>
<div><br>
</div>
<div>With that, it also becomes clear why--and I agree with you--an independent `Int.random(in: 0..<5)` is not necessary. `(0..<5).choice` is fine, and it can now appropriately return a value of type `T?` because it no longer needs to parallel `Int.random`.</div>
<div><br>
</div>
<div>* * *</div>
<div>
<div><br>
</div>
<div>More in the bikeshedding arena, I take issue with some of the names:</div>
<div><br>
</div>
<div>- I reiterate my comment that `Randomizable` is not the best name. There are multiple dictionary definitions of "randomize" and one is "make unpredictable, unsystematic, or random in order or arrangement." Wikipedia gives at least five different contextual
meanings for the word. What you're doing here is specifically **random sampling** and we can do better to clarify that, I think.</div>
<div><br>
</div>
<div>- While I agree that `RNG` can be cryptic, the alternative should be `RandomNumberGenerator` (as it's called in other languages); `RandomGenerator` is not quite accurate. Again, we're _consuming_ randomness to _generate_ numbers (or values of other type,
based on the result of a generated number). We're not _generating_ randomness.</div>
<div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Nov 5, 2017 at 6:33 PM, Alejandro Alonso <span dir="ltr">
<<a href="mailto:aalonso128@outlook.com" target="_blank">aalonso128@outlook.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:5px 5px;padding-left:10px;border-left:thin solid #e67e22">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<a href="https://github.com/apple/swift-evolution/pull/760" target="_blank">https://github.com/apple/swift<wbr>-evolution/pull/760</a> is the current API and proposed solution.</div>
<div class="m_-2469532730539551817gmail-HOEnZb"><font color="#888888"></font>
<div name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<font color="#888888"><br>
- Alejandro</font></div>
</div>
<div>
<div class="m_-2469532730539551817gmail-h5">
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
On Nov 5, 2017, 6:18 PM -0600, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>, wrote:<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #3498db">
<div dir="ltr">
<div>My comments are directed to the "more up-to-date" document that you just linked to in your reply to Jon. Is that one outdated? If so, can you send a link to the updated proposal and implementation for which you're soliciting feedback?</div>
<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Nov 5, 2017 at 6:12 PM, Alejandro Alonso <span dir="ltr">
<<a href="mailto:aalonso128@outlook.com" target="_blank">aalonso128@outlook.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:5px 5px;padding-left:10px;border-left:thin solid #d35400">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
The proposal and implementation have the current updated API. The link I sent Jon was the one I brought up a few weeks ago which is outdated now. The proposal answers all of your questions. As for `.random` being a function, some would argue that it behaves
in the same way as `.first` and `.last` which are properties.</div>
<div class="m_-2469532730539551817gmail-m_6864370541989554965HOEnZb"><font color="#888888"></font>
<div name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<font color="#888888"><br>
- Alejandro</font></div>
</div>
<div>
<div class="m_-2469532730539551817gmail-m_6864370541989554965h5">
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
On Nov 5, 2017, 6:07 PM -0600, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>, wrote:<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #34495e">
<div dir="ltr">A few quick thoughts:
<div><br>
</div>
<div>I know that there's been some discussion that `(1...10).random` is the best spelling, but I'd like to push back on that suggestion. When I want a random number, I tend to think of the type I want first ("I want a random integer") and then a range ("I want
a random integer between a and b"), not the other way around. My intuition is that `Int.random(in:)` will be more discoverable, both on that basis and because it is more similar to other languages' syntax (`Math.random` in JavaScript and `randint` in NumPy,
for example). It also has the advantage that the type is explicit, which I think is particularly useful in this case because the value itself is, well, random.</div>
<div><br>
</div>
<div>I would also argue that, `random` is most appropriately a method and not a property; there's no hard and fast rule for this, but the fact that the result is stochastic suggests (to me) that it's not a "property" of the range (or, for that matter, of the
type).</div>
<div><br>
</div>
<div>
<div>I would reiterate here my qualms about `Source` being the term used for a generator. These types are not a _source_ of entropy but rather a _consumer_ of entropy.</div>
</div>
<div><br>
</div>
<div>`UnsafeRandomSource` needs to be renamed; "unsafe" has a specific meaning in Swift--that is, memory safety, and this is not it. Moreover, it's questionable whether this protocol is useful in any sense. What useful generic algorithms can one write with
such a protocol?</div>
<div><br>
</div>
<div>`XoroshiroRandom` cannot be seeded by any `Numeric` value; depending on the specific algorithm it needs a seed of a specific bit width. If you default the shared instance to being seeded with an `Int` then you will have to have distinct implementations
for 32-bit and 64-bit platforms. This is unadvisable. On that note, your `UnsafeRandomSource` needs to have an associated type and not a generic `<T : Numeric>` for the seed.<br>
</div>
<div><br>
</div>
<div>The default random number generator should be cryptographically secure; however, it's not clear to me that it should be device random.</div>
<div><br>
</div>
<div>I agree with others that alternative random number generators other than the default RNG (and, if not default, possibly also the device RNG) should be accommodated by the protocol hierarchy but not necessarily supplied in the stdlib.</div>
<div><br>
</div>
<div>The term `Randomizable` means something specific which is not how it's used in your proposed protocol. </div>
<div><br>
</div>
<div>There's still the open question, not answered, about how requesting an instance of the hardware RNG behaves when there's insufficient or no entropy. Does it return nil, throw, trap, or wait? The proposed API does not clarify this point, although based
on the method signature it cannot return nil or throw. Trapping might be acceptable but I'd be interested to hear your take as to why it is preferable.</div>
<div><br>
</div>
<div><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">On Sun, Nov 5, 2017 at 4:43 PM, Alejandro Alonso via swift-evolution
<span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:5px 5px;padding-left:10px;border-left:thin solid #2ecc71">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
For the proof of concept, I had accidentally deleted that one. I have a more up to date one which was discussed a few weeks later. <a href="https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1" target="_blank">https://gist.github.com<wbr>/Azoy/15f0518df38df9b722d4cb17<wbr>bafea4c1</a></div>
<div name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
- Alejandro</div>
<div>
<div class="m_-2469532730539551817gmail-m_6864370541989554965m_1947579187318224822gmail-h5">
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
On Nov 5, 2017, 4:37 PM -0600, Jonathan Hull <<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>>, wrote:<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #9b59b6">
Is there a link to the writeup? The one in the quote 404s.
<div><br>
</div>
<div>Thanks,</div>
<div>Jon</div>
<div><br>
<div>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #e74c3c">
<div>On Nov 5, 2017, at 2:10 PM, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div>
<br class="m_-2469532730539551817gmail-m_6864370541989554965m_1947579187318224822gmail-m_3739135728595962658Apple-interchange-newline">
<div>
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
Hello once again Swift evolution community. I have taken the time to write up the proposal for this thread, and have provided an implementation for it as well. I hope to once again get good feedback on the overall proposal.</div>
<div name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
- Alejandro</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>, wrote:<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #1abc9c">
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
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" target="_blank">https://gist.github.com/A<wbr>zoy/5d294148c8b97d20b96ee64f43<wbr>4bb4f5</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><br>
</div>
<div>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><br>
</div>
<div>I’d like to hear about your ideas on this proposal, or any implementation changes if need be.</div>
<div><br>
</div>
<div>- Alejando</div>
</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
<div></div>
</div>
</blockquote>
</div>
</div>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div></div></div>
</blockquote></div><br></div></div>