Re: [swift-evolution] [Proposal] Random Unification

On Sat, Jan 13, 2018 at 10:29 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > I think a full random implementation should be decoupled from Swift's > standard library and generic random is overkill. > > In-language, I think pre-seeded random uniform (0 ..< 1, > `Double.un

Re: [swift-evolution] [Proposal] Random Unification

I think a full random implementation should be decoupled from Swift's standard library and generic random is overkill. In-language, I think pre-seeded random uniform (0 ..< 1, `Double.uniformRandom()`), random int (0 ..< max, `Int.uniform(max)`), and random index for indexed collection (`collec

Re: [swift-evolution] [Proposal] Random Unification

For a range of 0..<(2< On Jan 13, 2018, at 7:41 PM, C. Keith Ray via swift-evolution > wrote: > > Could someone measure how bad the "random(32 bits) mod m" problem actually > is? It's prominent when the number of bits is close to m, eg 4 bits and m == > 3. Is it bad when bits == 32 and m is le

Re: [swift-evolution] [Proposal] Random Unification

Could someone measure how bad the "random(32 bits) mod m" problem actually is? It's prominent when the number of bits is close to m, eg 4 bits and m == 3. Is it bad when bits == 32 and m is less than 2^16? Or bits == 64 and m is less than 2^32? C. Keith Ray https://leanpub.com/wepntk <- buy my

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 12, 2018, at 8:22 PM, Nate Cook wrote: > > On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I think we have different definitions of consistency. I am fine with the >> ergonomics of (0…100).random() as a convenience, but

Re: [swift-evolution] [Proposal] Random Unification

Basically, my point is that I want to be able to operate generically. > On Jan 13, 2018, at 5:20 AM, Letanyan Arumugam wrote: > > >> On 13 Jan 2018, at 02:24, Jonathan Hull > > wrote: >> >> I think we have different definitions of consistency. I am fine with the >> erg

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 13, 2018, at 5:20 AM, Letanyan Arumugam wrote: > > >> On 13 Jan 2018, at 02:24, Jonathan Hull > > wrote: >> >> I think we have different definitions of consistency. I am fine with the >> ergonomics of (0…100).random() as a convenience, but it really worries me

Re: [swift-evolution] [Proposal] Random Unification

> On 13 Jan 2018, at 02:24, Jonathan Hull wrote: > > I think we have different definitions of consistency. I am fine with the > ergonomics of (0…100).random() as a convenience, but it really worries me > here that everything is special cased. Special cased things are fine for > individual p

Re: [swift-evolution] [Proposal] Random Unification

On Fri, Jan 12, 2018 at 10:23 PM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > I think we have different definitions of consistency. I am fine with the > ergonomics of (

Re: [swift-evolution] [Proposal] Random Unification

> On 13. Jan 2018, at 05:23, Nate Cook via swift-evolution > wrote: > > On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I think we have different definitions of consistency. I am fine with the >> ergonomics of (0…100).random()

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > wrote: > > I think we have different definitions of consistency. I am fine with the > ergonomics of (0…100).random() as a convenience, but it really worries me > here that everything is special cased. Special cased things are

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 12, 2018, at 4:24 PM, Jonathan Hull wrote: > > Or what if I want an effect where it randomly fades in letters from a String. Just to explain this example further. I ran into this issue when trying to use arc4random to do this. The eye is really sensitive to patterns in cases like t

Re: [swift-evolution] [Proposal] Random Unification

I think we have different definitions of consistency. I am fine with the ergonomics of (0…100).random() as a convenience, but it really worries me here that everything is special cased. Special cased things are fine for individual projects, but not the standard library. We should make sure th

Re: [swift-evolution] [Proposal] Random Unification

We are doing crazy contortions to avoid the 'random % 100’ issue. Why not just check for that pattern and issue a warning with a fixit to do it better? I don’t think it is worth handicapping everything just to avoid this. Thanks, Jon > On Jan 11, 2018, at 11:22 PM, Nate Cook via swift-evoluti

Re: [swift-evolution] [Proposal] Random Unification

Done and done! Sent from my iPhone On Jan 12, 2018, at 01:22, Nate Cook mailto:natec...@apple.com>> wrote: On Jan 11, 2018, at 9:17 PM, Alejandro Alonso mailto:aalonso...@outlook.com>> wrote: Sorry it takes me forever to respond! I finally got around to writing this! School really takes all

Re: [swift-evolution] [Proposal] Random Unification

Give up* Sent from my iPhone On Jan 12, 2018, at 08:10, Alejandro Alonso via swift-evolution mailto:swift-evolution@swift.org>> wrote: I am willing to give `.random()`. However I still wish to preserve `.random(in:)` and `.random()` on Bool. Sent from my iPhone On Jan 11, 2018, at 21:28, Xia

Re: [swift-evolution] [Proposal] Random Unification

(0 ..< 10).random() would return an optional Int.random(in: 0 ..< 10) would return a non optional (this is the one that crashes on bad range) Sent from my iPhone On Jan 12, 2018, at 07:11, Letanyan Arumugam mailto:letanya...@gmail.com>> wrote: Nate’s design follows a consistent idea of getting

Re: [swift-evolution] [Proposal] Random Unification

I am willing to give `.random()`. However I still wish to preserve `.random(in:)` and `.random()` on Bool. Sent from my iPhone On Jan 11, 2018, at 21:28, Xiaodi Wu mailto:xiaodi...@gmail.com>> wrote: On Thu, Jan 11, 2018 at 9:17 PM, Alejandro Alonso via swift-evolution mailto:swift-evolution@

Re: [swift-evolution] [Proposal] Random Unification

Nate’s design follows a consistent idea of getting a random value from some set of values. Adding the static method random() to a type essentially creates an implicit set which you yourself said leads to inconsistency (Double/Int). Secondly I don’t see why random(in:) should be added when it is

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 11, 2018, at 9:17 PM, Alejandro Alonso wrote: > > Sorry it takes me forever to respond! I finally got around to writing this! > School really takes all my time x) > > I have a few ideas on where we can go with this: > > 1. I agree, we should ditch `Randomizable` as something like that

Re: [swift-evolution] [Proposal] Random Unification

On Thu, Jan 11, 2018 at 9:17 PM, Alejandro Alonso via swift-evolution < swift-evolution@swift.org> wrote: > Sorry it takes me forever to respond! I finally got around to writing > this! School really takes all my time x) > > I have a few ideas on where we can go with this: > > 1. I agree, we shoul

Re: [swift-evolution] [Proposal] Random Unification

Sorry it takes me forever to respond! I finally got around to writing this! School really takes all my time x) I have a few ideas on where we can go with this: 1. I agree, we should ditch `Randomizable` as something like that should belong in a separate library or written by the user. 2. I als

Re: [swift-evolution] [Proposal] Random Unification

If anything, Nate’s design is inconsistent as properties like `.first` and `.last` return an optional, and methods like `.min()` and `.max()` return an optional as well. Having `.random()` on ranges be an exception and return non optionals are inconsistent with other collection facilities, and w

Re: [swift-evolution] [Proposal] Random Unification

This is really cool and seems very powerful. However I don’t think we should sacrifice consistency for extendability. Especially when the extendability would not be what most people need. What I am basically trying to say is that. I think the proposals current design direction fits better in a

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 10, 2018, at 4:42 PM, Nate Cook wrote: > > I don’t see how a single distribution would generate both integers and > colors. Can your color type be initialized from an integer? Since the > “distributions” in that playground are just sequences, you could add > .lazy.map({ Color(value:

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 10, 2018, at 4:42 PM, Nate Cook wrote: >> Right. I guess my thought is that I would like them to be able to use a >> standard creation pattern so it doesn’t vary from type to type (that is the >> whole point of “unification” in my mind). In my own code, I have a concept >> of constra

Re: [swift-evolution] [Proposal] Random Unification

On Wed, Jan 10, 2018 at 6:02 PM, Jens Persson via swift-evolution < swift-evolution@swift.org> wrote: > I agree. > > If there should be an API to produce a random Double without parameters > then IMHO it should simply be a uniformly distributed Double in the unit > range [0, 1). Very useful as a b

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 9, 2018, at 3:07 PM, Jonathan Hull wrote: > >> >> On Jan 9, 2018, at 8:28 AM, Nate Cook > > wrote: >> >>> On Jan 9, 2018, at 4:12 AM, Jonathan Hull >> > wrote: >>> >>> Some thoughts: >>> >>> - How do I randomly select an enum? >> >>

Re: [swift-evolution] [Proposal] Random Unification

on Thu, 11 Jan 2018 00:02:18 +0100 Jens Persson wrote: If there should be an API to produce a random Double without parameters > then IMHO it should simply be a uniformly distributed Double in the unit > range [0, 1). Very useful as a basic building block... [0..1) sounds reasonable. even if di

Re: [swift-evolution] [Proposal] Random Unification

I agree. If there should be an API to produce a random Double without parameters then IMHO it should simply be a uniformly distributed Double in the unit range [0, 1). Very useful as a basic building block and can be constructed very fast from a random bitpattern like eg: extension Double { in

Re: [swift-evolution] [Proposal] Random Unification

Which begs the question: why would you want to do something like this? Creating a “random” Double from its full range of values is an odd thing to do, and the fact that it is non-uniform and has irregularities like infinity and signed zeros makes it likely that any such usage is probably done in

Re: [swift-evolution] [Proposal] Random Unification

On Wed, Jan 10, 2018 at 11:27 PM, Saagar Jha wrote: > Not a floating point expert, but are you sure this works? I have a feeling > this would lead to a distribution that’s not uniform. > > Yes, it would not be uniform, which is exactly what I meant by the last part of: "Assuming you are ok with s

Re: [swift-evolution] [Proposal] Random Unification

Not a floating point expert, but are you sure this works? I have a feeling this would lead to a distribution that’s not uniform. Saagar Jha > On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution > wrote: > > On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution > mailto:s

Re: [swift-evolution] [Proposal] Random Unification

On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > > One additional question. How do you ergonomically get a Double which > doesn’t have a range, but also isn’t NaN? > > Assuming you are ok with signed zero and infinities and "strange" bias as

Re: [swift-evolution] [Proposal] Random Unification

On Tue, Jan 9, 2018 at 5:12 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Some thoughts: > > - How do I randomly select an enum? > carefully, of course > > - I like that RandomNumberGenerator doesn’t have an associated type. I > agree that we should just spit out U

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 9, 2018, at 8:28 AM, Nate Cook wrote: > >> On Jan 9, 2018, at 4:12 AM, Jonathan Hull > > wrote: >> >> Some thoughts: >> >> - How do I randomly select an enum? > > Vote for SE-0194! :) > >> - I like that RandomNumberGenerator doesn’t have an associated type. I

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 9, 2018, at 11:01 AM, Ben Cohen via swift-evolution > wrote: > > > >> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> - Why bother supporting non-closed Ranges at all? If you only allow closed >> ranges, then you c

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution > wrote: > > - Why bother supporting non-closed Ranges at all? If you only allow closed > ranges, then you can’t end up with an empty range. The only difference in > behavior I can think of is on floating point, but I can’t thi

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 9, 2018, at 4:12 AM, Jonathan Hull wrote: > > Some thoughts: > > - How do I randomly select an enum? Vote for SE-0194! :) > - I like that RandomNumberGenerator doesn’t have an associated type. I agree > that we should just spit out UInt64s for simplicity. It simplifies things a lot,

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 9, 2018, at 3:12 AM, Jonathan Hull via swift-evolution > wrote: > > Some thoughts: > > - How do I randomly select an enum? Well… combine this with SE-0194 and you have all the basics you need: the set of all enum values in a collection, and a way to pick a random element from a co

Re: [swift-evolution] [Proposal] Random Unification

On Tue, Jan 9, 2018 at 05:12 Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Some thoughts: > > - How do I randomly select an enum? > > - I like that RandomNumberGenerator doesn’t have an associated type. I > agree that we should just spit out UInt64s for simplicity. > > -

Re: [swift-evolution] [Proposal] Random Unification

Some thoughts: - How do I randomly select an enum? - I like that RandomNumberGenerator doesn’t have an associated type. I agree that we should just spit out UInt64s for simplicity. - I don’t like how it is so closely tied with Range. I realize that both Int and Float work with Ranges, but oth

Re: [swift-evolution] [Proposal] Random Unification

Agreed. This simplification is more or less precisely the shape of the proposal that I was hoping for. I'm worried that "optional" `random()` and "non-optional" `random()` are spelled the same way, especially as the type is not always obvious when, say, a range or collection is referred to by vari

Re: [swift-evolution] [Proposal] Random Unification

Unfortunately, it wasn’t my only worry. The simplifications from dropping Randomizable and random(in: ) are also very welcome for me. > On 8 Jan 2018, at 23:08, Alejandro Alonso wrote: > > I made changes last night that uses methods rather than properties if that’s > all you’re worried about.

Re: [swift-evolution] [Proposal] Random Unification

> On 08 Jan 2018, at 21:02, Nate Cook via swift-evolution > wrote: > > I created a playground to explore this question, starting with a minimal > subset of the proposal’s additions and building from there. The attached > playground demonstrates what’s possible with this subset on the first pa

Re: [swift-evolution] [Proposal] Random Unification

I made changes last night that uses methods rather than properties if that’s all you’re worried about. Sent from my iPhone On Jan 8, 2018, at 15:27, David Hart via swift-evolution mailto:swift-evolution@swift.org>> wrote: I much prefer the API from Nate Cook compared to the previous proposal.

Re: [swift-evolution] [Proposal] Random Unification

I much prefer the API from Nate Cook compared to the previous proposal. Its simpler, while still very powerful, and closer to Swift conventions (method instead of property). > On 8 Jan 2018, at 20:02, Nate Cook via swift-evolution > wrote: > > I created a playground to explore this question,

Re: [swift-evolution] [Proposal] Random Unification

On Tue, Jan 2, 2018 at 10:19 AM, Dave DeLong via swift-evolution < swift-evolution@swift.org> wrote: > Just skimmed through the updated proposal and am weighing in with my naïve > opinions: > > >- I’m still highly skeptical of a static “T.random” API. I’ve yet to >see a convincing example

Re: [swift-evolution] [Proposal] Random Unification

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. I agree that random() is better as a method. I also think that the default

Re: [swift-evolution] [Proposal] Random Unification

Just skimmed through the updated proposal and am weighing in with my naïve opinions: 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 “pi

Re: [swift-evolution] [Proposal] Random Unification

On Tue, Jan 2, 2018 at 2:35 AM, Alejandro Alonso via swift-evolution < swift-evolution@swift.org> wrote: > 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 problem

Re: [swift-evolution] [Proposal] Random Unification

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: https://github.com

Re: [swift-evolution] [Proposal] Random Unification

On Wed, Dec 20, 2017 at 13:13 Jens Persson wrote: > Oh OK, I must have misunderstood this thread: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html > ( > "The strong opinion of the core team is that such an API should *not* be > designed with an attempt to ser

Re: [swift-evolution] [Proposal] Random Unification

Oh OK, I must have misunderstood this thread: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html ( "The strong opinion of the core team is that such an API should *not* be designed with an attempt to service people writing crypto code." "It is general goodness if gen

Re: [swift-evolution] [Proposal] Random Unification

xoroshiro128+ is not a cryptographically secure algorithm and would not be incorporated into the Random API, though it is trivial to implement your own; the proposal outlines sources of randomness that are cryptographically secure. On Wed, Dec 20, 2017 at 09:46 Jens Persson via swift-evolution <

Re: [swift-evolution] [Proposal] Random Unification

I'd like to add a pointer to the information here: http://xoroshiro.di.unimi.it since AFAICS, the xoroshiro128+ generator and the method of "Generating uniform doubles in the unit interval" should probably be implemented in any modern general purpose Random API. Please correct me if there are mor

Re: [swift-evolution] [Proposal] Random Unification

I don’t have much to say about this other than that I think the discussion seems way too narrow, focusing on spelling rather than on functionality and composability. I consider the “generic random number library” design to be a mostly-solved problem, in the C++ standard library (http://en.cppr

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution > wrote: > > Instead, we ought to make clear to users both the features and the > limitations of this API, to encourage use where suitable and to discourage > use where unsuitable. I like that you're considering the balance here. I'

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution > wrote: > > My point is that our entire design process has been geared towards a > reasonable, best-effort general-use API: It is being designed by community > members who are not specialized in this particular subfield. It is expli

Re: [swift-evolution] [Proposal] Random Unification

On Sat, Dec 2, 2017 at 19:02 Greg Parker wrote: > > On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon > wrote: > >> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution < >> swift-evolution

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon > wrote: >> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> That said, I am

Re: [swift-evolution] [Proposal] Random Unification

On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon wrote: > On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > That said, I am not sure that this proposal should give any pretense of > being suitable for cryptographic use. On implementation, the c

Re: [swift-evolution] [Proposal] Random Unification

On Dec 1, 2017, at 11:23 PM, David Waite wrote: > > > >> On Dec 1, 2017, at 11:05 AM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I'd like to put forth that Gameplay Kit offers a perfectly cromulent model >> of random number generation and API. Why not

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution > wrote: > > That said, I am not sure that this proposal should give any pretense of being > suitable for cryptographic use. On implementation, the code will not have > been audited for that purpose, although the author very rightly

Re: [swift-evolution] [Proposal] Random Unification

eatable, faster, more > secure, etc. > Yes, I understand. Even then: is a struct that has two stored properties more secure when it is initialized with two more secure values? That may depend on what the struct does with those values, no? > -Nate >> >> >> 👍 >>&g

Re: [swift-evolution] [Proposal] Random Unification

On Sat, Dec 2, 2017 at 12:23 AM, David Waite wrote: > > > On Dec 1, 2017, at 11:05 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > > I'd like to put forth that Gameplay Kit offers a perfectly cromulent model > of random number generation and API. Why not take that as a

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 1, 2017, at 11:05 AM, Erica Sadun via swift-evolution > wrote: > > I'd like to put forth that Gameplay Kit offers a perfectly cromulent model of > random number generation and API. Why not take that as a starting point, > Swiftify it so it becomes a cross platform solution, and then

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 1, 2017, at 9:39 AM, Martin Waitz wrote: > > Hi, > >> With a protocol defining random() and random(in:), you could write generic >> algorithms on things which know how to create themselves from a RNG. With >> your approach the RNG has to provide a way to get a random value for each

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 5:21 PM, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Nov 30, 2017 at 5:24 PM, Nate Cook > wrote: >> On Nov 30, 2017, at 4:30 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Thu, Nov 30, 2017 at 3

Re: [swift-evolution] [Proposal] Random Unification

Hi, > With a protocol defining random() and random(in:), you could write generic > algorithms on things which know how to create themselves from a RNG. With > your approach the RNG has to provide a way to get a random value for each > type you want to support. This is right, if we want a gene

Re: [swift-evolution] [Proposal] Random Unification

on Thu, 30 Nov 2017 15:08:55 -0800 Jonathan Hull wrote: > > I think it is important to have Type.random as the base because there are > many types which would conform (not just Int & Double). what would Double.random return though? a "uniformly distributed value" in the range minus DBL_MAX ...

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 11:11 PM, Martin Waitz wrote: > > Hello, > >> The collection is a subject which has elements, and we are asking for one of >> them at random. > > it has elements, sure. > And because of its structure, it has a first and a last element and whatever. > But that random elem

Re: [swift-evolution] [Proposal] Random Unification

Hello, > The collection is a subject which has elements, and we are asking for one of > them at random. it has elements, sure. And because of its structure, it has a first and a last element and whatever. But that random element is not an inherent property of the collection. I find it much more

Re: [swift-evolution] [Proposal] Random Unification

different distributions by passing different RNGs. Is there any way any of this works for an RNG that isn't providing uniform random bits? I don't understand how any of these primitive methods would work with an RNG that was doing something different, regardless of how the methods are spel

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 4:11 PM, Xiaodi Wu wrote: > > On Thu, Nov 30, 2017 at 5:29 PM, Jonathan Hull > wrote: > >> On Nov 30, 2017, at 2:30 PM, Xiaodi Wu > > wrote: >> >> On Thu, Nov 30, 2017 at 3:58 PM, Dave DeLong via swift-evolution >> mail

Re: [swift-evolution] [Proposal] Random Unification

lar. All the methods can be summarized as >> selecting a single random element from a collection >> `[0, 2, 3].random` selects a single element from the given collection >> `Int.random(in: 0…8)` selects a single element from the given range >> `Int.random` has no range, but

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 3:46 PM, Martin Waitz wrote: > > Hello Jonathan, > >> For collections, I think we should call returning a random element >> -randomElement, and choosing a random element without replacement >> -popRandomElement > > I disagree because I don’t think that the random data is

Re: [swift-evolution] [Proposal] Random Unification

m`s have different semantics, but to me (at >>>> least), they are all very similar. All the methods can be summarized as >>>> selecting a single random element from a collection >>>> `[0, 2, 3].random` selects a single element from the given collection >>&

Re: [swift-evolution] [Proposal] Random Unification

evolution < >> swift-evolution@swift.org> wrote: >> >> You say that all the `.random`s have different semantics, but to me (at >> least), they are all very similar. All the methods can be summarized as >> selecting a single random element from a collection >&g

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 5:02 PM, Jonathan Hull wrote: > > >> On Nov 30, 2017, at 3:52 PM, Dave DeLong > > wrote: >> >> What is the useful distinction between generating a random value, and >> choosing a random element from a collection of all possible values? > >

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 3:52 PM, Dave DeLong wrote: > > What is the useful distinction between generating a random value, and > choosing a random element from a collection of all possible values? I don’t have to generate (or keep in memory) that collection. I gave an example before of an easy

Re: [swift-evolution] [Proposal] Random Unification

Hi, >>> This is redundant. In order to pick a random element, you’re saying I >>> should have to do “Int.random(0 ..< 10)”? The redundancy here is that I >>> have to specify Int twice: once for the “.random” call, and again for the >>> type of the range. We can do better than that. > > I don’t

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 4:46 PM, Jonathan Hull wrote: > >> >> On Nov 30, 2017, at 3:19 PM, Dave DeLong > > wrote: >> >> >> >>> On Nov 30, 2017, at 4:08 PM, Jonathan Hull >> > wrote: >>> >>> On Nov 30, 2017, at 1:58 PM, Dave DeLong >>>

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 3:19 PM, Dave DeLong wrote: > > > >> On Nov 30, 2017, at 4:08 PM, Jonathan Hull > > wrote: >> >> >>> On Nov 30, 2017, at 1:58 PM, Dave DeLong >> > wrote: >>> >>> >>> On Nov 30, 2017, at 2:48 PM, Jonathan Hull v

Re: [swift-evolution] [Proposal] Random Unification

Hello Jonathan, > For collections, I think we should call returning a random element > -randomElement, and choosing a random element without replacement > -popRandomElement I disagree because I don’t think that the random data is a property of the collection. The collection is not the subject

Re: [swift-evolution] [Proposal] Random Unification

Don’t forget that if you already know the type, you can leave out the type name, so for example, to supply a random bool a function, you could just use `.random()` instead of `Bool.random()`, which removes a lot of the extra redundant type names. > 2017/11/30 17:19、Dave DeLong のメール: > > > >>

Re: [swift-evolution] [Proposal] Random Unification

om the collection >>> of all ints (equivalent to if the above method had a default value for its >>> range) >>> So to me these are all doing the same operation, just with different types >>> of inputs >>> >>>> 2017/11/24 20:07、Alejandro A

Re: [swift-evolution] [Proposal] Random Unification

`Int.random(in: 0…8)` selects a single element from the given range >>> `Int.random` has no range, but selects a single element from the collection >>> of all ints (equivalent to if the above method had a default value for its >>> range) >>> So to me these are a

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 30, 2017, at 4:08 PM, Jonathan Hull wrote: > > >> On Nov 30, 2017, at 1:58 PM, Dave DeLong > > wrote: >> >> >> >>> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> I would personally

Re: [swift-evolution] [Proposal] Random Unification

similar. All the methods can be summarized as >>>> selecting a single random element from a collection >>>> `[0, 2, 3].random` selects a single element from the given collection >>>> `Int.random(in: 0…8)` selects a single element from the given range >>>> `Int.rand

Re: [swift-evolution] [Proposal] Random Unification

t;> selecting a single random element from a collection >>>> `[0, 2, 3].random` selects a single element from the given collection >>>> `Int.random(in: 0…8)` selects a single element from the given range >>>> `Int.random` has no range, but selects a single element from

Re: [swift-evolution] [Proposal] Random Unification

o to me these are all doing the same operation, just with different types >>> of inputs >>> >>>> 2017/11/24 20:07、Alejandro Alonso >>> <mailto:aalonso...@outlook.com>>のメール: >>>> >>>> >>>> - Alejandro >>>>

Re: [swift-evolution] [Proposal] Random Unification

t;> `Int.random(in: 0…8)` selects a single element from the given range >>> `Int.random` has no range, but selects a single element from the collection >>> of all ints (equivalent to if the above method had a default value for its >>> range) >>> So to me

Re: [swift-evolution] [Proposal] Random Unification

all doing the same operation, just with different types > of inputs > > 2017/11/24 20:07、Alejandro Alonso のメール: > > > - Alejandro > > -- Forwarded message -- > *From:* Xiaodi Wu > *Date:* Nov 24, 2017, 3:05 PM -0600 > *To:* Alejandro Alonso > *Cc:

Re: [swift-evolution] [Proposal] Random Unification

Steve Canon via swift-evolution <swift-evolution@swift.org> Subject: Re: [swift-evolution] [Proposal] Random Unification On Fri, Nov 24, 2017 at 2:55 PM, Alejandro Alonso <aalonso...@outlook.com> wrote: Regarding naming too many things “random”, I’ve talked to many developers on m

Re: [swift-evolution] [Proposal] Random Unification

For collections, I think we should call returning a random element -randomElement, and choosing a random element without replacement -popRandomElement var list = [1,2,3,4] let a:Int? = list.randomElement //List is still [1,2,3,4] and ‘a’ contains one of the elements let b:Int? = list.popRandomE

Re: [swift-evolution] [Proposal] Random Unification

00 >> To: Alejandro Alonso mailto:aalonso...@outlook.com>> >> Cc: Brent Royal-Gordon > <mailto:br...@architechies.com>>, Steve Canon via swift-evolution >> mailto:swift-evolution@swift.org>> >> Subject: Re: [swift-evolution] [Proposal] Random Unification &g

Re: [swift-evolution] [Proposal] Random Unification

Right—again, this is yet another difference between two things both named “random” in this proposal. Almost always, when we say “give me two random integers,” we want independent random samples from the set of all integers. But for collections, a very common (and probably more common operation) is

Re: [swift-evolution] [Proposal] Random Unification

Hi Erica, > Doesn't `choose` usually take two arguments, the `count` to choose > (presumably defaulting to 1) and the collection to choose `from`? This might be useful for collections, when you want to draw several elements without drawing the same element twice. For ranges of random numbers yo

Re: [swift-evolution] [Proposal] Random Unification

> On 28. Nov 2017, at 00:20, Martin Waitz via swift-evolution > wrote: > > Hello, > >> Maybe we call the default RNG instance `random`, and then give the >> `random(in:)` methods another name, like `choose(in:)`? >> >> let diceRoll = random.choose(in: 1...6) >> let card = random.c

  1   2   3   >