Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Sun Jul 24 2016, Brent Royal-Gordon wrote: >> On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution > wrote: >> >> Another possible choice would be to return .descending whenever >> either of the comparands were NaN, while also making <, >, <=, and >> >= return false in such cases.

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Mon, Jul 25, 2016 at 1:12 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Another possible choice would be to return .descending whenever either > of th

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution > wrote: > > Another possible choice would be to return .descending whenever either of the > comparands were NaN, while also making <, >, <=, and >= return false in such > cases. Then we wouldn't see preconditionFailures but inste

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> Dave Abrahams wrote: > > Asking whether zero appears in a sequence that happened to contain a NaN > would equally be a precondition violation. No, it wouldn't because Double would implement Equatable + Comparable by providing custom implementations of ==, <, >, <=, and >=, in addition to Do

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Asking whether zero appears in a sequence that happened to contain a NaN would equally be a precondition violation. I don't think that's an acceptable cliff. The point of NaNs and Infs is that they flow through a multidimensional calculation without disturbing the parts that are still valid, rat

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On 22 Jul 2016, at 18:43, Dave Abrahams wrote: > >> on Fri Jul 22 2016, Haravikk wrote: >> >> In my own hacked implementation I'm using Order.before, Order.same, >> and Order.after. It's not much of a change, but it seems to clarify >> what the enum is, at least in my opinion. > > I always t

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Pyry Jahkola wrote: >> or even to ask whether >> someSequence.contains(.nan). IMO that's not really acceptable. > > Not correct. Algorithms like contains(_:) or firstIndex(of:) would use the == > operator which is part of the protocol and thus wouldn't call <=> on > FloatingPoint types which o

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Dave Abrahams wrote: >> Given all this, I propose a simpler model that makes `a <=> b` follow >> the expected behaviour of < and ==, with the tradeoff that `a <=> >> .nan` and `.nan <=> b` will abort with a precondition failure: > > This effectively makes it a precondition violation to default-so

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Sat Jul 23 2016, Xiaodi Wu wrote: > IMO what's causing the headaches now isn't NaN; it's actually +0 and > -0. Yes, and specifically division by zero, which *seriously doesn't concern me*. I view the reason for floating point's (1/0 == Inf) to be very similar to its reason for having NaN, w

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Sat Jul 23 2016, Pyry Jahkola wrote: > Given all this, I propose a simpler model that makes `a <=> b` follow > the expected behaviour of < and ==, with the tradeoff that `a <=> > .nan` and `.nan <=> b` will abort with a precondition failure: This effectively makes it a precondition violation

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Daniel Duan Sent from my iPhone > On Jul 23, 2016, at 3:15 PM, Ross O'Brien via swift-evolution > wrote: > > This might be a radical suggestion ... or possibly a naive or unoriginal one, > I'll find out once I suggest it. > > Swift took the bold step of establishing optionals as a central t

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

This might be a radical suggestion ... or possibly a naive or unoriginal one, I'll find out once I suggest it. Swift took the bold step of establishing optionals as a central type, rather than assigning dual meanings to 'default' values such as zero or false. Recognising the concept of not having

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Sat, Jul 23, 2016 at 4:19 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > Another option would be to leave the IEEE 754 NaN hijinks in Float and > Double (as numerics people expect), and create a new type (with a nice > approachable name) that “acts like” Double but doe

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

IMO what's causing the headaches now isn't NaN; it's actually +0 and -0. On Sat, Jul 23, 2016 at 4:19 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > Another option would be to leave the IEEE 754 NaN hijinks in Float and > Double (as numerics people expect), and create a

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Another option would be to leave the IEEE 754 NaN hijinks in Float and Double (as numerics people expect), and create a new type (with a nice approachable name) that “acts like” Double but does not model NaN. Then any operation which would ordinarily produce a NaN, instead traps for the new type. T

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Sorry to overwhelm with more emails. I'd like to show some work and further analysis for your consideration that refines the sketch I just wrote: Two FP values a and b can be, with respect to each other: * ordered or unordered (per IEEE, NaN compares unordered to everything, including itself) * i

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Sat Jul 23 2016, Xiaodi Wu wrote: > That last sentence: division is defined in Arithmetic (IIUC--I'm not in > front of a traditional computer ATM). Yes. > I would expect, for any arithmetic type T, that the following would > return true: > > let a, b, c: T > if a == b { > return c/a == c/b

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Throwing out some more radical ideas here. Suppose we had instead (taking inspiration from IEEE notation): [Pardon any errors; I'm writing freehand in Gmail] infix operator ==? { /* figure out precedence later */ } protocol Equatable { static func ==? (lhs: Self, rhs: Self) -> Bool? /* seman

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Given all this, I propose a simpler model that makes `a <=> b` follow the expected behaviour of < and ==, with the tradeoff that `a <=> .nan` and `.nan <=> b` will abort with a precondition failure: 1) We keep the current Interface of Equatable unchanged, with != defined in terms of ==. 2) Co

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

That last sentence: division is defined in Arithmetic (IIUC--I'm not in front of a traditional computer ATM). I would expect, for any arithmetic type T, that the following would return true: let a, b, c: T if a == b { return c/a == c/b } This would not hold for all a and b if -0 === +0. On Sat,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, jaden.geller-AT-gmail.com wrote: > What if you wanted to filter such that you keep values less than some > element that happens to be positive zero; might that keep around any > negative zeros? Seems problematic. I agree. >> On Jul 22, 2016, at 7:53 PM, Dave Abrahams wrote:

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Sat Jul 23 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon wrote: > >> > The point of this design is that `===` means identity and that `.same ` >> > also means identity. >> > >> > Since this is new territory I suppose we get to decide what identity >> > means for fl

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon wrote: > > The point of this design is that `===` means identity and that `.same ` > > also means identity. > > > > Since this is new territory I suppose we get to decide what identity > > means for floating point. Should +0 and -0 have the same id

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> Am 23.07.2016 um 06:34 schrieb Stephen Canon via swift-evolution > : > >> The point of this design is that `===` means identity and that `.same ` >> also means identity. >> >> Since this is new territory I suppose we get to decide what identity >> means for floating point. Should +0 and -0 h

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

What if you wanted to filter such that you keep values less than some element that happens to be positive zero; might that keep around any negative zeros? Seems problematic. > On Jul 22, 2016, at 7:53 PM, Dave Abrahams wrote: > > >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >>> On Fri, Jul 22

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> The point of this design is that `===` means identity and that `.same ` > also means identity. > > Since this is new territory I suppose we get to decide what identity > means for floating point. Should +0 and -0 have the same identity or > not? I’ll leave the answer to folks more knowledgable

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 10:04 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 9:57 PM, Dave Abrahams wrote: >> >> >> on Fri Jul 22 2016, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 10:04 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:57 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Xiaodi Wu > wrote: > > On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams > wrote: > > > on Fri Jul 22 2016, Xiaodi Wu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:57 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams > wrote: > > > >> > >> on Fri Jul 22 2016, Xiaodi Wu wrote: > >> > >> > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson < > matt...@anandabits.co

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:57 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Xiaodi Wu > wrote: > >> On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams wrote: >> >>> >>> on Fri Jul 22 2016, Xiaodi Wu wrote: >>> On Fri, Jul 22, 2016 at 9:23 PM, Matthew Jo

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson > > >> > wrote: >> > >> >> >> >> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: >> >> >> >> On Fri,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:53 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 9:38 PM, wrote: > > > >> This seems reasonable to me. I don't see why `===` has to do a total > order > >> comparison when we already have another operator, `<=>`, that d

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Brent Royal-Gordon wrote: >> On Jul 22, 2016, at 7:23 PM, Dave Abrahams wrote: >> >> No, NSString's conformance to Identifiable (probably NSObject's, >> actually) would define `===` in terms of `isEqual()`. That's saying >> identity for these types is determined by `isEqua

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:38 PM, wrote: > >> This seems reasonable to me. I don't see why `===` has to do a total order >> comparison when we already have another operator, `<=>`, that does that. >> > > I take it back. It wouldn't solve the issue that gene

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson > > > wrote: > > > >> > >> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: > >> > >> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-ev

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:46 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Xiaodi Wu wrote: > >> On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson >> wrote: >> >>> >>> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: >>> >>> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 7:23 PM, Dave Abrahams wrote: > > No, NSString's conformance to Identifiable (probably NSObject's, > actually) would define `===` in terms of `isEqual()`. That's saying > identity for these types is determined by `isEqual()`. So `===` no longer tests if both instances are

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: >> >> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> On Jul 22, 2016, a

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:38 PM, wrote: > This seems reasonable to me. I don't see why `===` has to do a total order > comparison when we already have another operator, `<=>`, that does that. > I take it back. It wouldn't solve the issue that generic `<` would still behave in surprising ways, wh

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:28 PM, Dave Abrahams wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > > >> > wrote: >> > >> >> >> >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: >> >> >> >> On Fri,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

This seems reasonable to me. I don't see why `===` has to do a total order comparison when we already have another operator, `<=>`, that does that. > On Jul 22, 2016, at 7:35 PM, Xiaodi Wu wrote: > >> On Fri, Jul 22, 2016 at 9:28 PM, Dave Abrahams wrote: >> >> on Fri Jul 22 2016, Xiaodi Wu w

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:28 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > > > wrote: > > > >> > >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: > >> > >> On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson < > matt...@

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:26 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evol

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: >> >> On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson >> wrote: >> >>> >>> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: >>> >>> On Fri, Jul

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:15 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution < >> swi

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:24 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Matthew Johnson wrote: > >>> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Fri Jul 22 2016, Matthew Johnson >> > wrote: >>> >> >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on F

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:20 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:19 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:12 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 9:09 PM, Jaden Geller >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Matthew Johnson wrote: >> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Jul 22 2016, Matthew Johnson > > wrote: >> > On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution mailto:s

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Brent Royal-Gordon wrote: >> On Jul 22, 2016, at 4:55 PM, Daniel Duan via swift-evolution >> wrote: >> >>> Well, it's still a very real question whether we ought to have the >>> additional API surface implied by areSame, or wether we should collapse >>> it with ===. >>> >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:09 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 8:45 PM, Dave Abrahams > wrote: > > > >> > >> on Fri Jul 22 2016, Xiaodi Wu wrote: > >> > >> > On Fri, Jul 22, 2016 at 8:

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:19 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:12 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:09 PM, Jaden Geller > wrote: > >> 1. NaN != NaN and +0 == -0 [what the traditional comparison operators are >> constrained to do] >> 2. NaN == NaN, +0 == -0, a

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 8:45 PM, Dave Abrahams wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> on Fri Jul 22 2016, Dan

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:12 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:09 PM, Jaden Geller > wrote: >> 1. NaN != NaN and +0 == -0 [what the traditional comparison operators are >> constrained to do] >> 2. NaN == NaN, +0 == -0, and the same number encoded d

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > on Fri Jul 22 2016, Matthew Johnson wrote: > > On Jul 22, 2016, at 8:37 PM, Xiaod

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Jaden Geller wrote: > "The totalOrder predicate will order these cases, and it also > distinguishes between different representations of NaNs and between > the same decimal floating point number encoded in different ways." > - > [Wikipedia](https://en.wikipedia.org/wiki/IEEE

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Jul 22 2016, Matthew Johnson > wrote: > >>> On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Fri, Jul 2

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: >> >> On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson >> wrote: >> >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Matthew Johnson wrote: >> On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution >> >> > >> wrote: >> >> on Fri Jul 22 2016, Daniel Duan wrote: >> >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:09 PM, Jaden Geller wrote: > 1. NaN != NaN and +0 == -0 [what the traditional comparison operators are > constrained to do] > 2. NaN == NaN, +0 == -0, and the same number encoded different ways > compare equal > 3. NaN == NaN, +0 != -0, and the same number encoded differ

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Fri, Jul 22,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> 1. NaN != NaN and +0 == -0 [what the traditional comparison operators are > constrained to do] > 2. NaN == NaN, +0 == -0, and the same number encoded different ways compare > equal > 3. NaN == NaN, +0 != -0, and the same number encoded different ways compare > not equal Though it seems super

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Fri, Jul 22, 2016 at 8:52 PM, Jad

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:02 PM, Jaden Geller wrote: > >> Fair enough; the result of that will be, as Pyry noted above, that: >> >> ``` >> [-0.0, 1.0, .nan, 0.0].firstIndex(of: 0.0) //=> 3, not 0 >> ``` > > Well, ummm, that's unfortunate. This would be extremely surprising behavior, > and I cou

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:00 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 22, 2016, at 4:55 PM, Daniel Duan via swift-evolution >> wrote: >> >>> Well, it's still a very real question whether we ought to have the >>> additional API surface implied by areSame, or wether we sho

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution < > swift-evolution@swift.org> wrote: > >> "The totalOrder predicate w

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> If `===` is the new `areSame`, and `Hashable` is based on `===`, wouldn't > that mean that objects could only be hashed (and thus, be looked up in > Dictionary and Set) by identity? So, for instance, code like this: > > var set = Set() > > set.insert("test") > set.inse

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> Fair enough; the result of that will be, as Pyry noted above, that: > > ``` > [-0.0, 1.0, .nan, 0.0].firstIndex(of: 0.0) //=> 3, not 0 > ``` Well, ummm, that's unfortunate. This would be extremely surprising behavior, and I could easily see this causing bugs. Users would have to be very carefu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 4:55 PM, Daniel Duan via swift-evolution > wrote: > >> Well, it's still a very real question whether we ought to have the >> additional API surface implied by areSame, or wether we should collapse >> it with ===. >> > > To spell this out (because I had to think about it f

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > "The totalOrder predicate will order these cases, and it also distinguishes > between different representat

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution < swift-evolution@swift.org> wrote: > "The totalOrder predicate will order these cases, and it also > distinguishes between different representations of NaNs and between the > same decimal floating point number encoded in different

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

"The totalOrder predicate will order these cases, and it also distinguishes between different representations of NaNs and between the same decimal floating point number encoded in different ways." - [Wikipedia](https://en.wikipedia.org/wiki/IEEE_floating_point#Total-ordering_predicate) Sounds l

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:46 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 8:43 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jul 22, 2016 at 8:42 PM, Jaden Geller > wrote: > >> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Jaden Geller wrote: >> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` >> *but not iff*. This is to satisfy IEEE 754: "Comparisons shall >> ignore the sign of zero (so +0 = −0)". > > I don't see why both `(+0) === (-0)` and `(+0) <=> (-0)` can't return > `

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:45 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> on Fri Jul 22 2016, Daniel Duan wrote: > >> > >> >> On Jul 22, 2016, at 3

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Daniel Duan wrote: >> >> >> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:43 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 8:42 PM, Jaden Geller > wrote: >> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but not >> iff*. This is to satisfy IEEE 754: "Comparisons sh

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:44 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Dan

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > on Fri Jul 22 2016, Daniel Duan wrote: > > >> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evo

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:42 PM, Jaden Geller wrote: > For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but > not iff*. This is to satisfy IEEE 754: "Comparisons shall ignore the sign > of zero (so +0 = −0)". > > > I don't see why both `(+0) === (-0)` and `(+0) <=> (-0)` can't

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Jaden Geller wrote: > I really like this idea. I was initially opposed to changing the > behavior of `===`, but I think I'm for it now. Though there have been > quite a few situations where I specifically want reference identity, > in these situations I would not override the

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but not > iff*. This is to satisfy IEEE 754: "Comparisons shall ignore the sign of zero > (so +0 = −0)". I don't see why both `(+0) === (-0)` and `(+0) <=> (-0)` can't return `true` and `.same`, respectively. This doesn't br

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:34 PM, Jaden Geller via swift-evolution > wrote: > > I really like this idea. I was initially opposed to changing the behavior of > `===`, but I think I'm for it now. Though there have been quite a few > situations where I specifically want reference identity, in these

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Daniel Duan wrote: > > >> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> > >> on Fri Jul 22 2016, Daniel D

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

I really like this idea. I was initially opposed to changing the behavior of `===`, but I think I'm for it now. Though there have been quite a few situations where I specifically want reference identity, in these situations I would not override the `===` operator anyway; these objects were ident

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Daniel Duan wrote: >> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Jul 22 2016, Daniel Duan > > wrote: >> > On Jul 22, 2016, at 11:05 AM, Dave Abrahams via swift-evolution mailto:swif

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

I'm convinced. Let's make areSame === again! On Fri, Jul 22, 2016 at 18:55 Daniel Duan via swift-evolution < swift-evolution@swift.org> wrote: > On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > on Fri Jul 22 2016, Daniel Duan wrote: > > O

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Sorry, yeah, that's what I meant to ask. I can't see how it would make anything unworkable, but I agree that it might not be very useful. On Fri, Jul 22, 2016 at 18:50 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Jul 22 2016, Daniel Duan > wrote: > >>> On Jul 22, 2016, at 11:05 AM, Dave Abrahams via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> on Thu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 5:48 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 3:54 PM, Dave Abrahams >> wrote: >> > >> >> >> >> on Fri Jul 22 2016, Xia

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Matthew Johnson wrote: >> On Jul 22, 2016, at 4:47 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Jul 22 2016, Tony Allevato > >> > > >> wrote: >> >>> I like a lot of this, but the changes to Equatable are where I get stu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Tony Allevato wrote: > On Fri, Jul 22, 2016 at 2:52 PM Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Tony Allevato wrote: >> >> > I like a lot of this, but the changes to Equatable are where I get stuck. >> > What are the

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 6:13 PM, Stephen Canon wrote: > On Jul 22, 2016, at 6:55 PM, Matthew Johnson > wrote: > > > On Jul 22, 2016, at 5:50 PM, Stephen Canon wrote: > > On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > > Sorry if it wasn

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 6:55 PM, Matthew Johnson wrote: > >> On Jul 22, 2016, at 5:50 PM, Stephen Canon > > wrote: >> >>> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Sorry if it wasn’t clear. I’m

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 5:48 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 3:54 PM, Dave Abrahams > wrote: > > > >> > >> on Fri Jul 22 2016, Xiaodi Wu wrote: > >> > >> > On Fri, Jul 22, 2016 at 1:

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 5:50 PM, Stephen Canon wrote: > >> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Sorry if it wasn’t clear. I’m not suggesting taking that away. I’m asking >> whether we have considered defining `==`

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 3:54 PM, Dave Abrahams wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 1:05 PM, Dave Abrahams via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> on Thu Jul 21 2016, Dua

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 5:41 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 5:34 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 5:29 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 5:17 PM, Matthew Johnson via swift-evol

  1   2   >