Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 29, 2016 at 2:11 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > Hi Tony, > > As you can see in the notes from April 27, 2016 language review, the > core team discussed this. Although one member had some reservations, I > think it would be very worthwhile

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Tue Apr 26 2016, Tony Allevato wrote: > On 2016-04-26 22:32:16 +, Dave Abrahams via swift-evolution said: > >> The main reasons to route through a single generic operator >> implementation are: >> >> * User experience; we want to cut down the number of overloads of any >> operator to a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Wed, Apr 27, 2016 at 1:14 PM Dave Abrahams wrote: > > The one possible alternative I thought of would be to support infix > notation, e.g. > > x T.+= y > > It might come down to what's easier to parse. > That personally looks a bit awkward to me, but if it turned out to be significa

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Wed Apr 27 2016, Tony Allevato wrote: > On Wed, Apr 27, 2016 at 1:14 PM Dave Abrahams wrote: > > The one possible alternative I thought of would be to support infix > notation, e.g. > > x T.+= y > > It might come down to what's easier to parse. > > That personally looks a bit

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Wed Apr 27 2016, Tony Allevato wrote: > On Wed, Apr 27, 2016 at 11:07 AM Dave Abrahams via swift-evolution > wrote: > > on Wed Apr 27 2016, Stephen Canon wrote: > > >> On Apr 27, 2016, at 1:54 PM, Dave Abrahams via swift-evolution > wrote: > >> > >> on Tue Apr 26 2016,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 27, 2016, at 10:54 AM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 26 2016, Chris Lattner wrote: > >> On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution >> wrote: >>> Would something like this be possible? Imagine protocols defined like this: >>> >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 27, 2016, at 9:10 AM, Jordan Rose wrote: > > >> On Apr 26, 2016, at 11:42, Chris Lattner via swift-evolution >> wrote: >> >> On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution >> wrote: >>> That seems like a purely syntactic concern that could potentially be >>> addre

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> Am 27.04.2016 um 16:45 schrieb Dave Abrahams : > >> >> On Apr 27, 2016, at 2:20 AM, Thorsten Seitz wrote: >> >> Am 27. April 2016 um 00:32 schrieb Dave Abrahams via swift-evolution >> : >> >>> >>> on Tue Apr 26 2016, Tony Allevato wrote: >>> On Sun, Apr 24, 2016 at 2:57 AM Nicola S

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Wed, Apr 27, 2016 at 11:07 AM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Wed Apr 27 2016, Stephen Canon wrote: > > >> On Apr 27, 2016, at 1:54 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> on Tue Apr 26 2016, Chris Lattn

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Wed Apr 27 2016, Stephen Canon wrote: >> On Apr 27, 2016, at 1:54 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Tue Apr 26 2016, Chris Lattner wrote: >> >>> On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution >>> wrote: > Would something like this be possible

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 27, 2016, at 1:54 PM, Dave Abrahams via swift-evolution > wrote: > > on Tue Apr 26 2016, Chris Lattner wrote: > >> On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution >> wrote: >>> Would something like this be possible? Imagine protocols defined like this: >>> >>> publi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Tue Apr 26 2016, Chris Lattner wrote: > On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution > wrote: >> Would something like this be possible? Imagine protocols defined like this: >> >> public protocol Equatable { >> static func == (lhs: Self, rhs: Self) -> Self >> } >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 26, 2016, at 11:42, Chris Lattner via swift-evolution > wrote: > > On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution > wrote: >> That seems like a purely syntactic concern that could potentially be >> addressed in other ways, though. I'm not sure the choice of "duplicat

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution wrote: > Would something like this be possible? Imagine protocols defined like this: > > public protocol Equatable { > static func == (lhs: Self, rhs: Self) -> Self > } The problem is that every type that conforms to Equat

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On 2016-04-26 22:32:16 +, Dave Abrahams via swift-evolution said: The main reasons to route through a single generic operator implementation are: * User experience; we want to cut down the number of overloads of any operator to a manageable set, in part because they live in the global n

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Tue Apr 26 2016, Tony Allevato wrote: > On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution > wrote: > > > > func isEqual(to other: Self) ->Bool > > > func isLess(than other: Self) ->Bool > > > func isLessThanOrEqual(to other: Self) ->Bool > > > > I'm stil

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Apr 26, 2016, at 12:28 PM, Xiaodi Wu wrote: > If this design is a workaround for type checker limitations, then perhaps > comparison method names are better prefixed with an underscore and/or using > abbreviated terms-of-art (eq, lt, lte, etc.)? As Tony points out, it seems > tragic to promo

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

If this design is a workaround for type checker limitations, then perhaps comparison method names are better prefixed with an underscore and/or using abbreviated terms-of-art (eq, lt, lte, etc.)? As Tony points out, it seems tragic to promote to an equal footing with `2.0 + 2.0 == 4.0` the alternat

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

You'll have to forgive my ignorance on the matter because I'm also not a type checker expert. If compile-time performance concerns are the motivating factor, is it possible to address them in a different way that would not require trampoline code or public interface bloat, like hoisting operators i

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 26, 2016, at 11:42 AM, Chris Lattner via swift-evolution > wrote: > > On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution > wrote: >> That seems like a purely syntactic concern that could potentially be >> addressed in other ways, though. I'm not sure the choice of "dupli

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution wrote: > That seems like a purely syntactic concern that could potentially be > addressed in other ways, though. I'm not sure the choice of "duplicate all > operators using verbosely-named methods" is the best one for the reasons I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

Again, +1 to Tony's analysis. In the context of numerics in particular, global functions and operators are very much "normal means," and if anything instance methods are rather "convenience." On Tue, Apr 26, 2016 at 13:36 Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > On T

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 26, 2016, at 9:19 AM, Jordan Rose via swift-evolution > wrote: > > I tend to agree. I’d like the inconsistency concerning operators and dispatch > to be resolved by investigating making operators into members, not by forcing > operators to be second-class citizens. (Obviously this de

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 11:29 AM Nicola Salmoria wrote: > On Tue, Apr 26, 2016 at 8:10 PM, Thorsten Seitz > wrote: > >> See inline. >> >> Am 26.04.2016 um 19:36 schrieb Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org>: >> >> On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato >> w

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 10:36 AM Nicola Salmoria wrote: > On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato > wrote: > >> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> > > func isEqual(to other: Self) ->Bool >>> > > func isLess(tha

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 8:10 PM, Thorsten Seitz wrote: > See inline. > > Am 26.04.2016 um 19:36 schrieb Nicola Salmoria via swift-evolution < > swift-evolution@swift.org>: > > On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato > wrote: > >> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-e

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 12:36 PM, Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato > wrote: > >> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> > > func isEqu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

See inline. > Am 26.04.2016 um 19:36 schrieb Nicola Salmoria via swift-evolution > : > >> On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato wrote: >>> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution >>> wrote: >>> > > func isEqual(to other: Self) ->Bool >>> > > func isLess(th

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 5:47 PM, Tony Allevato wrote: > That seems like a purely syntactic concern that could potentially be > addressed in other ways, though. I'm not sure the choice of "duplicate all > operators using verbosely-named methods" is the best one for the reasons I > mentioned above,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato wrote: > On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < > swift-evolution@swift.org> wrote: > >> > > func isEqual(to other: Self) ->Bool >> > > func isLess(than other: Self) ->Bool >> > > func isLessThanOrEqual(to other: Self)

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

+1 from me as well to Tony's write-up. -Thorsten > Am 26.04.2016 um 17:54 schrieb Xiaodi Wu via swift-evolution > : > > +1 to Tony's write-up. > >> On Tue, Apr 26, 2016 at 10:47 Tony Allevato via swift-evolution >> wrote: >> That seems like a purely syntactic concern that could potentially

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

I tend to agree. I’d like the inconsistency concerning operators and dispatch to be resolved by investigating making operators into members, not by forcing operators to be second-class citizens. (Obviously this deserves its own proposal and its own discussion.) Jordan > On Apr 26, 2016, at 08

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

+1 to Tony's write-up. On Tue, Apr 26, 2016 at 10:47 Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > That seems like a purely syntactic concern that could potentially be > addressed in other ways, though. I'm not sure the choice of "duplicate all > operators using verbosel

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

That seems like a purely syntactic concern that could potentially be addressed in other ways, though. I'm not sure the choice of "duplicate all operators using verbosely-named methods" is the best one for the reasons I mentioned above, and the question of "how do we cleanly unify operators with oth

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

I’m with Nicola on this one. Operators are currently odd in that they have to be declared globally. Everything else about protocol conformance is kept within the conforming type. - Dave Sweeris > On Apr 26, 2016, at 9:28 AM, Tony Allevato via swift-evolution > wrote: > > On Sun, Apr 24, 201

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > > > func isEqual(to other: Self) ->Bool > > > func isLess(than other: Self) ->Bool > > > func isLessThanOrEqual(to other: Self) ->Bool > > > > I'm still not sure why these are methods instead

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

First, something absent: I'm a little bit concerned by the act that there's no means to convert between different concrete FloatingPoint types. Something like the IntMax mechanism in Swift 2's IntegerType might be useful, though there may be good reasons not to do that. >>> >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Mon, Apr 25, 2016 at 1:32 PM, Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote: > >> func isEqual(to other: Self) -> Bool > >> func isLess(than other: Self) -> B

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 25, 2016, at 6:10 PM, Dave Abrahams via swift-evolution > wrote: > > on Mon Apr 25 2016, Stephen Canon wrote: > >>> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>> A few things… >>> >>> First, something absent: I'm a little bit concerned by

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Mon Apr 25 2016, Stephen Canon wrote: >> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> A few things… >> >> First, something absent: I'm a little bit concerned by the act that >> there's no means to convert between different concrete FloatingPoint >> t

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 25, 2016, at 2:12 PM, Jordan Rose wrote: > >> On Apr 22, 2016, at 7:13, Stephen Canon > > wrote: >> >>> /// A signaling NaN (not-a-number). >>> @warn_unused_result >>> static func signalingNaN: Self { get } >>> >>> I’m not sure it really makes sense for a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution > wrote: > > A few things… > > First, something absent: I'm a little bit concerned by the act that there's > no means to convert between different concrete FloatingPoint types. Something > like the IntMax mechanism in Swif

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 7:13, Stephen Canon wrote: > >> /// A signaling NaN (not-a-number). >> @warn_unused_result >> static func signalingNaN: Self { get } >> >> I’m not sure it really makes sense for a Bignum / APFloat type to support >> such a value. But really I think this is just unde

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On 4/23/16 21:53, Brent Royal-Gordon via swift-evolution wrote: >> public protocol FloatingPoint: Comparable, IntegerLiteralConvertible { >> public protocol BinaryFloatingPoint: FloatingPoint, FloatLiteralConvertible { > > Any reason why FloatLiteralConvertible isn't on FloatingPoint? While I'm n

[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> > func isEqual(to other: Self) ->Bool > > func isLess(than other: Self) ->Bool > > func isLessThanOrEqual(to other: Self) ->Bool > > I'm still not sure why these are methods instead of operators. I think this is an *excellent* choice, and I hope it is the first step to completely removing opera

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

A few things… First, something absent: I'm a little bit concerned by the act that there's no means to convert between different concrete FloatingPoint types. Something like the IntMax mechanism in Swift 2's IntegerType might be useful, though there may be good reasons not to do that. > public

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Fri Apr 22 2016, Stephen Canon wrote: > This argument makes no sense to me. A floating point number is made up > of three parts, and one part *is* not like the other ones. > > In what way is it different? It's not a number. -- Dave ___ sw

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 8:13 AM, Stephen Canon via swift-evolution > wrote: > > >> /// A signaling NaN (not-a-number). >> @warn_unused_result >> static func signalingNaN: Self { get } >> >> I’m not sure it really makes sense for a Bignum / APFloat type to support >> such a value. But rea

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

Neither, actually. NaN is a valid value and even its use does not always lead to exceptions. For example, it's possible (and a deliberate use case) to assign NaN (even signaling NaN), and the IEEE 754 function maxNum(x, y) (here proposed as `maximum`) will return x if x is not NaN and y is NaN. On

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 12:42 PM, Dave Abrahams via swift-evolution > wrote: > > This argument makes no sense to me. A floating point number is made up > of three parts, and one part *is* not like the other ones. In what way is it different?___ swift-

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

(-1)^sign * significand * radix^exponent Significand is not like the other two, I guess, since nothing is raised to it as a power... On Fri, Apr 22, 2016 at 11:42 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > A floating point number is made up > of three parts, a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Fri Apr 22 2016, Stephen Canon wrote: > I’d be okay with Greg’s idea of changing the type to an enum. I’d also be > okay with renaming this to a predicate, whatever the name ends up being. > (“isSignBitSet”, “isSignNegative”, etc.) > > Making it a predicate is weird, because then

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 12:09 PM, Xiaodi Wu wrote: > >> >> This runs into exactly the same issues; in the (extremely rare) cases where >> such enormous exponents are used, they tend to be coupled with surprisingly >> modest significands, so I don’t think this fixes anything. >> >> There was so

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 11:09 AM, Xiaodi Wu wrote: > On Fri, Apr 22, 2016 at 11:04 AM, Stephen Canon wrote: >> >>> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu wrote: >>> >>> On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon wrote: > On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 12:21 PM, Xiaodi Wu wrote: > > To expand, the hypothetical use case I'm trying to leave open is this: > suppose I want to implement a Float1024 type with 79 exponent bits and > 944 fraction bits. Could I conform it to BinaryFloatingPoint? As > currently proposed, no. What wo

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 11:04 AM, Stephen Canon wrote: > >> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu wrote: >> >> On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon wrote: >>> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu wrote: > > On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon wrote: >> >>> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: >>> >>> On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon wrote: > >> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: >> >> On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: >>> >>> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: >>> >>> Naive question: is it necessary to make a trade-off here? Why not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 11:29 AM, David Sweeris wrote: > >> On Apr 22, 2016, at 9:56 AM, Stephen Canon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu >> > wrote: >>> >>> Naive question: is it necessary t

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: > > On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: >> >> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: >> >> Naive question: is it necessary to make a trade-off here? Why not an >> associated type Exponent that's Int for Float, Double,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 9:56 AM, Stephen Canon via swift-evolution > wrote: > > >> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu > > wrote: >> >> Naive question: is it necessary to make a trade-off here? Why not an >> associated type Exponent that's Int for Float, Double, a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: > > On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: > > Naive question: is it necessary to make a trade-off here? Why not an > associated type Exponent that's Int for Float, Double, and Float80, > allowing for something else for bignums? > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

It was originally used for nan static function payload argument, but as that function has been removed from the FloatingPoint protocol, the associatedtype could also be moved down. – Steve > On Apr 22, 2016, at 11:16 AM, Xiaodi Wu wrote: > > One more stray thought: > Is there a reason RawSign

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

One more stray thought: Is there a reason RawSignificand is declared in FloatingPoint but used only in BinaryFloatingPoint? On Fri, Apr 22, 2016 at 10:02 AM, Xiaodi Wu wrote: > Two stray thoughts: > > I agree with previous comments that `ulpOfOne` may not really be necessary. > > Of the followin

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: > > On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: > > Naive question: is it necessary to make a trade-off here? Why not an > associated type Exponent that's Int for Float, Double, and Float80, > allowing for something else for bignums? > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

Two stray thoughts: I agree with previous comments that `ulpOfOne` may not really be necessary. Of the following-- ``` init(signBit: Bool, exponent: Int, significand: Self) init(magnitudeOf other: Self, signOf: Self) ``` --would it be more elegant to have the latter be `init(signOf: Self, mag

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: > > Naive question: is it necessary to make a trade-off here? Why not an > associated type Exponent that's Int for Float, Double, and Float80, > allowing for something else for bignums? It’s an added (fairly minor) complexity to the API surface t

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 9:13 AM, Stephen Canon via swift-evolution wrote: > > On Apr 21, 2016, at 9:13 PM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md] > > This is super impressive. I do have several bits I’m

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 21, 2016, at 9:13 PM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md > > ] > > This is super impressi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 21, 2016, at 19:58, James Berry wrote: > > >> On Apr 21, 2016, at 6:13 PM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On 'isLessThanOrEqual(to:)’: I agree with Xiaodi that the argument label is >> problematic here. I think the problem is that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 21, 2016, at 6:13 PM, Jordan Rose via swift-evolution > wrote: > > On 'isLessThanOrEqual(to:)’: I agree with Xiaodi that the argument label is > problematic here. I think the problem is that we have two prepositions that > apply to the argument, and “pick the second one” leaves the b

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md ] This is super impressive. I do have several bits I’m uncomfortable with, however. I’ll t