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

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

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

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

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

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

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:

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

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 >

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

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

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

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

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

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

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

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

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. –

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 > > wrote: >> >> >>> On Apr 15: 2016: at 8:20 AM: Stephen Canon via swift-evolution >>>

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

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

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

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`

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

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 >

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

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

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

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

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

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

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

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 >> > wrote: >> >> On Apr 14, 2016, at 9:49 PM, Stephen Canon >

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

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

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

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 >> > wrote: >>> Provide basic constants (analogues of C's DBL_MAX, etc.) >> Nice, have you considered

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

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

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

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

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…"