> 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

Reply via email to