Re: [swift-evolution] [pitch] Comparison Reform

Sent from my iPhone > On 28 Apr 2017, at 01:51, Jonathan Hull via swift-evolution > wrote: > > To be clear, the big downside is the current lack of hardware support. There > are apparently some chips in the pipeline, but nothing for Apple platforms > that I know

Re: [swift-evolution] [pitch] Comparison Reform

Agreed. I think the first step if we are interested in unums is to make a 3rd party library. (There are apparently chips already in the pipeline, but it won’t affect iOS or Macs, which are the main targets for Swift.) That said, whether the implementation is based on unums or not, I would

Re: [swift-evolution] [pitch] Comparison Reform

To be clear, the big downside is the current lack of hardware support. There are apparently some chips in the pipeline, but nothing for Apple platforms that I know of. We are likely to see them first in GPUs and neural network processors (since they allow effective neural networks using only

Re: [swift-evolution] [pitch] Comparison Reform

On Apr 27, 2017, at 7:35 PM, Jonathan Hull via swift-evolution wrote: > I doubt we would get rid of Double/Float, but I would love to see it used as > a core type in Swift 5. Not to be discouraging, but Swift 5 is wildly ambitious for the inclusion of unum in the

Re: [swift-evolution] [pitch] Comparison Reform

There have been a bunch of updates since then (currently under peer review), which deal with implementation on current systems. Reading the new/updated paper now… Here is a video of the author speaking about some of the general ideas: https://www.youtube.com/watch?v=aP0Y1uAA-2Y I doubt we

Re: [swift-evolution] [pitch] Comparison Reform

I mentioned unums on the list about a year ago. Steve Canon replied with some thoughts: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016889.html . > On Apr 27, 2017, at 4:26 PM,

Re: [swift-evolution] [pitch] Comparison Reform

I have read it, and it is a truly brilliant work. I would love to see some (or all) of it make it into Swift (most likely Swift 5 or 6). The author is related to a friend of mine, so I can see if he is available to answer questions if there is interest... > On Apr 27, 2017, at 5:14 AM,

Re: [swift-evolution] [pitch] Comparison Reform

Hi all together, I was just looking quickly over an article from Wolfram which covers new books covering Mathematica and tripped over this book: https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/p/book/9781482239867 From the reviews: "This book is an extraordinary reinvention

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 26, 2017, at 4:23 PM, Michel Fortin via swift-evolution > wrote: > >> Le 26 avr. 2017 à 18:33, Xiaodi Wu > > a écrit : >> >> On Wed, Apr 26, 2017 at 2:14 PM, Michel Fortin via swift-evolution >>

Re: [swift-evolution] [pitch] Comparison Reform

On Wed, Apr 26, 2017 at 6:23 PM, Michel Fortin wrote: > Le 26 avr. 2017 à 18:33, Xiaodi Wu a écrit : > > On Wed, Apr 26, 2017 at 2:14 PM, Michel Fortin via swift-evolution < > swift-evolution@swift.org> wrote: > >> Just throwing a idea that came to

Re: [swift-evolution] [pitch] Comparison Reform

> Le 26 avr. 2017 à 18:33, Xiaodi Wu a écrit : > > On Wed, Apr 26, 2017 at 2:14 PM, Michel Fortin via swift-evolution > > wrote: > Just throwing a idea that came to me while reading this discussion (hopefully >

Re: [swift-evolution] [pitch] Comparison Reform

On Wed, Apr 26, 2017 at 2:14 PM, Michel Fortin via swift-evolution < swift-evolution@swift.org> wrote: > Just throwing a idea that came to me while reading this discussion > (hopefully not duplicating something that was already suggested)... > > We could introduce `FiniteFloat` and `FiniteDouble`

Re: [swift-evolution] [pitch] Comparison Reform

Just throwing a idea that came to me while reading this discussion (hopefully not duplicating something that was already suggested)... We could introduce `FiniteFloat` and `FiniteDouble` types that would disallow NaN and infinity. Computations creating NaN or infinity would trap with these

Re: [swift-evolution] [pitch] Comparison Reform

As discussed a long time ago, and as I raised here in an earlier reply in this thread, a total order over floating point values is almost never what you want. It distinguishes between +0.0 and -0.0, between +NaN and -NaN, between signaling NaN and quiet NaN, between different NaN payloads, and for

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 11:50 PM, Jonathan Hull wrote: > > >> On Apr 25, 2017, at 9:34 PM, Jaden Geller > > wrote: >> >>> >>> On Apr 25, 2017, at 8:28 PM, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 9:34 PM, Jaden Geller wrote: > >> >> On Apr 25, 2017, at 8:28 PM, Jonathan Hull via swift-evolution >> > wrote: >> >> >>> On Apr 25, 2017, at 7:17 PM, Xiaodi Wu

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 8:28 PM, Jonathan Hull via swift-evolution > wrote: > > >> On Apr 25, 2017, at 7:17 PM, Xiaodi Wu > > wrote: >> >> On Tue, Apr 25, 2017 at 8:38 PM, Jonathan Hull >

Re: [swift-evolution] [pitch] Comparison Reform

Alternatively, we could introduce a new type `PotentiallyUnknown` that’s kind of like `Optional` but has different equality semantics. We’d probably also need to introduce a `PartiallyEquatable` (probably the wrong word) protocol too though. I don’t think this is really that feasible. protocol

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 7:17 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 8:38 PM, Jonathan Hull > wrote: > >> On Apr 25, 2017, at 5:25 PM, Xiaodi Wu > > wrote: >> >> On Tue,

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 8:38 PM, Jonathan Hull wrote: > > On Apr 25, 2017, at 5:25 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 6:53 PM, Jonathan Hull wrote: > >> I just wanted to ask for more detail on why this is a non-starter (it >>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 5:25 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 6:53 PM, Jonathan Hull > wrote: > I just wanted to ask for more detail on why this is a non-starter (it seems > like most of my ideas are dismissed as

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 6:53 PM, Jonathan Hull wrote: > I just wanted to ask for more detail on why this is a non-starter (it > seems like most of my ideas are dismissed as “non-starters”, but I am > rarely given a detailed reason why). > > Migration would be a renaming from

Re: [swift-evolution] [pitch] Comparison Reform

I just wanted to ask for more detail on why this is a non-starter (it seems like most of my ideas are dismissed as “non-starters”, but I am rarely given a detailed reason why). Migration would be a renaming from ‘Double' to ‘Double?’, but it wouldn’t be cosmetic. It would free us to use a

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 7:34 AM, Stephen Canon wrote: > > >> On Apr 24, 2017, at 10:06 PM, Jonathan Hull via swift-evolution >> wrote: >> >> As I am thinking about it more, this means that for == and < >> >> NaN == NaN >> -0 == +0 >> +Inf < NaN >>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 10:06 PM, Jonathan Hull via swift-evolution > 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, I think we should also consider taking the >

Re: [swift-evolution] [pitch] Comparison Reform

On Mon, Apr 24, 2017 at 11: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

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 3:12 AM, David Waite wrote: > > On Apr 24, 2017, at 11:52 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> +1 >> >> What I am arguing

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 2:41 AM, David Waite wrote: > > On Apr 24, 2017, at 11:52 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > The only other alternative I can think of is to include a notion of > unordered to our comparisons… > >

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 11:52 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution > > wrote: > +1 > > What I am arguing for is #2. We have two different expectations and

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 11:52 PM, Jonathan Hull via swift-evolution > wrote: > > The only other alternative I can think of is to include a notion of unordered > to our comparisons… > > What if we made <=> return an optional comparison result, with nil meaning >

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 10:54 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 12:52 AM, Jonathan Hull > wrote: > The only other alternative I can think of is to include a notion of unordered > to our comparisons… > > What if we

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 12:52 AM, Jonathan Hull wrote: > The only other alternative I can think of is to include a notion of > unordered to our comparisons… > > What if we made <=> return an optional comparison result, with nil meaning > unordered (which is how Ruby does it)? >

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > +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

Re: [swift-evolution] [pitch] Comparison Reform

The only other alternative I can think of is to include a notion of unordered to our comparisons… What if we made <=> return an optional comparison result, with nil meaning unordered (which is how Ruby does it)? For == and <, we still require a strict total ordering (i.e. they would not be

Re: [swift-evolution] [pitch] Comparison Reform

On Mon, Apr 24, 2017 at 11:44 PM, David Waite 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 >

Re: [swift-evolution] [pitch] Comparison Reform

+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,

Re: [swift-evolution] [pitch] Comparison Reform

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

Re: [swift-evolution] [pitch] Comparison Reform

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

Re: [swift-evolution] [pitch] Comparison Reform

As I am thinking about it more, this means that for == and < NaN == NaN -0 == +0 +Inf < NaN Since this would break from IEEE, I think we should also consider taking the opportunity to make == and < work with a default tolerance. That is, 'a == b' would check that (a - b) < epsilon for some

Re: [swift-evolution] [pitch] Comparison Reform

On Mon, Apr 24, 2017 at 7:16 PM, Dave Abrahams wrote: > > on Sun Apr 23 2017, Xiaodi Wu wrote: > > > On Sun, Apr 23, 2017 at 4:32 PM, Dave Abrahams > wrote: > > > >> > >> on Sun Apr 23 2017, Xiaodi Wu wrote: > >> > >> > On Sun, Apr 23, 2017 at 7:54

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 23 2017, Xiaodi Wu wrote: > On Sun, Apr 23, 2017 at 4:32 PM, Dave Abrahams wrote: > >> >> on Sun Apr 23 2017, Xiaodi Wu wrote: >> >> > On Sun, Apr 23, 2017 at 7:54 AM, Dave Abrahams >> wrote: >> > >> >> >> >> on Sun Apr 23 2017, Xiaodi Wu

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 23, 2017 at 4:32 PM, Dave Abrahams wrote: > > on Sun Apr 23 2017, Xiaodi Wu wrote: > > > On Sun, Apr 23, 2017 at 7:54 AM, Dave Abrahams > wrote: > > > >> > >> on Sun Apr 23 2017, Xiaodi Wu wrote: > >> > >> > On Sat, Apr 22, 2017 at 11:00

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 4:14 PM, Dave Abrahams wrote: > > > on Sat Apr 22 2017, David Sweeris wrote: > >> Maybe we should make Float/Double conform to >> "IEEE754Comparable"/"IEEE754Equatable" instead of >> "Comparable"/"Equatable". Then it's all a moot point since

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 23 2017, Xiaodi Wu wrote: > On Sun, Apr 23, 2017 at 7:54 AM, Dave Abrahams wrote: > >> >> on Sun Apr 23 2017, Xiaodi Wu wrote: >> >> > On Sat, Apr 22, 2017 at 11:00 PM, Dave Abrahams >> wrote: >> > >> >> >> >> >> > That is to say, I would

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 23, 2017 at 7:54 AM, Dave Abrahams wrote: > > on Sun Apr 23 2017, Xiaodi Wu wrote: > > > On Sat, Apr 22, 2017 at 11:00 PM, Dave Abrahams > wrote: > > > >> > >> >> > That is to say, I would expect the standard library to supply an > >> >> >

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 11:46 PM, David Waite > wrote: > >> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution >> wrote: >> >> I don’t think that this proposal is acceptable as written. I think it is >> really bad that

Re: [swift-evolution] [pitch] Comparison Reform

There is one more option which hasn’t really been considered: • == and != are tied to the Equatable protocol, which is essentially the == operation. • <, <=, >, >= are tied to the Comparable protocol (which is kept the same except for minor changes/additions listed below) • Hashable still

Re: [swift-evolution] [pitch] Comparison Reform

> (Sometimes I think there should be a separate Real type that ordinary > users work with, leaving all the fun of FP to hard-core numericists). Might be a good idea not only because of NaN: One of the first lessons in numerical analysis is that equality is brittle for floats, thus you check the

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 23 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 11:00 PM, Dave Abrahams wrote: > >> >> >> > That is to say, I would expect the standard library to supply an >> >> > alternative implementation of equality for Array> >> > FloatingPoint>. >> >> >> >> And also

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, David Waite wrote: >> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution >> wrote: >> >> I don’t think that this proposal is acceptable as written. I think >> it is really bad that abstracting a concrete algorithm would change >>

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Chris Lattner wrote: > On Apr 22, 2017, at 6:06 PM, Xiaodi Wu wrote: >> but my quick reaction to `&==` is that it would make me quite >> nervous to have `==` not bound to 754-equals as it is in essentially >> every other language. In particular, I worry

Re: [swift-evolution] [pitch] Comparison Reform

Sent from my iPhone > On 23 Apr 2017, at 05:58, Chris Lattner via swift-evolution > wrote: > >> On Apr 22, 2017, at 6:06 PM, Xiaodi Wu wrote: >> but my quick reaction to `&==` is that it would make me quite nervous to >> have `==` not bound

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 23, 2017 at 1:46 AM, David Waite wrote: > > > On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I don’t think that this proposal is acceptable as written. I think it > is really bad that

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 11:00 PM, Dave Abrahams wrote: > > >> > That is to say, I would expect the standard library to supply an > >> > alternative implementation of equality for Array >> > FloatingPoint>. > >> > >> And also for Dictionary? What do you expect to happen when

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution > wrote: > > I don’t think that this proposal is acceptable as written. I think it is > really bad that abstracting a concrete algorithm would change its behavior so > substantially. I don’t care

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 9:58 PM, Chris Lattner wrote: > > I don’t think that this proposal is acceptable as written. I think it is > really bad that abstracting a concrete algorithm would change its behavior so > substantially. I don’t care about SNaNs, but I do care

Re: [swift-evolution] [pitch] Comparison Reform

On Apr 22, 2017, at 6:06 PM, Xiaodi Wu wrote: > but my quick reaction to `&==` is that it would make me quite nervous to have > `==` not bound to 754-equals as it is in essentially every other language. In > particular, I worry about the risk of people porting numerical

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 6:37 PM, Dave Abrahams wrote: > > >> >> >> > To be clear, this proposal promises that `[0 / 0 as Double]` will be >> made >> >> > to compare unequal with itself, yes? >> >> >> >> Nope. >> >> >> >> As you know,

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 7:37 PM, Stephen Canon wrote: > > On Apr 22, 2017, at 6:55 PM, Xiaodi Wu wrote: > > Yes. Specifically, in floating point code. I guess that's the part about > shaping the rug not to cover the bump. IEEE does not require `==` to be

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 6:37 PM, Dave Abrahams wrote: > > >> > To be clear, this proposal promises that `[0 / 0 as Double]` will be > made > >> > to compare unequal with itself, yes? > >> > >> Nope. > >> > >> As you know, equality of arrays is implemented generically and

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 7:02 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Apr 22, 2017, at 4:53 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams > wrote: > >> >>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 6:55 PM, Xiaodi Wu wrote: > > Yes. Specifically, in floating point code. I guess that's the part about > shaping the rug not to cover the bump. IEEE does not require `==` to be the > spelling of the quiet equality comparison operator, and it does

Re: [swift-evolution] [pitch] Comparison Reform

Sent from my iPad > On Apr 22, 2017, at 4:53 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> On

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, David Sweeris wrote: > Maybe we should make Float/Double conform to > "IEEE754Comparable"/"IEEE754Equatable" instead of > "Comparable"/"Equatable". Then it's all a moot point since floating > point types wouldn't end up in the same generic functions as other > comparable

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 5:51 PM, Dave Abrahams wrote: > > on Sat Apr 22 2017, Xiaodi Wu wrote: > > > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams > wrote: > > > >> > >> on Tue Apr 18 2017, Xiaodi Wu wrote: > >> > >> > On Tue, Apr 18, 2017 at 10:40

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 5:51 PM, Dave Abrahams wrote: > > on Sat Apr 22 2017, Xiaodi Wu wrote: > > > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams > wrote: > > > >> > >> on Tue Apr 18 2017, Xiaodi Wu wrote: > >> > >> > On Tue, Apr 18, 2017 at 10:40

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> On

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 5:39 PM, David Sweeris wrote: > Maybe we should make Float/Double conform to "IEEE754Comparable"/" > IEEE754Equatable" instead of "Comparable"/"Equatable". Then it's all a > moot point since floating point types wouldn't end up in the same generic >

Re: [swift-evolution] [pitch] Comparison Reform

Maybe we should make Float/Double conform to "IEEE754Comparable"/"IEEE754Equatable" instead of "Comparable"/"Equatable". Then it's all a moot point since floating point types wouldn't end up in the same generic functions as other comparable types. (Not sure if I'm serious) - Dave Sweeris >

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > > on Tue Apr 18 2017, Xiaodi Wu wrote: > > > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > > on Tue Apr 18 2017, Xiaodi Wu wrote: > > > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via

Re: [swift-evolution] [pitch] Comparison Reform

on Tue Apr 18 2017, Xiaodi Wu wrote: > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Apr 17, 2017, at 9:07 AM, Joe

Re: [swift-evolution] [pitch] Comparison Reform

on Tue Apr 18 2017, Ben Cohen wrote: >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>> wrote: >>> > >>> On Apr 15, 2017, at 9:49

Re: [swift-evolution] [pitch] Comparison Reform

To me, there are two proposals here, partly interrelated but worth considering separately. 1. Use of @_implements to allow floating point to have an IEEE implementation of operators, while still having Comparable implement strict total order across every unique value (NaN.) This includes

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > > On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution < >

Re: [swift-evolution] [pitch] Comparison Reform

> On 18 Apr 2017, at 19:06, David Sweeris via swift-evolution > wrote: > > >> On Apr 18, 2017, at 8:40 AM, Ben Cohen via swift-evolution >> > wrote: >> >>> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner

Re: [swift-evolution] [pitch] Comparison Reform

I certainly don't want to restrain anyone from improving on the floating point status quo. There's surely much to do. I apologize for my not-so-constructive messages. Maybe I'm surprised that this was one of the goals of Swift. Floats and Strings are efficient ways to test comparison APIs

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 8:40 AM, Ben Cohen via swift-evolution > wrote: > >> >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> > wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff

Re: [swift-evolution] [pitch] Comparison Reform

> Le 18 avr. 2017 à 17:40, Joe Groff a écrit : > > >> On Apr 18, 2017, at 1:34 AM, Gwendal Roué wrote: >> >>> >>> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution >>> a écrit : >>> On Apr 17, 2017, at

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 11:43 AM, Stephen Canon via swift-evolution > wrote: >> On Apr 18, 2017, at 11:40 AM, Ben Cohen via swift-evolution >> > wrote: >> >> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 11:40 AM, Ben Cohen via swift-evolution > wrote: > > >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> > wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 1:34 AM, Gwendal Roué wrote: > >> >> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution >> a écrit : >> >>> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: >>> >>> On Apr 17,

Re: [swift-evolution] [pitch] Comparison Reform

>> then you're expecting the abstract guarantees of interchangeability and >> total ordering that implies > > > Joe, please: I'm very glad that you are expert in so many subject - I'd love > to have your job - but please keep track of average joes that have to scratch > their heads whenever

Re: [swift-evolution] [pitch] Comparison Reform

> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution > a écrit : > >> >> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: > > >> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution > wrote: > > >> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> For example, I expect `XCTAssertEqual(_:_:)` to be vended >> as part of XCTest, in

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 16 2017, Xiaodi Wu wrote: > On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull wrote: > >> >> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> The point is that, when you manipulate two

Re: [swift-evolution] [pitch] Comparison Reform

Sorting a collection will not use `<` as the default predicate. In the Gist, I've outlined a design for `[Double].sorted()` which would exhibit identical behavior to what is proposed in this thread, but the design would be different under the hood. In brief, the "go-to" overload for sorting a

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 16 2017, Xiaodi Wu wrote: > On Sun, Apr 16, 2017 at 1:13 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >>> > I have an incipient idea. It begins with: >> >> > >> >> > enum ComparisonResult { >> >> > case

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution > wrote: > > For example, I expect `XCTAssertEqual(_:_:)` to be vended > as part of XCTest, in order to make sure that > `XCTAssertEqual(resultOfComputation, Double.nan)` always fails. Unit tests strike

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 2:45 PM, Jonathan Hull wrote: > > On Apr 16, 2017, at 11:52 AM, Xiaodi Wu wrote: > > On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull wrote: > >> >> On Apr 16, 2017, at 10:45 AM, Xiaodi Wu wrote:

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 16, 2017, at 11:52 AM, Xiaodi Wu wrote: > > On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull > wrote: > >> On Apr 16, 2017, at 10:45 AM, Xiaodi Wu > > wrote: >> >> On Sun,

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull wrote: > > On Apr 16, 2017, at 10:45 AM, Xiaodi Wu wrote: > > On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> One benefit of the idea of using

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull wrote: > > On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > The point is that, when you manipulate two real numbers, sometimes there > is no numeric result. You cannot simply wish

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution > wrote: > > The point is that, when you manipulate two real numbers, sometimes there is > no numeric result. You cannot simply wish this away with a new numeric type > because it is not an artifact of

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 16, 2017, at 10:45 AM, Xiaodi Wu wrote: > > On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution > > wrote: > One benefit of the idea of using comparison metrics instead of changing >

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > One benefit of the idea of using comparison metrics instead of changing > comparable, is that you could just have two metrics on double. The default > one which is closer to what we have now

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 12:30 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 16, 2017, at 09:56, Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Another option is to make a new type, not sure what to call it but

  1   2   >