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, >

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

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

For a range of 0..<(2<

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 > > wrote: > >> I think we have different definitions of consistency. I am fine with the >>

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

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()

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

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 > > wrote: > >> I think we have different definitions of

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

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

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

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

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

Done and done! Sent from my iPhone On Jan 12, 2018, at 01:22, Nate Cook > wrote: On Jan 11, 2018, at 9:17 PM, Alejandro Alonso > wrote: Sorry it takes me forever to respond! I finally got

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

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

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 > wrote: Nate’s design follows a

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 > wrote: On Thu, Jan 11, 2018 at 9:17 PM, Alejandro Alonso via 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

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

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

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

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

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 >

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

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

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

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

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 {

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

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:

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

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

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

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

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 >> > wrote: >> >> - Why bother supporting non-closed Ranges

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

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

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

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

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

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 >

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

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 > wrote: I much prefer the API from Nate Cook

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

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

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

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:

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

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

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

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

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

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

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,

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 >>

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.

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 >> > wrote: >> >> I'd like to put forth that Gameplay Kit offers a perfectly

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,

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

le/repeatable, 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

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

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 >>

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

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

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.

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

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

that was doing something different, regardless of how the methods are spelled. The purpose of the (using:) versions is to allow for RNGs that meet different requirements from the default: seedable/repeatable, faster, more secure, etc. > >> -Nate >> >> >>&g

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,

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

ds 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 selects a single ele

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

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

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 the >&

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

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

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

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:

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:

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

just with different types >>> of inputs >>> >>>> 2017/11/24 20:07、Alejandro Alonso <aalonso...@outlook.com >>>> <mailto:aalonso...@outlook.com>>のメール: >>>> >>>> >>>> - Alejandro >>>> >>>> ---

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

ll 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 Alonso <aalonso...@outlook.com >>>>

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 >>>

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

ent 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 the >>>> collection of all ints (equivalent to if the above method had a default >>>>

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

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

uivalent 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 Alonso <aalonso...@outlook.com >>>

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

f 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 Alonso <aalonso...@outlook.com >>>&

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

tion, just with different types > of inputs > > 2017/11/24 20:07、Alejandro Alonso <aalonso...@outlook.com>のメール: > > > - Alejandro > > -- Forwarded message -- > *From:* Xiaodi Wu <xiaodi...@gmail.com> > *Date:* Nov 24, 2017, 3:05 PM -0600 >

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

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 my

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? =

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

di...@gmail.com <mailto:xiaodi...@gmail.com>> >> Date: Nov 24, 2017, 3:05 PM -0600 >> To: Alejandro Alonso <aalonso...@outlook.com <mailto:aalonso...@outlook.com>> >> Cc: Brent Royal-Gordon <br...@architechies.com >> <mailto:br...@architechies.com>>, Steve

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

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)

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

On Nov 28, 2017, at 11:10 PM, Thorsten Seitz via swift-evolution wrote: > > Shouldn't it be > > random.choose(from: 1...6) > > etc.? > > -Thorsten Doesn't `choose` usually take two arguments, the `count` to choose (presumably defaulting to 1) and the

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

Shouldn't it be random.choose(from: 1...6) etc.? -Thorsten > Am 28.11.2017 um 00:20 schrieb Martin Waitz via swift-evolution > : > > Hello, > >> Maybe we call the default RNG instance `random`, and then give the >> `random(in:)` methods another name, like

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

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.choose(in: deck) > let isHeads = random.choose(in: [true, false]) > let

  1   2   3   >