[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Sun, Apr 16, 2017 at 12:30 PM, David Sweeris via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Apr 16, 2017, at 09:56, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Another option is to make a new type, not sure what to call it but I’ll
> use “Num” for now, that is essentially the same as Double except it does
> not represent NaN. After all, why should a numeric type ever be “not a
> number”,
>
> Division by 0, incrementing past the largest representable value, probably
> a couple others that I'm not thinking of.
>

Those are reasons for integers to overflow.

Floating point values become NaN when you try to compute 0/0, when you try
to subtract infinity from itself, and when you try to multiply 0 and
infinity. There are also various trigonometric and hyperbolic functions
that are expected to emit NaN for various reasons, and for complex numbers
these reasons multiply (haha).

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.

> and what sort of name is “Double” anyway except as a hold-over from
> legacy standards?
>
> FWIW, I suggested something like that ("Float"->"Float32",
> "Double"->"Float64", and typealias the largest CPU-native type to just
> "Float") a while back and the consensus was that we wanted to preserve the
> current notation.
>
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170416/32e276ee/attachment.html>