[swift-evolution] [Proposal draft] Enhanced floating-point protocols
scanon at apple.com
Fri Apr 15 10:26:51 CDT 2016
> 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution