Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

Okay, well, I'm +1 on this. I like that we got rid of conversions from/to U/IntMax in favor of more general initializers and the bitshift enhancements. I think that most generic algorithms on integers will get simpler. I'm not overly concerned/competent with floating-point numbers, but I'm sure

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 8:47 PM, Félix Cloutier wrote: > > Thanks for answering my questions earlier. I like a lot of the changes. > > Speaking of heterogeneous comparisons again, though, how are comparisons of > negative signed integers with unsigned integers handled? It is in the prototype: h

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 22:47, Félix Cloutier via swift-evolution > wrote: > > Thanks for answering my questions earlier. I like a lot of the changes. > > Speaking of heterogeneous comparisons again, though, how are comparisons of > negative signed integers with unsigned integers handled? > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

Thanks for answering my questions earlier. I like a lot of the changes. Speaking of heterogeneous comparisons again, though, how are comparisons of negative signed integers with unsigned integers handled? Félix > Le 23 juin 2016 à 17:36:14, Max Moiseev via swift-evolution > a écrit : > >> >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

> > For Integer, does the presence of signBit indicate an expectation that > > signed Integers will have a two's complement representation? > Yes. That is correct. > > So would this require a BigInt implementation to be in two's complement also? > Most BigInt implementations use a separate sign

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 15:35, Max Moiseev wrote: > > Hi Jordan, > >> On Jun 23, 2016, at 1:50 PM, Jordan Rose > > wrote: >> >> Hey, standard library folks. Glad we're doing this one. :-) >> >> - I remain unconvinced that defining an Arithmetic that includes both e

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

Hi Jordan, > On Jun 23, 2016, at 1:50 PM, Jordan Rose wrote: > > Hey, standard library folks. Glad we're doing this one. :-) > > - I remain unconvinced that defining an Arithmetic that includes both exact > and floating-point numbers is a good idea. All of the arguments from Swift 1 > and 2 a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 15:19, Patrick Pijnappel > wrote: > > - I remain unconvinced that defining an Arithmetic that includes both exact > and floating-point numbers is a good idea. All of the arguments from Swift 1 > and 2 about why we didn't include this still seem relevant. To phrase it in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

> > - I remain unconvinced that defining an Arithmetic that includes both > exact and floating-point numbers is a good idea. All of the arguments from > Swift 1 and 2 about why we didn't include this still seem relevant. To > phrase it in generic programming terms, what algorithm would be generic >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

Oh, one more comment: I suggest naming the primary protocol something other than "Integer", which IMHO is a little close to "Int" for a beginner. "Integral" is a bit too ambiguous, but maybe "IntegerArithmetic" or "ArithmeticInteger"? Or to go with the representation thing, "BinaryInteger"? (So

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

Hey, standard library folks. Glad we're doing this one. :-) - I remain unconvinced that defining an Arithmetic that includes both exact and floating-point numbers is a good idea. All of the arguments from Swift 1 and 2 about why we didn't include this still seem relevant. To phrase it in generic