[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull <jhull at gbis.com> wrote:

>
> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> The point is that, when you manipulate two real numbers, sometimes there
> is no numeric result. You cannot simply wish this away with a new numeric
> type because it is not an artifact of _modeling_ real numbers but rather
> intrinsic to mathematics itself.
>
>
> I agree with the rest of what you said, but I have to disagree on this
> point.  What I think he is saying is that, in Swift, we really should be
> representing the NaN case as an optional instead of a magic value on the
> type itself (similar to how swift uses an optional instead of NSNotFound).
>
> In fact, that might be an actual option here.  For ‘Double?’ the compiler
> could use the bit pattern for NaN internally to represent .none (I believe
> it does similar tricks to save space with other optional types).  Then
> disallow reference to NaN within swift code.  Functions or operations which
> could produce NaN would either have to produce an optional or trap in case
> of NaN. (e.g. the trig functions would likely return an optional, and 0/0
> would trap).
>
> I think it would actually lead to much better code because the compiler
> would force you to have to explicitly deal with the case of optional/NaN
> when it is possible.  Migration would be tricky though...
>

This is essentially a cosmetic renaming from `Double` to `Double?`. There
are rules for propagating NaN which numeric algorithms expect. For example,
`cos(.nan)` returns a value. If your design is to work, every function that
takes a `Double` will need to take a `Double?`.

Just as Swift String conforms to Unicode standards, FloatingPoint conforms
to IEEE standards. You'd have to come up with enormous benefits to justify
breaking that. Doing so for Swift 4 is plainly a non-starter.

Thanks,
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170416/e536bf18/attachment.html>