[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

[Xiaodi Wu]

Neither, actually. NaN is a valid value and even its use does not always
lead to exceptions. For example, it's possible (and a deliberate use case)
to assign NaN (even signaling NaN), and the IEEE 754 function maxNum(x, y)
(here proposed as `maximum`) will return x if x is not NaN and y is NaN.
On Fri, Apr 22, 2016 at 12:19 David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> On Apr 22, 2016, at 8:13 AM, Stephen Canon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>   /// A signaling NaN (not-a-number).
>   @warn_unused_result
>   static func signalingNaN: Self { get }
>
>
> I’m not sure it really makes sense for a Bignum / APFloat type to support
> such a value. But really I think this is just underspecified. What does it
> mean, in terms of this protocol and its uses, for a NaN to be signaling? Is
> it just a specific “color" of NaN, with no semantic requirements other than
> being distinguishable?
>
>
> I’m confused in that I haven’t really had exposure to signaling NaNs
> before, and wasn’t really able to find hints on how they are used. Do math
> operations create signaling NaNs, or is it an explicitly set value?
>
> My first expectation was that you would either have overflow operators
> where a NaN result would immediately raise an exception.
>
> My second expectation if NaN was a valid value but use created exceptions
> is that floating point numbers are monadic. Specifically, floating point
> operations with soft NaN seem similar to optional, while Floats with
> signaling NaN seem similar to implicitly unwrapped optionals - but without
> the use of separate types to represent numbers and possibly-not-numbers.
>
> That said, would use of an attribute on a floating point type, similar to
> what is planned for IUOs, be appropriate to indicate that the type should
> be treated as signaling?
>
> -DW
>
> _______________________________________________
> 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/20160422/ba368f9f/attachment.html>