On Wed, Jan 10, 2018 at 6:02 PM, Jens Persson via swift-evolution < swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution