[swift-evolution] [Proposal] Random Unification

Wed Jan 10 00:14:01 CST 2018

On Tue, Jan 9, 2018 at 5:12 AM, Jonathan Hull via swift-evolution <
swift-evolution at 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 at 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 at 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 at swift.org> wrote:
>
>
> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/4796da34/attachment.html>