[swift-evolution] [Proposal] Random Unification

[Nevin Brackett-Rozinsky]

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>