> On Jan 9, 2018, at 3:12 AM, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> 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 collection... > > - 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 other random types do not (e.g. CGVectors). > You are special casing FixedWidthInteger and BinaryFloatingPoint, which are > very important… but we lose the ability to deal with other randomly generated > types. > > - Following on the previous point, I don’t like that the code for dealing > with Integers/Floats is in Range. It feels like things aren’t properly > encapsulated. > > - 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 think of a use-case > where excluding the supremum is actually useful in any real world way. > > - This may sound strange, but I would really like to see Bool handled as a > default implementation on the generator protocol itself. On my own version > of this I have both the ‘coinFlip()’ and ‘oneIn(_ num:Int)’ methods which I > find extremely useful. CoinFlip just gives you a random bool, whereas you > can say things like oneIn(100) to get ‘true’ roughly 1 out of every 100 times > you call it. These are useful for branching randomly. They are most useful > on the source/generator itself because it is ergonomic when you need to > rewind the source. > > - IMO distributions should be sources/generators themselves which just wrap > another source. We could have a subprotocol of RandomNumberGenerator which > just semantically guarantees uniform distribution, and then distributions > that need it could be sure of the input distribution. Notice this doesn’t > limit the distribution to only be used for Integers as they are in the demo. > They can be used anywhere a source can be used. > > - Having a subprotocol for generators which can be rewound is extremely > important for entire classes of real-world problems. I have spent a lot of > time using this and it solves a LOT of problems. For example, I have a Lorem > Ipsum Generator which takes Attributes and a CGSize to fill. It works by > branching (using the Bool methods above) and then rewinding bits which don’t > fit (If you just futz with the last part instead of generating appropriate > clauses, it won’t look right). I also have a bunch of backtracking > algorithms which rely on this rewind ability. Plus numerous visual effects > which rely on a repeatable rewindable source. > - Tl;dr: It isn’t enough to just have a seed, you need to be able to > mark a state of a generator and return to that state later. > > My RepeatableRandomSource Protocol has 3 extra methods: > - It takes a seed > - It has a mark() method which returns a token > - It has a returnToMark(_ mark:Mark) method which takes a token and > restores the appropriate state > > - I really appreciate that you made a playground :-) > > Thanks, > Jon > > >> On Jan 8, 2018, at 11:02 AM, Nate Cook via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 page, >> then uses subsequent pages to explore how the main random facilities of the >> C++ STL work under this model. (In my opinion, they work pretty well!) >> >> The subset in the playground has three main differences from the proposal: >> - It doesn't include a Randomizable protocol or a random property on >> numeric types. >> - It doesn't include the static random(in:) methods on numeric types, >> either. >> - The RandomNumberGenerator protocol doesn't have an associated type. >> Instead, it requires all conforming types to produce UInt64 values. >> >> I’ve tried to include a bit of real-world usage in the playground to >> demonstrate what writing code would look like with these additions. Please >> take a look! >> >> Nate >> >> <Random.playground.zip> >> >>> On Dec 2, 2017, at 9:50 PM, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> 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.cppreference.com/w/cpp/numeric/random >>> <http://en.cppreference.com/w/cpp/numeric/random>). Whatever goes into the >>> Swift standard library does not need to have all those features right away, >>> but should support being extended into something having the same general >>> shape. IMO the right design strategy is to implement and use a Swift >>> version of C++’s facilities and only then consider proposing [perhaps a >>> subset of] that design for standardization in Swift. >>> >>> Sent from my iPad >>> >>> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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've been lightly >>>> following this thread and want to add my thoughts on keeping crypto and >>>> pseudorandomness out of the name of at least one random API intended for >>>> general use. >>>> >>>> For someone who doesn't know or care about the subtleties of insecure or >>>> pseudorandom numbers, I'm not sure that the name insecureRandom is >>>> effectively much different than badRandom, at least in terms of the >>>> information it conveys to non-experts. To Greg's point, that's the >>>> opposite of the signal that the API name should suggest because it's what >>>> most people should use most of the time. As you say, this API is being >>>> designed for general use. >>>> >>>> There's a cost to adding extra complexity to names, too. I don't think >>>> it's far-fetched to suspect that people who find insecureRandom in an >>>> autocomplete listing or search will think "Where's the plain random >>>> function?"... and then go looking for a community extension that will >>>> inevitably provide a trivial alias: func random() { return >>>> insecureRandom() }. That's the sort of adoption I'd expect from something >>>> for new programmers, like Swift Playgrounds. Someone's introduction to >>>> randomness in programming should probably involve no more than a >>>> straightforward mapping from the elementary definition, rather than >>>> forcing a teaching moment from more advanced math. >>>> >>>> I think there are better places for caveat information than in the API >>>> names themselves; documentation being one clear destination. This is in >>>> contrast with Unsafe*Pointer, where the safety element is critical enough >>>> to be elevated to be more than caveat-level information. You can go really >>>> far and create really cool things before these caveats start to apply. >>>> Using randomness as a black box in an intro programming environment seems >>>> like a much more common scenario than someone attempting to roll their >>>> first crypto by only reading API names and hoping for the best. >>>> >>>> -Kyle >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
