<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 10, 2018 at 6:02 PM, Jens Persson via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I agree.<div><br></div><div>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:</div><div><div>extension Double {</div><div>    init(unitRange v: UInt64) {</div><div>        self = Double(v &gt;&gt; Double.exponentBitCount) * (.ulpOfOne/2.0)</div><div>    }</div><div>}</div></div></div></blockquote><div><br></div><div>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…</div><div><br></div><div>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)?</div><div><br></div><div>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?</div><div><br></div><div>Or should some fixed number of equally-spaced values that span the range be the only possible results?</div><div><br></div><div>Or something else?</div><div><br></div><div>Should subnormal values be producible?</div><div><br></div><div>There is no uniform distribution over an infinite-length continuum, so how should infinite ranges be handled? In the range (0.0 ..&lt; .infinity) should we always return .greatestFiniteMagnitude? And in (-.infinity ..&lt; 0.0) should we always return (-.infinity)? What about (-.infinity ..&lt; .infinity)? Should there be preconditions that can fail at runtime, or should we sometime return .nan, or what?</div><div><br></div><div>• • •</div><div><br></div><div>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.</div><div><br></div><div>Nevin</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>