> On Apr 14, 2016, at 10:12 PM, Erica Sadun <[email protected]> wrote:
>
>
>> On Apr 14, 2016, at 10:36 PM, Stephen Canon <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Erica, thanks for the feedback.
>>
>>> On Apr 14, 2016, at 6:29 PM, Erica Sadun <[email protected]
>>> <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
