> On Apr 25, 2016, at 2:12 PM, Jordan Rose <[email protected]> wrote:
>
>> On Apr 22, 2016, at 7:13, Stephen Canon <[email protected]
>> <mailto:[email protected]>> 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?
>>
>> There are a variety of means that a softfloat type could use to implement
>> signaling NaNs. Here are two of the simpler ones:
>>
>> (a) if running on HW with hard-float support, use native-precision
>> hard-float instructions to set flags as needed.
>> (b) provide operation variants that take an inout flags / parameter:
>>
>> mutating func add(rhs: Self, inout flags: Flags)
>>
>
> Sorry, I think my question is more general than this. "Signaling" is a term
> of art in IEEE 754, but it doesn't actually mean anything in Swift, and none
> of the operations in the protocol have defined semantics for "signaling".
> Maybe that's the real question: what must each of the operations of
> FloatingPoint and BinaryFloatingPoint do when operating on an SNaN? a QNaN?
>
> (I know what IEEE 754 says. We need the same rules in Swift semantics:
> "throws", "traps", "returns an unspecified result”.)
At present, I would say that by default they should raise the invalid
floating-point flag, which is impossible to observe from raw Swift, but is
observable via the C stdlib <fenv.h> functions; they might optionally set a
flag in an explicit inout parameter or trap. We should eventually have a
specified floating-point environment model, but that’s (mostly) orthogonal to
this API proposal.
– Steve
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution