[swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Stephen Canon]

> On Apr 14, 2016, at 10:12 PM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> 
>> On Apr 14, 2016, at 10:36 PM, Stephen Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote:
>> 
>> Hi Erica, thanks for the feedback.
>> 
>>> On Apr 14, 2016, at 6:29 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>> 
>>> * I do use % for floating point but not as much as I first thought before I started searching through my code after reading your e-mail. But when I do use it, it's nice to have a really familiar symbol rather than a big word. What were the ways that it was used incorrectly? Do you have some examples?
>> 
>> As it happens, I have a rationale sitting around from an earlier (internal) discussion:
>> 
> 
> Thanks. That makes plenty of sense although I do still think the name is long and hard to discover compared to fmod[1] and %.

I completely agree.  I don’t expect the fmod free function to go away anytime soon, FWIW (and I would oppose removing it unless we had a more discoverable name for this method).

>>> * I don't quite get how equatable is going to work. Do you mind explaining that in more detail?
>> 
>> I’m not totally sure what your question is.  Are you asking how FloatingPoint will conform to Equatable, or how the Equatable protocol will work?
> 
> Given the many words and passionate articles about how difficult it is to perform floating point comparisons, 
> for example, https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ <https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/>, 
> I'm just curious as to what approach you've settled on. The topic has come up on-list quite a few times.

The actual == and != operators should continue to default to exact (IEEE 754) equality.  Doing anything else is asking for a lot of trouble when people try to convert algorithms from other languages.

Support for equality and comparison with a tolerance would be a great library feature, but the difficulty is that it’s impossible to provide a solution that’s appropriate for all (or even most) cases.  I have a few sketches of things I’d like to do in that direction, but it’s out of scope for Swift 3, considering the subtle numerics *and* library/language design issues involved.

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160415/2bd843d2/attachment.html>