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 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. > generating “random vectors” is a *big* mood and it’s not as simple as varying on a range of *R*3. There’s a mild but non-trivial amount of work needed to get a uniform distribution and avoid degeneracies and division by zero. and “random” can mean different things, sometimes you want a random 2D disk of vectors that all live in some plane in 3D space because you need them to be perpendicular to something. And at any rate, CGVector is not a standard type, while Int and Float are. > > - 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. > i see this as an inconvenience for the sake of security theater. Usually when you want a random integer on a continuous range, you’re using them as indices into something. And indices go from 0 ..< count, not 0 ... (count - 1). if whatever you’re indexing into is empty, it’s empty. > > - 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> 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> 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). 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> wrote: > > > On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution < > 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 > 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 > > > > _______________________________________________ > 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
