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

Stephen Canon scanon at apple.com
Mon Apr 25 13:22:17 CDT 2016


> On Apr 25, 2016, at 2:12 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> On Apr 22, 2016, at 7:13, Stephen Canon <scanon at apple.com <mailto:scanon at apple.com>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160425/4f9e3f2b/attachment.html>


More information about the swift-evolution mailing list