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 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
> <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>>
>>>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
