[swift-evolution] [Proposal] Random Unification
Nevin Brackett-Rozinsky
nevin.brackettrozinsky at gmail.com
Wed Jan 10 21:57:37 CST 2018
On Wed, Jan 10, 2018 at 6:02 PM, Jens Persson via swift-evolution <
swift-evolution at 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 basic building block and can be constructed
> very fast from a random bitpattern like eg:
> extension Double {
> init(unitRange v: UInt64) {
> self = Double(v >> Double.exponentBitCount) * (.ulpOfOne/2.0)
> }
> }
>
The implementation of randomness for floating point types deserves in-depth
consideration. I know that we have some IEEE-754 experts on this list, and
it would be great to have them weigh in. For instance…
When generating a uniformly-distributed floating point number in a
half-open range with finite bounds, should every representable value in
that range be possible to produce? If so, should each representable value v
appear with probability proportional to (v.nextUp - v), which may be
different from (x.ulp)?
In other words, conceptually, should the API behave as if a real number
were chosen uniformly from the range, then rounded down to the closest
representable value that does not exceed it?
Or should some fixed number of equally-spaced values that span the range be
the only possible results?
Or something else?
Should subnormal values be producible?
There is no uniform distribution over an infinite-length continuum, so how
should infinite ranges be handled? In the range (0.0 ..< .infinity) should
we always return .greatestFiniteMagnitude? And in (-.infinity ..< 0.0)
should we always return (-.infinity)? What about (-.infinity ..<
.infinity)? Should there be preconditions that can fail at runtime, or
should we sometime return .nan, or what?
• • •
These are just a few of the questions that spring to mind, so I think it is
highly important that floating-point randomness gets sufficient attention
to ensure that we land on a well-considered design.
Nevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/ce7635da/attachment.html>
More information about the swift-evolution
mailing list