> > - 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 > over Arithmetic? >
E.g. generic point/size/rect types. > 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 I think, not sure if that's for performance reasons or merely convenience though. On Fri, Jun 24, 2016 at 7:40 AM, Jordan Rose via swift-evolution < [email protected]> wrote: > 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"? (Some of the requirements are at odds with a decimal-based > implementation.) > > Jordan > > > On Jun 23, 2016, at 13:50, Jordan Rose <[email protected]> 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 about why we didn't include this still seem relevant. To > phrase it in generic programming terms, what algorithm would be generic > over Arithmetic? > > > - What is Integer.init<T: FloatingPoint>(_:) supposed to do if the > floating-point value is larger than the maximum representable integer? > Smaller than the minimum? (As a special case, negative, when the integer > type is unsigned?) Infinity? NaN? > > - Integer.init<T: Integer>(_:) currently says "if it is representable". It > should say something like "trapping if it is not representable". > > - I find it odd that Integer.init(clamping:) privileges the bounds of > fixed-width integers. I was going to suggest it should take a range to > clamp to that *defaults* to the min and max, but that's not implementable > for a BigInt. > > - nthWord should count "from least-significant to most-significant" rather > than "from the right". > > - As mentioned before, it sounds like Integer requires a two's complement > representation (if only so the result of nthWord can be interpreted > correctly). That should probably be in the doc comment for the protocol. > > - Why is bitWidth in bits but nthWord in words? (I know there's a good > answer to this, but using them together seems like it will be common.) > > - It's also probably worth calling out *even more explicitly* that > bitWidth is a *representation* property, not a *value* property. That is, > a BigInt with the value "1" could have a bitWidth of 1, 8, or 128. > > - What does signBitIndex return if self is positive? I ask because it's > just not in the doc comment, but thinking about the answer made it obvious > that the correct return value for 0 is 0. > > - For signed integers, does remainder(dividingBy:) have specified behavior > for the sign of the result? See > https://en.wikipedia.org/wiki/Modulo_operation. > > - I do think having Swift.abs(_:) and Integer.absoluteValue is confusing, > but I don't know what to do about it. > > > - Why are bitwise operations limited to fixed-width integers? I see "The > only difference is that because shifting left truncates the high bits of > fixed-width integers, it is hard to define what a left shift would mean to > an arbitrary-precision integer" further down, but I would just assume it > wouldn't truncate (i.e. it would be a pure multiplication by two). > > - Is there a requirement about left-shifting into the sign bit, for '<<' > and for '&<<'? > > - What is the ArithmeticOverflow type? > > - When does the remainder operation overflow? (I just can't remember.) > > - I feel a little weird having "someValue.and(mask)". Maybe bitwiseAnd or > bitwiseAND to be more explicit? > > - maskingShiftLeft/Right seem underspecified in their doc comments. Why > can't the protocol requirement just assume the shift amount has already > been masked, instead of performing the masking themselves? Is it because we > won't be able to optimize that away? > > I think that's about it. Great work, all! > Jordan > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
