+1
What I am arguing for is #2. We have two different expectations and we
need to be explicit about which is being used. Furthermore, I am arguing
that if one of them is going to be the default (and use the ‘==‘ and ‘<‘
symbols), it needs to be the strict equality/total ordering version, since
that is what every other Swift type is modeling, and IEEE is only
applicable to floating point.
Then it's an insoluble problem, because (and for good reasons) there are
those who consider anything other than `.nan != .nan` to be a non-starter.
My attempt to convince people that maybe we could just make that expression
trap instead of giving an answer did not, evidently, win over too many
fans. But I tend to sympathize with the numerics crowd that `.nan == .nan`
would be disastrous for Swift when it comes to numerics. No other (common)
language behaves that way.
···
On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote:
On Apr 24, 2017, at 9:44 PM, David Waite via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I still think this is a naming conflict more than anything else.
>
> The first expectation is that equatable and comparable provides strict
equality and strict total ordering, and that those are exposed via
operators. The other expectation is that floating point abides by the IEEE
rules which have neither of these, and are exposed via operators.
>
> Either:
> 1. the operators need to do different things in different contexts
> 2. we need different methods/operators to indicate these different
concepts
> 3. Equatable and comparable need to be altered to no longer require
strict equality and strict total ordering (and all generic algorithms based
on equatable/comparable need to be checked that they still work)
> 4. floating point numbers need to explicitly not be equatable/comparable
to prevent their usage in generic algorithms requiring strict behavior.
> 5. We break away from IEEE behavior and provide only strict equality and
strict total ordering
>
> (I tried to sort these roughly in order of feasibility)
>
> Are there any other options?
>
> -DW
>
>> On Apr 24, 2017, at 9:50 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>>
>> on Mon Apr 24 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>>
>>> On Mon, Apr 24, 2017 at 9:06 PM, Jonathan Hull via swift-evolution < > >>> swift-evolution@swift.org> wrote:
>>>
>>>> As I am thinking about it more, this means that for == and <
>>>>
>>>> NaN == NaN
>>>> -0 == +0
>>>> +Inf < NaN
>>>>
>>>> Since this would break from IEEE,
>>>
>>> Yeah, as Steve mentioned, it's a huge deal to break from IEEE rules.
>>
>> Allow me to put it even more strongly: I consider reinventing how
>> floating point works to be a massive undertaking comparable to
>> supplanting the Unicode standard with something better. I have no doubt
>> that it could be done by somebody, somewhere, someday, but it would be
>> easy to do something much worse than what IEEE has done, and getting it
>> right would occupy so much of this group's time that we couldn't hope to
>> accomplish anything else, if we even had the expertise—I know I don't!
>> Doing anything in this area that is not firmly rooted in existing
>> standards and practices is not an option I'm willing to pursue.
>>
>> --
>> -Dave
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution