Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

on Thu Apr 21 2016, Thorsten Seitz wrote: > I totally agree with you. > > But I think that the suggested Summable with zero fits the bill of > your citation quite nicely as it actually is a very generic concept > which is widely useful. Sure, that's Monoid. My main objection is to adding a "M

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

I totally agree with you. But I think that the suggested Summable with zero fits the bill of your citation quite nicely as it actually is a very generic concept which is widely useful. FWIW I had chosen the name Summable instead of Monoid for two reasons: (1) there has been reluctance by som

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

on Wed Apr 20 2016, davesweeris-AT-mac.com wrote: >> On Apr 20, 2016, at 1:15 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Apr 19 2016, Thorsten Seitz wrote: >> >>> I'd like to have something like Summable with 'add', 'adding' and 'zero' >>> being a >>> separate protocol

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

I totally agree with Dave Sweeris. He has put the issue quite nicely. Being able to add protocol conformance to a protocol would indeed solve this problem (having well designed protocols in the standard library would still be nice, though, so many thanks for the pointers, Dave A, that looks real

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 20, 2016, at 1:15 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 19 2016, Thorsten Seitz wrote: > >> I'd like to have something like Summable with 'add', 'adding' and 'zero' >> being a >> separate protocol as well as somthing like Multiplicative with 'multiply', >>

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

on Tue Apr 19 2016, Thorsten Seitz wrote: > I'd like to have something like Summable with 'add', 'adding' and 'zero' > being a > separate protocol as well as somthing like Multiplicative with 'multiply', > 'multiplied' and 'one' being a separate protocol, because these are > universally > inte

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

on Mon Apr 18 2016, Greg Parker wrote: >> On Apr 14, 2016, at 10:07 PM, Stephen Canon via swift-evolution >> wrote: >> >>> On Apr 14, 2016, at 8:34 PM, Brent Royal-Gordon >>> wrote: >>> Stephen Canon wrote: public protocol Arithmetic >>> >>> Is there a rationale for the na

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

I'd like to have something like Summable with 'add', 'adding' and 'zero' being a separate protocol as well as somthing like Multiplicative with 'multiply', 'multiplied' and 'one' being a separate protocol, because these are universally interesting for other cases, e.g. Summable would be useful f

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution > wrote: > > /// `true` iff the signbit of `self` is set. Implements the IEEE 754 > /// `signbit` operation. > /// > /// Note that this is not the same as `self < 0`. In particular, this > /// property is true for `-0`

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 10:07 PM, Stephen Canon via swift-evolution > wrote: > >> On Apr 14, 2016, at 8:34 PM, Brent Royal-Gordon >> wrote: >> >>> Stephen Canon wrote: >>> >>> public protocol Arithmetic >> >> Is there a rationale for the name "Arithmetic"? There's probably nothing >> wrong

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

+1 `prefix -=`, it logically follows :) -- Howard. On 19 April 2016 at 09:02, wrote: > "prefix -=“? > > (I’m not sure if I’m serious) > > - Dave Sweeris > > On Apr 18, 2016, at 5:57 PM, Howard Lovatt > wrote: > > I think `prefix -` works for `negated` (non-mutating form) but not > `negate` (

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

"prefix -=“? (I’m not sure if I’m serious) - Dave Sweeris > On Apr 18, 2016, at 5:57 PM, Howard Lovatt wrote: > > I think `prefix -` works for `negated` (non-mutating form) but not `negate` > (mutating form). IE `-=` is the mutating form of `infix -` and there is no > equivalent in C-like la

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

I think `prefix -` works for `negated` (non-mutating form) but not `negate` (mutating form). IE `-=` is the mutating form of `infix -` and there is no equivalent in C-like languages for `negated` :( -- Howard. On 19 April 2016 at 08:28, wrote: > On Apr 16, 2016, at 6:12 PM, Howard Lovatt via

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 16, 2016, at 6:12 PM, Howard Lovatt via swift-evolution > wrote: > > For the Arithmetic protocol how about changing it to: > > protocol Arithmetic { > func + (lhs: Self, rhs: Self) -> Self > mutating func += (rhs: Self) -> Self > ... > } > > That way na

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

on Thu Apr 14 2016, Stephen Canon wrote: > Hi Howard, thanks for the feedback. > > On Apr 14, 2016, at 6:05 PM, Howard Lovatt > wrote: > > +1 great addition. > > Would suggest the naming could be more consistent, in particular: > > 1 Anything returning Self could be named xxxed

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

on Fri Apr 15 2016, Brent Royal-Gordon wrote: >>> Are there potential conforming types which aren't Comparable? >> >> Not at present, but I expect there to be in the future. Modular integers >> and complex numbers come to mind as the most obvious examples. > > Ooh, those are great examples. T

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

For the Arithmetic protocol how about changing it to: protocol Arithmetic { func + (lhs: Self, rhs: Self) -> Self mutating func += (rhs: Self) -> Self ... } That way naming issues are largely avoided, except for `mutating func negate()` which has no operator and wo

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> Oh, a couple more things I just thought of: > > > public protocol Arithmetic: Equatable, IntegerLiteralConvertible { > If your goals include supporting complex numbers, how is > IntegerLiteralConvertible going to fit in there? > > > /// Initialize to zero > > init() > 0 is valuable as the addi

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 11:15, Erica Sadun via swift-evolution > wrote: > > Finally, it's Swift. Isn't it time for π and 𝜏 as well as Pi and Tau? Yes! I was waiting to bring up tau. ___ swift-evolution mailing list swift-evolution@swift.org https://li

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Oh, a couple more things I just thought of: > public protocol Arithmetic: Equatable, IntegerLiteralConvertible { If your goals include supporting complex numbers, how is IntegerLiteralConvertible going to fit in there? > /// Initialize to zero > init() 0 is valuable as the additive identit

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

On 2016-04-15, 18:58, Stephen Canon wrote: but the documentation for Equatable and Comparable states that == and < must implement an equivalence relation and a strict total order, which is incompatible with the default IEEE-754 implementation of these operators when NaN values are involved. How

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 12:22 PM, Stephen Canon wrote: > >> >> On Apr 15, 2016, at 11:14 AM, Erica Sadun > > wrote: >> That said, I use M_PI_4 a lot because it's really handy for sample code. I'm >> one of the >> outlier users whose use is not reflective of this quic

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

On Apr 15, 2016, at 11:05 AM, Guillaume Lessard via swift-evolution wrote: > I don’t see why this is needed; there isn't an AdditivelyInvertible protocol That’s precisely SignedArithmetic, just under a different name. – Steve___ swift-evolution maili

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 11:14 AM, Erica Sadun wrote: > > On Apr 15: 2016: at 11:56 AM: Joe Groff via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 15: 2016: at 8:20 AM: Stephen Canon via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> “e” i

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

On Apr 15: 2016: at 11:56 AM: Joe Groff via swift-evolution mailto:swift-evolution@swift.org>> wrote: > > >> On Apr 15: 2016: at 8:20 AM: Stephen Canon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> “e” is a great bike-shedding example. While it would definitely allow

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

On Apr 15: 2016: at 11:56 AM: Joe Groff via swift-evolution wrote: > > >> On Apr 15: 2016: at 8:20 AM: Stephen Canon via swift-evolution >> wrote: >> >> “e” is a great bike-shedding example. While it would definitely allow a >> fluent style if you know what you’re looking at: I worry a lit

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On 15 avr. 2016, at 00:48, Nicola Salmoria via swift-evolution > wrote: > > It might make sense to also have a > > public protocol InvertibleArithmetic : Arithmetic { > func inverted() -> Self > } > > FloatingPoint would conform to this protocol, returning 1/x, while integer > types would

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Hi Stephen > Hi Erica, thanks for the feedback. > >> On Apr 14, 2016, at 6:29 PM, Erica Sadun > > wrote: >> >> * I do use % for floating point but not as much as I first thought before I >> started searching through my code after reading your e-mail. But when I do

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 8:20 AM, Stephen Canon via swift-evolution > wrote: > > “e” is a great bike-shedding example. While it would definitely allow a > fluent style if you know what you’re looking at, I worry a little bit about > readability of `Float.e` or `.e` in source. Most programmers

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

On Apr 15, 2016, at 8:20 AM, Stephen Canon wrote: >> >> Incidentally, if you make pi and e be static members of the type, we should >> get a pretty fluent style, along the lines of: >> >> let x = someDouble * 2 * .pi >> >> I agree that there is a concern about deciding “which” constants t

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

The floating-point API design looks great. However, I'm concerned about providing a generic Arithmetic protocol: > On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution > wrote: > > A new protocol, Arithmetic, is introduced that provides the most basic > operations (add, subtract, mu

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 9:52 AM, Stephan Tolksdorf via swift-evolution > wrote: > > but the documentation for Equatable and Comparable states that == and < must > implement an equivalence relation and a strict total order, which is > incompatible with the default IEEE-754 implementation of these

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Hi Stephen, You write * FloatingPoint should conform to Equatable, and Comparable but the documentation for Equatable and Comparable states that == and < must implement an equivalence relation and a strict total order, which is incompatible with the default IEEE-754 implementation of the

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> > Ultimately, we may want to have a finer-grained classification of numeric > protocols, but “schoolbook arithmetic” is a pretty reasonable set of > operations while we’re picking just one. > > – Steve > The only thing I want to add to this fantastic discussion is that, while "schoolbook a

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 11:48 PM, Nicola Salmoria > wrote: > >> /// The quotient of `self` dividing by `rhs`. >> // Arithmetic provides a default implementation of this method in terms >> // of the mutating `divide` operation. >> @warn_unused_result >> func divided(by rhs: Self) -> Self >>

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 7:23 AM, plx via swift-evolution > wrote: > > One is if there’s any ETA or similar for a glimpse at the “complete picture” > of Swift’s revised numeric protocols; these floating-point protocols look > really, really good, but this is also (I think) the first glimpse at th

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 10:47 PM, daveswee...@mac.com wrote: > > In general, I think this is fantastic. In particular, I *really* like the > notion that `BinaryFloatingPoint` conforms to `FloatingPoint`. I would do a > few things differently, though: >> On Apr 14, 2016, at 6:55 PM, Stephen Canon v

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 10:12 PM, Erica Sadun wrote: > > >> On Apr 14, 2016, at 10:36 PM, Stephen Canon > > wrote: >> >> Hi Erica, thanks for the feedback. >> >>> On Apr 14, 2016, at 6:29 PM, Erica Sadun >> > wrote: >>> >>> * I do use % for

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

+1 great addition. Would suggest the naming could be more consistent, in particular: 1. Anything returning Self could be named xxxed. In the current proposal this naming convention is sometimes used, e.g. divided, and sometimes not, e.g. subtracting. Suggest all unified with the xxxed co

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 11:05 PM, Chris Lattner wrote: > > >> On Apr 14, 2016, at 11:01 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Apr 14, 2016, at 9:49 PM, Stephen Canon > > wrote: On Apr 14, 2016, at 4:55 PM, Steph

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

+1; this is great! I have nothing but good things to say about the proposal itself. I have two smaller questions, however; I apologize if they are off-topic. One is if there’s any ETA or similar for a glimpse at the “complete picture” of Swift’s revised numeric protocols; these floating-point p

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

>> Are there potential conforming types which aren't Comparable? > > Not at present, but I expect there to be in the future. Modular integers and > complex numbers come to mind as the most obvious examples. Ooh, those are great examples. That is definitely the right decision, then. (One thing

[swift-evolution] [Proposal draft] Enhanced floating-point protocols

> /// The quotient of `self` dividing by `rhs`. > // Arithmetic provides a default implementation of this method in terms > // of the mutating `divide` operation. > @warn_unused_result > func divided(by rhs: Self) -> Self > > /// Divides `self` by `rhs`. > mutating func divide(by r

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 11:01 PM, Chris Lattner via swift-evolution > wrote: > > On Apr 14, 2016, at 9:49 PM, Stephen Canon > wrote: >>> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: Provide basic const

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

On Apr 14, 2016, at 9:49 PM, Stephen Canon wrote: >> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> Provide basic constants (analogues of C's DBL_MAX, etc.) >> Nice, have you considered adding pi/e and other common constants? I’d

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

In general, I think this is fantastic. In particular, I *really* like the notion that `BinaryFloatingPoint` conforms to `FloatingPoint`. I would do a few things differently, though: > On Apr 14, 2016, at 6:55 PM, Stephen Canon via swift-evolution > wrote: > > public protocol FloatingPoint: Sig

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 10:36 PM, Stephen Canon wrote: > > Hi Erica, thanks for the feedback. > >> On Apr 14, 2016, at 6:29 PM, Erica Sadun > > wrote: >> >> * I do use % for floating point but not as much as I first thought before I >> started searching through my c

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Hi Brent, thanks for the feedback. > On Apr 14, 2016, at 8:34 PM, Brent Royal-Gordon > wrote: > > First of all: I do *not* do crazy things with floating-point numbers, so > there's a good chance I'm missing the point with some of this. Consider > anything having to do with NaNs, subnormals, o

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Thanks for the feedback, Chris. > On Apr 14, 2016, at 9:06 PM, Chris Lattner wrote: > > This proposal looks really really great, let me know when you want to start > the review process (or just submit a PR for the -evolution repo) and I’ll > happily review manage it for you. > > On Apr 14, 20

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Hi Howard, thanks for the feedback. > On Apr 14, 2016, at 6:05 PM, Howard Lovatt wrote: > > +1 great addition. > > Would suggest the naming could be more consistent, in particular: > Anything returning Self could be named xxxed. In the current proposal this > naming convention is sometimes use

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Hi Erica, thanks for the feedback. > On Apr 14, 2016, at 6:29 PM, Erica Sadun wrote: > > * I do use % for floating point but not as much as I first thought before I > started searching through my code after reading your e-mail. But when I do > use it, it's nice to have a really familiar symbol

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

This proposal looks really really great, let me know when you want to start the review process (or just submit a PR for the -evolution repo) and I’ll happily review manage it for you. On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution wrote: > Provide basic constants (analogues of

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

First of all: I do *not* do crazy things with floating-point numbers, so there's a good chance I'm missing the point with some of this. Consider anything having to do with NaNs, subnormals, or other such strange denizens of the FPU to be prefixed with "I may be totally missing the point, but…"

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

* I do use % for floating point but not as much as I first thought before I started searching through my code after reading your e-mail. But when I do use it, it's nice to have a really familiar symbol rather than a big word. What were the ways that it was used incorrectly? Do you have some exam

[swift-evolution] [Proposal draft] Enhanced floating-point protocols

Enhanced floating-point protocols Proposal: SE- Author(s): Stephen Canon Status: Awaiting review Review manager: TBD