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

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

on Sat Jan 14 2017, Benjamin Spratling wrote: > I notice the BinaryInteger's func word(at n: Int) -> UInt function > expects a 2's complement representation. Do you expect that "BigInt" > will be implemented with 2's complement? Ah, this is an excellent question, excellently phrased! We des

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

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 AM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > >> Great work, all. I'm not sure I ever commented on SE-0104, so

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

on Fri Jan 13 2017, Max Moiseev wrote: > So, in an expression `x &>> 32`, compiler assumes 32 to have type Int > (which is the default type for the integer literals) and prefer the > heterogeneous overload. It might not be too bad, as I showed in > examples above, but in order to increase chance

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

on Sat Jan 14 2017, Xiaodi Wu wrote: > On Fri, Jan 13, 2017 at 7:51 PM, Xiaodi Wu > wrote: > >> Thanks, that's very helpful. Yes, my question was more directed to those >> situations that can't be optimized away. It's good to know that the maximum >> total cost is an and and a shift, which is w

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

> On Jan 14, 2017, at 11:18 AM, Xiaodi Wu wrote: > > On Fri, Jan 13, 2017 at 7:51 PM, Xiaodi Wu > wrote: > Thanks, that's very helpful. Yes, my question was more directed to those > situations that can't be optimized away. It's good to know that the maximum > total

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

On Fri, Jan 13, 2017 at 7:51 PM, Xiaodi Wu wrote: > Thanks, that's very helpful. Yes, my question was more directed to those > situations that can't be optimized away. It's good to know that the maximum > total cost is an and and a shift, which is what it sounded like but wasn't > made explicit.

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

On Sat, Jan 14, 2017 at 1:32 AM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > Great work, all. I'm not sure I ever commented on SE-0104, so I've read > through this one more carefully. Here are some things that came to mind: > > *## Arithmetic* > > Why are Expressi

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

I notice the BinaryInteger's func word(at n: Int) -> UInt function expects a 2's complement representation. Do you expect that "BigInt" will be implemented with 2's complement? As a nonmutating function, I would think any implementation from a 1's complement big int would result in O(n^2) unl

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

+1 Any change of including “ranged integers”? I.e. an integer with a value that must fit in a predefined range? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 13 Jan 2017, at 21:47, Max Moi

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

Great work, all. I'm not sure I ever commented on SE-0104, so I've read through this one more carefully. Here are some things that came to mind: *## Arithmetic* Why are ExpressibleByIntegerLiteral and init?(exactly:) required? I could understand needing access to 0, but this could be provided by

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

Thanks, that's very helpful. Yes, my question was more directed to those situations that can't be optimized away. It's good to know that the maximum total cost is an and and a shift, which is what it sounded like but wasn't made explicit. On Fri, Jan 13, 2017 at 17:25 Stephen Canon wrote: > > On

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

> On Jan 13, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution > wrote: > > [Resending to list with original message removed for length.] > > This is fantastic. Glad to see it take shape. Very neat and insightful to > have trailingZeros on BinaryInteger but leadingZeros on FixedWidthInteger. A

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

Hi Xiaodi, > What is the performance penalty as compared to the existing operators? First of all, I don’t have the concrete numbers unfortunately. But… If we are talking about concrete types, there should be very little difference between the two smart and masking shifts. For example, the follo

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

[Resending to list with original message removed for length.] This is fantastic. Glad to see it take shape. Very neat and insightful to have trailingZeros on BinaryInteger but leadingZeros on FixedWidthInteger. A couple of questions on smart shifts: What is the performance penalty as compared to t

<    1   2