Re: [swift-evolution] protocol-oriented integers (take 2)

Hi Ben, The reason to include init?(exactly:T) as a requirement for the Arithmetic (now Number) protocol was that it already refines ExpressibleByIntegerLiteral, so it would be quite weird to *not* allow explicit initialization. Generic conversion to floating point types is not covered by

Re: [swift-evolution] protocol-oriented integers (take 2)

The problem with moving divided(by:) to DoubleWidth is that over there. When `dividing(_:)` is on the FixedWidthInteger conforming type, Self is known and it is possible to implement this operation efficiently. If it moves to the DoubleWidth, because T is just “something that conforms to

Re: [swift-evolution] protocol-oriented integers (take 2)

on Tue Jan 31 2017, Xiaodi Wu wrote: > Why not move the `dividing` version to DoubleWidth, where it can be > a proper `divided(by:)`? Why didn't I think of that? :-) -- -Dave ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] protocol-oriented integers (take 2)

On Tue, Jan 31, 2017 at 10:15 PM, Dave Abrahams wrote: > > on Tue Jan 31 2017, Xiaodi Wu wrote: > > > On Tue, Jan 31, 2017 at 2:53 PM, Max Moiseev wrote: > > > >> Hi Brent, > >> > >> Thanks a lot for your suggestions! After having discussed them with >

Re: [swift-evolution] protocol-oriented integers (take 2)

on Tue Jan 31 2017, Xiaodi Wu wrote: > On Tue, Jan 31, 2017 at 2:53 PM, Max Moiseev wrote: > >> Hi Brent, >> >> Thanks a lot for your suggestions! After having discussed them with Dave, >> we came up with the following design that I personally like a lot. >> >> enum

Re: [swift-evolution] protocol-oriented integers (take 2)

> On 31 Jan 2017, at 20:53, Max Moiseev via swift-evolution > wrote: > > Hi Brent, > > Thanks a lot for your suggestions! After having discussed them with Dave, we > came up with the following design that I personally like a lot. > > enum Overflowing { case

Re: [swift-evolution] protocol-oriented integers (take 2)

Cute. Reminds me of C++ STL's struct tags: http://en.cppreference. com/w/cpp/utility/piecewise_construct_t http://en.cppreference.com/w/cpp/iterator/iterator_tags On Tue, Jan 31, 2017 at 12:53 PM, Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > Hi Brent, > > Thanks a lot

Re: [swift-evolution] protocol-oriented integers (take 2)

Hi Brent, Thanks a lot for your suggestions! After having discussed them with Dave, we came up with the following design that I personally like a lot. enum Overflowing { case .withOverflow } enum FullWidth { case .fullWidth } protocol FixedWidthInteger { func adding(_ other: Self, _:

Re: [swift-evolution] protocol-oriented integers (take 2)

on Mon Jan 30 2017, Brent Royal-Gordon wrote: >> On Jan 30, 2017, at 11:25 AM, Dave Abrahams via swift-evolution >> wrote: >> >>> I mean that `OptionSet.RawValue` currently has to conform to >>> `BitwiseOperations`, >> >> Actually it doesn't. You just have to

Re: [swift-evolution] protocol-oriented integers (take 2)

It’s (a) the inverse operation of doubleWidthMultiply. (b) an important building block for fast “small bignum arithmetic” (2-16 ish words). If you have this operation, it’s easy to build the divide that does DoubleWidth / DoubleWidth. (c) the widest divide operation that maps reasonably cleanly

Re: [swift-evolution] protocol-oriented integers (take 2)

…rather, the remainder will fit in width min(X, Y) Nevin On Tuesday, January 31, 2017, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > What, exactly, is the intended purpose of doubleWidthDivide? > > I ask because, outside of degenerate cases, a quotient and remainder will

Re: [swift-evolution] protocol-oriented integers (take 2)

What, exactly, is the intended purpose of doubleWidthDivide? I ask because, outside of degenerate cases, a quotient and remainder will fit in the same size type as the operands. So widthX / widthY will have quotient that fits in width X, and remainder that fits in width Y. In general, we cannot

Re: [swift-evolution] protocol-oriented integers (take 2)

On Mon, Jan 30, 2017 at 10:08 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jan 30, 2017, at 11:25 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > >> I mean that `OptionSet.RawValue` currently has to conform to > >>

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 30, 2017, at 11:25 AM, Dave Abrahams via swift-evolution > wrote: > >> I mean that `OptionSet.RawValue` currently has to conform to >> `BitwiseOperations`, > > Actually it doesn't. You just have to implement these yourself in that > case: > > extension

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 30, 2017, at 11:31 AM, Max Moiseev wrote: > > doubleWidthDivide should not return a DoubleWidth for two reasons: > 1. The components of it’s return type are not high and low, but are quotient > and remainder instead. > 2. In DoubleWidth high is T and low is

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 30, 2017, at 12:21 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jan 29, 2017, at 10:07 PM, Dave Abrahams wrote: >> > It might make a great deal of sense to support bitwise operations on > this type, I

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 4:41 AM, Xiaodi Wu wrote: > > > > static func doubleWidthMultiply(_ lhs: Self, _ rhs: Self) -> (high: Self, > > low: Magnitude) > > static func doubleWidthDivide(_ lhs: (high: Self, low: Magnitude), _ rhs: > > Self) -> (quotient: Self,

Re: [swift-evolution] protocol-oriented integers (take 2)

on Mon Jan 30 2017, Brent Royal-Gordon wrote: >> On Jan 29, 2017, at 10:07 PM, Dave Abrahams wrote: >> > It might make a great deal of sense to support bitwise operations on > this type, I think that's a model of SetAlgebra,

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 10:07 PM, Dave Abrahams wrote: > It might make a great deal of sense to support bitwise operations on this type, >>> >>> I think that's a model of SetAlgebra, then, isn't it? >> >> Hmm, arguably. It's a shame that we won't be able to use it

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 29 2017, Brent Royal-Gordon wrote: >> On Jan 29, 2017, at 7:02 PM, Dave Abrahams via swift-evolution >> wrote: >> var popcount: Int { get } >>> >>> I'm not super-fond of this name; I assume it's a term of art, but it's >>> a pretty obscure one.

Re: [swift-evolution] protocol-oriented integers (take 2)

I share your concern about trailingZeros and leadingZeros; those could probably be improved as trailingZeroBits and leadingZeroBits. The terms of art there, ctz ("count trailing zeros") and clz, are a bit cryptic but perhaps also fine if ulp is acceptable for FloatingPoint. On Sun, Jan 29, 2017

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 7:02 PM, Dave Abrahams via swift-evolution > wrote: > >>> var popcount: Int { get } >> >> I'm not super-fond of this name; I assume it's a term of art, but it's >> a pretty obscure one. Maybe `numberOfOnes`? `onesWithin`? > > Yes, the

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 29 2017, Brent Royal-Gordon wrote: >> On Jan 13, 2017, at 12:47 PM, Max Moiseev via swift-evolution >> wrote: >> >> Protocol-oriented integers (take 2) >> >> • Proposal: SE- >> • Authors: Dave Abrahams, Maxim

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 29, 2017 at 2:30 PM, David Sweeris wrote: > > On Jan 29, 2017, at 12:13, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris > wrote: > >> >> On Jan 29, 2017, at 10:36, Xiaodi Wu

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 12:13, Xiaodi Wu wrote: > >> On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris wrote: >> >>> On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: >>> >>> Hmm, interesting. I might be tempted to use a 40-bit type for

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris wrote: > > On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: > > Hmm, interesting. I might be tempted to use a 40-bit type for large > arrays, but the performance hit for any useful computation over a large >

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: > > Hmm, interesting. I might be tempted to use a 40-bit type for large arrays, > but the performance hit for any useful computation over a large array would > probably tilt heavily in favor of plain 64-bit integers. What's

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 29 2017, Jonathan Hull wrote: > Shouldn’t “Number” be reserved for a foundation type similar to > NSNumber? Or would this protocol actually serve that purpose? I don't think so. What is the purpose of NSNumber? I always viewed it as being, approximately, a box that allows us to

Re: [swift-evolution] protocol-oriented integers (take 2)

Hmm, interesting. I might be tempted to use a 40-bit type for large arrays, but the performance hit for any useful computation over a large array would probably tilt heavily in favor of plain 64-bit integers. What's your use case for such a 40-bit type? And is it common enough to justify such a

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 13, 2017, at 12:47, Max Moiseev via swift-evolution > wrote: > DoubleWidth > The DoubleWidth type allows to create wider fixed-width integer types from > the ones available in the standard library. > > Standard library currently provides fixed-width

Re: [swift-evolution] protocol-oriented integers (take 2)

I think these protocols + generics should cover most such use cases, no? On Sun, Jan 29, 2017 at 06:57 Jonathan Hull wrote: > Shouldn’t “Number” be reserved for a foundation type similar to NSNumber? > Or would this protocol actually serve that purpose? > > I was planning to

Re: [swift-evolution] protocol-oriented integers (take 2)

Shouldn’t “Number” be reserved for a foundation type similar to NSNumber? Or would this protocol actually serve that purpose? I was planning to ask for a value type similar to NSNumber in phase 2. I built one for my own code (a struct around an enum which can be Int, Decimal, Rational, or

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 29, 2017 at 6:02 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jan 13, 2017, at 12:47 PM, Max Moiseev via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Protocol-oriented integers (take 2) > > > > • Proposal: SE- > >

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 13, 2017, at 12:47 PM, Max Moiseev via swift-evolution > wrote: > > Protocol-oriented integers (take 2) > > • Proposal: SE- > • Authors: Dave Abrahams, Maxim Moiseev > • Review Manager: TBD > • Status: Awaiting review > •

Re: [swift-evolution] protocol-oriented integers (take 2)

Renaming Arithmetic to Number (and having SignedNumber) might actually end up being a win, since we need to provide SignedNumber to maintain source code compatibility anyway. > On Jan 27, 2017, at 8:34 AM, Xiaodi Wu via swift-evolution > wrote: > > I'd always just

Re: [swift-evolution] protocol-oriented integers (take 2)

I'd always just assumed that Arithmetic was chosen so that SignedArithmetic wouldn't clash with the old SignedNumber. If that's not an issue, definitely agree that Number is the superior name. On Fri, Jan 27, 2017 at 08:30 T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote: > Oh,

Re: [swift-evolution] protocol-oriented integers (take 2)

Oh, I misread the arrows in that diagram and this makes much more sense now. Thanks. On Fri, Jan 27, 2017 at 9:14 AM, Stephen Canon wrote: > The bitwise stuff isn't on ArithMETic | ARITHmetic | Number | whatever. > > On Jan 27, 2017, at 9:13 AM, T.J. Usiyan via

Re: [swift-evolution] protocol-oriented integers (take 2)

The bitwise stuff isn't on ArithMETic | ARITHmetic | Number | whatever. > On Jan 27, 2017, at 9:13 AM, T.J. Usiyan via swift-evolution > wrote: > > Regarding `Number` or `Numeric`: Does everything in Arithmetic apply to > complex numbers and do we want it to? The

Re: [swift-evolution] protocol-oriented integers (take 2)

Regarding `Number` or `Numeric`: Does everything in Arithmetic apply to complex numbers and do we want it to? The bitwise stuff is where I think that there might be a mismatch. On Thu, Jan 26, 2017 at 2:26 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun Jan

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Stephen Canon wrote: > Responding to the thread in general here, not so much any specific email: > > “Arithmetic” at present is not a mathematically-precise concept, and > it may be a mistake to make it be one[1]; it’s a >

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 10:03, Xiaodi Wu via swift-evolution > wrote: > > Stephen Canon wrote that Arithmetic should refine ExpressibleByIntegerLiteral > because of certain mathematical properties of rings. In that case, 0 and 1 > would just be spelled in that way.

Re: [swift-evolution] protocol-oriented integers (take 2)

I wish I knew how to express those requirements in the type system. This is a good way to implement additiveIdentity but I assume that Arithmetic protocol implies behavior of Addable. > On Jan 25, 2017, at 20:58, David Sweeris wrote: > >> >> On Jan 25, 2017, at 07:59,

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 1:58 PM, David Sweeris via swift-evolution > wrote: > > >> On Jan 25, 2017, at 07:59, Anton Mironov via swift-evolution >> wrote: >> >> Hi everyone, >> >> I want to suggest a tiny extension to an Arithmetic

Re: [swift-evolution] protocol-oriented integers (take 2)

Sent from my iPhone > On Jan 25, 2017, at 1:45 PM, David Sweeris via swift-evolution > wrote: > > >> On Jan 25, 2017, at 10:03, Xiaodi Wu via swift-evolution >> wrote: >> >> Stephen Canon wrote that Arithmetic should refine >>

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 07:59, Anton Mironov via swift-evolution > wrote: > > Hi everyone, > > I want to suggest a tiny extension to an Arithmetic protocol. It would be > nice to have an additive identity and a multiplicative identity constants. > Basically zero and

Re: [swift-evolution] protocol-oriented integers (take 2)

It should already be possible to handle special cases like that since you can reässign self in an initializer. Here's a contrived example; would it allay your performance concerns? ``` struct Foo: ExpressibleByIntegerLiteral { private let value: String private static let zero = Foo("a

Re: [swift-evolution] protocol-oriented integers (take 2)

Stephen Canon wrote that Arithmetic should refine ExpressibleByIntegerLiteral because of certain mathematical properties of rings. In that case, 0 and 1 would just be spelled in that way. Otherwise, +1. On Wed, Jan 25, 2017 at 11:38 Anton Mironov via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] protocol-oriented integers (take 2)

public protocol Arithmetic { init?(exactly source: T) } public protocol BinaryInteger : Arithmetic { init?(exactly source: T) } Should the `init?(exactly:)` initializers belong

Re: [swift-evolution] protocol-oriented integers (take 2)

I can't speak to the core team's motivations, but what I'm hoping for personally is a solution to this problem: Currently, there are a bunch of protocols to which integer types conform. However, they aren't very useful (not really usable) for generic programming. One example: As an exercise, I

Re: [swift-evolution] protocol-oriented integers (take 2)

>From what I see, talking about Fields, Rings, vector spaces etc... we're >talking about modeling the standard library upon mathematic models / axioms >(particularly algebra) and using the same terminology. Those constructions allow for a more flexible approach as one would be able to 'code

Re: [swift-evolution] protocol-oriented integers (take 2)

I barely understand any of this thread, so these might be silly questions, or based on a total misunderstanding the goals here, but it seems to be about: a) clever/advanced mathsy things; b) naming things; and c) the standard library... my questions are: Do specialised clever advanced mathsy

Re: [swift-evolution] protocol-oriented integers (take 2)

on Mon Jan 16 2017, Xiaodi Wu wrote: > Strideable? I didn't think Strideable itself was going away. I'd be sad if > it did; for one, all the Unsafe*Pointers are Strideable and that has its > uses. Nobody's proposing to remove Strideable. -- -Dave

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 16, 2017, at 17:16, Xiaodi Wu wrote: > > My understanding of the goal here is to model what integers can already do, > not to give them new functions. Ah, ok. Never mind then. - Dave Sweeris ___ swift-evolution mailing

Re: [swift-evolution] protocol-oriented integers (take 2)

I don't think this is necessary for any generic algorithms. There is already quotientAndRemainder for your use for integers, and floating point division works differently. I don't think .0 works in any case. Fundamentally, your idea would turn integers into ersatz rational numbers, but one of the

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 16, 2017, at 13:40, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon wrote: >>> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> Unless

Re: [swift-evolution] protocol-oriented integers (take 2)

On Mon, Jan 16, 2017 at 2:04 PM, Dave Abrahams wrote: > > on Mon Jan 16 2017, Xiaodi Wu wrote: > > > On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon > wrote: > > > >> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution < > >>

Re: [swift-evolution] protocol-oriented integers (take 2)

On Mon, Jan 16, 2017 at 3:32 PM, Karl Wagner wrote: > > On 16 Jan 2017, at 20:53, Xiaodi Wu wrote: > > On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > >> Really glad to see this coming back :) >>

Re: [swift-evolution] protocol-oriented integers (take 2)

> On 16 Jan 2017, at 20:53, Xiaodi Wu wrote: > > On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution > > wrote: > Really glad to see this coming back :) > > I have a couple of questions: > > 1)

Re: [swift-evolution] protocol-oriented integers (take 2)

on Mon Jan 16 2017, Xiaodi Wu wrote: > On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > >> Really glad to see this coming back :) >> >> I have a couple of questions: >> >> 1) How does Strideable relate to

Re: [swift-evolution] protocol-oriented integers (take 2)

On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > Really glad to see this coming back :) > > I have a couple of questions: > > 1) How does Strideable relate to Arithmetic? > > My understanding is that Strideable allows non-numeric types to

Re: [swift-evolution] protocol-oriented integers (take 2)

on Mon Jan 16 2017, Xiaodi Wu wrote: > On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon wrote: > >> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> Unless I'm mistaken, after removing division, models of

Re: [swift-evolution] protocol-oriented integers (take 2)

On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon wrote: > On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > Unless I'm mistaken, after removing division, models of SignedArithmetic > would have the mathematical properties of a

Re: [swift-evolution] protocol-oriented integers (take 2)

Really glad to see this coming back :) I have a couple of questions: 1) How does Strideable relate to Arithmetic? My understanding is that Strideable allows non-numeric types to express different-type addition and subtraction, and that Arithmetic is for numeric types only (derives from

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution > wrote: > > Unless I'm mistaken, after removing division, models of SignedArithmetic > would have the mathematical properties of a ring. For every element a in ring > R, there must exist an additive

Re: [swift-evolution] protocol-oriented integers (take 2)

On Mon, Jan 16, 2017 at 12:44 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun Jan 15 2017, Stephen Canon wrote: > > > Responding to the thread in general here, not so much any specific email: > > > > “Arithmetic” at present is not a

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Stephen Canon wrote: > Responding to the thread in general here, not so much any specific email: > > “Arithmetic” at present is not a mathematically-precise concept, and > it may be a mistake to make it be one[1]; it’s a >

Re: [swift-evolution] protocol-oriented integers (take 2)

Sent from my moss-covered three-handled family gradunza > On Jan 15, 2017, at 6:46 PM, Jacob Bandes-Storch wrote: > >> On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution >> wrote: > >> One example: earlier, it was demonstrated that

Re: [swift-evolution] protocol-oriented integers (take 2)

Sent from my moss-covered three-handled family gradunza > On Jan 15, 2017, at 5:29 PM, Xiaodi Wu wrote: > >> On Sun, Jan 15, 2017 at 7:24 PM, Dave Abrahams wrote: >> >> on Sun Jan 15 2017, Xiaodi Wu wrote: >> >> > On Sun, Jan 15, 2017 at 6:42 PM,

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > One example: earlier, it was demonstrated that a genetic lerp would not > accommodate vector types. However, it _does_ work fine for any scalar (i.e. > field) type; however, with the currently

Re: [swift-evolution] protocol-oriented integers (take 2)

Responding to the thread in general here, not so much any specific email: “Arithmetic” at present is not a mathematically-precise concept, and it may be a mistake to make it be one[1]; it’s a mathematically-slightly-fuzzy “number” protocol. FWIW, if I had to pick a mathematical object to pin it

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 15, 2017, at 19:24, Dave Abrahams wrote: > > >> on Sun Jan 15 2017, Xiaodi Wu wrote: >> >>> On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris wrote: >>> >>> >>> >>> >>> >>> On Jan 15, 2017, at 18:02, Xiaodi Wu wrote:

Re: [swift-evolution] protocol-oriented integers (take 2)

One example: earlier, it was demonstrated that a genetic lerp would not accommodate vector types. However, it _does_ work fine for any scalar (i.e. field) type; however, with the currently proposed integer protocols, one would constrain it to Arithmetic types, yet the algorithm would be bogus for

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Xiaodi Wu wrote: > On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Sun Jan 15 2017, Xiaodi Wu wrote: >> >> > There _may_ be value in recognizing the distinction between rings and

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris wrote: > > > > Sent from my iPhone > On Jan 15, 2017, at 18:02, Xiaodi Wu wrote: > > "Mathematically correct" integers behave just like Int in that there is > not a multiplicative inverse. What we're trying

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Jacob Bandes-Storch wrote: > On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu wrote: > >> On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> [ proposal link:

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Xiaodi Wu wrote: > On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris wrote: > >> >> >> >> >> On Jan 15, 2017, at 18:02, Xiaodi Wu wrote: >> >> "Mathematically correct" integers behave just like Int in that there is >> not a

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 7:24 PM, Dave Abrahams wrote: > > on Sun Jan 15 2017, Xiaodi Wu wrote: > > > On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris > wrote: > > > >> > >> > >> > >> > >> On Jan 15, 2017, at 18:02, Xiaodi Wu wrote:

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Jacob Bandes-Storch wrote: > [ proposal link: https://gist.github.com/moiseev/ > 62ffe3c91b66866fdebf6f3fcc7cad8c ] > > On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> Responding to both Jacob and Xiaodi here;

Re: [swift-evolution] protocol-oriented integers (take 2)

Sent from my iPhone > On Jan 15, 2017, at 18:02, Xiaodi Wu wrote: > > "Mathematically correct" integers behave just like Int in that there is not a > multiplicative inverse. What we're trying to do here is to determine how much > of what we know about mathematics is

Re: [swift-evolution] protocol-oriented integers (take 2)

"Mathematically correct" integers behave just like Int in that there is not a multiplicative inverse. What we're trying to do here is to determine how much of what we know about mathematics is usefully modeled in the standard library. The answer is not zero, because there is more than just

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 15, 2017, at 17:19, Jacob Bandes-Storch via swift-evolution > wrote: > > >> On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu wrote: >>> On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution >>>

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu wrote: > On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > >> [ proposal link: https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f >> 3fcc7cad8c ] >> >> >> On Sat,

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > [ proposal link: https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f > 3fcc7cad8c ] > > > On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution < >

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun Jan 15 2017, Xiaodi Wu wrote: > > > There _may_ be value in recognizing the distinction between rings and > > fields, perhaps? Just as the FP protocols

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Xiaodi Wu wrote: > There _may_ be value in recognizing the distinction between rings and > fields, perhaps? Just as the FP protocols make room for people to implement > their own decimal FP types, and just as you're trying to make Arithmetic >

Re: [swift-evolution] protocol-oriented integers (take 2)

[ proposal link: https://gist.github.com/moiseev/ 62ffe3c91b66866fdebf6f3fcc7cad8c ] On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > Responding to both Jacob and Xiaodi here; thanks very much for your > feedback! > > on Sat Jan 14 2017,

Re: [swift-evolution] protocol-oriented integers (take 2)

You're quite right. Since the multiplicative inverse of any integer other than 1 and -1 is not itself an integer, there isn't much one can do... On Sun, Jan 15, 2017 at 08:41 Dave Abrahams wrote: > > > on Sun Jan 15 2017, Xiaodi Wu wrote: > > > > > Given that Arithmetic

Re: [swift-evolution] protocol-oriented integers (take 2)

There _may_ be value in recognizing the distinction between rings and fields, perhaps? Just as the FP protocols make room for people to implement their own decimal FP types, and just as you're trying to make Arithmetic accommodate complex numbers, the distinction would allow someone to write

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Rob Mayoff wrote: > On Sat, Jan 14, 2017 at 7:41 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> Oh... you mean that word(at:) itself would be linear, and thus >> algorithms that iterate the words linearly would be O(N^2)... yuck. >> > >

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sat, Jan 14, 2017 at 7:41 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > Oh... you mean that word(at:) itself would be linear, and thus > algorithms that iterate the words linearly would be O(N^2)... yuck. > Couldn't you fix this by replacing `func word(at n:

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Anton Zhilin wrote: > What about taking a mathematical approach to numbers? > > protocol Group : Equatable { > static var zero: Self { get } > static func + (Self, Self) -> Self > static func += (inout Self, Self) > static func -

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, David Sweeris wrote: >> On Jan 14, 2017, at 18:55, Dave Abrahams via swift-evolution >> wrote: >> >> >> Responding to both Jacob and Xiaodi here; thanks very much for your >> feedback! > >> >>> on Sat Jan 14 2017, Xiaodi Wu

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Xiaodi Wu wrote: > Given that Arithmetic also provides for multiplication and division, might > it be wise then also to have .multiplicativeIdentity (or .one)? I'm always wary of adding requirements that don't have a demonstrated use-case in a generic algorithm. What

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Nate Cook wrote: > Excited to see this getting closer! > >> On Jan 14, 2017, at 7:41 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Sat Jan 14 2017, Benjamin Spratling > >

Re: [swift-evolution] protocol-oriented integers (take 2)

What about taking a mathematical approach to numbers? protocol Group : Equatable { static var zero: Self { get } static func + (Self, Self) -> Self static func += (inout Self, Self) static func - (Self, Self) -> Self static func -= (inout Self, Self) static prefix func -

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sat Jan 14 2017, Dave Abrahams wrote: > That said, the ability to interpret integer literals as an arbitrary > Arithmetic isn't used anywhere in the standard library, so I'd like to > consider undoing >

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 14, 2017, at 18:55, Dave Abrahams via swift-evolution > wrote: > > > Responding to both Jacob and Xiaodi here; thanks very much for your > feedback! > >> on Sat Jan 14 2017, Xiaodi Wu wrote: >> >> On Sat, Jan 14, 2017 at 1:32

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 15, 2017, at 03:20, Xiaodi Wu via swift-evolution > wrote: > > Given that Arithmetic also provides for multiplication and division, might it > be wise then also to have .multiplicativeIdentity (or .one)? > >> On Sun, Jan 15, 2017 at 02:47 Dave Abrahams via

Re: [swift-evolution] protocol-oriented integers (take 2)

Given that Arithmetic also provides for multiplication and division, might it be wise then also to have .multiplicativeIdentity (or .one)? On Sun, Jan 15, 2017 at 02:47 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sat Jan 14 2017, Dave Abrahams

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 2:00 AM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > > Link: https://github.com/natecook1000/swift/blob/nc- > bigint/test/Prototypes/BigInt.swift > > This is just a proof of concept BigInt implementation—there's not much in > the way of optimization

  1   2   >