<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><span class="im" style="font-size: 13px;">> For Integer, does the presence of signBit indicate an expectation that signed Integers will have a two's complement representation?<br class=""></span><span class="" style="font-size: 13px;">Yes. That is correct.</span></blockquote><div class=""><br class=""></div><div class="">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.</div></div></blockquote></div><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">This is a very valid concern. I think I have <strike class="">discovered a truly marvelous solution</strike> a way of addressing it:</div><div class=""><br class=""></div><div class="">`signBitIndex` is only used (I’m talking about the prototype now) to determine the absolute required minimum of bits needed to represent the current value of number when converting it to a different type.</div><div class=""><br class=""></div><div class="">So, instead of mentioning the sign bit, let’s call it what it is ‘minimumRequiredWidth’ or something along this line. This move will also allow the default implementation of `minimumRequiredWidth` to simply return `bitWidth` for unsigned numbers and and `bitWidth - 1` for positive signed, etc.</div><div class=""><br class=""></div><div class="">This way bignum implementations don’t have to have any specific underlying representation. They can either inherit the default implementation or implement their own version of `minimumRequiredWidth` in case the `bitWidth` has some extra unused space that is not absolutely required.</div><div class=""><br class=""></div><div class="">I still need to validate this idea, these are just the thoughts. Any comments are more than welcome.</div><div class=""><br class=""></div><div class="">Max</div></div></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 3:19 PM, Patrick Pijnappel <<a href="mailto:patrickpijnappel@gmail.com" class="">patrickpijnappel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:13px" class="">- 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?</div></blockquote><div class=""><br class=""></div><div class="">E.g. generic point/size/rect types.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:13px">> For Integer, does the presence of signBit indicate an expectation that signed Integers will have a two's complement representation?<br class=""></span><span style="font-size:13px" class="">Yes. That is correct.</span></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 24, 2016 at 7:40 AM, Jordan Rose via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.)</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><div class="h5"><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 13:50, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class="">Hey, standard library folks. Glad we're doing this one. :-)<div class=""><br class=""></div><div class="">- 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?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">- 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?</div><div class=""><br class=""></div><div class="">- Integer.init<T: Integer>(_:) currently says "if it is representable". It should say something like "trapping if it is not representable".</div><div class=""><br class=""></div><div class="">- 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 <i class="">defaults</i> to the min and max, but that's not implementable for a BigInt.</div><div class=""><br class=""></div><div class="">- nthWord should count "from least-significant to most-significant" rather than "from the right".</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">- 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.)</div><div class=""><br class=""></div><div class="">- It's also probably worth calling out <i class="">even more explicitly</i> that bitWidth is a <i class="">representation</i> property, not a <i class="">value</i> property. That is, a BigInt with the value "1" could have a bitWidth of 1, 8, or 128.</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">- For signed integers, does remainder(dividingBy:) have specified behavior for the sign of the result? See <a href="https://en.wikipedia.org/wiki/Modulo_operation" target="_blank" class="">https://en.wikipedia.org/wiki/Modulo_operation</a>.</div><div class=""><br class=""></div><div class=""><div class="">- I do think having Swift.abs(_:) and Integer.absoluteValue is confusing, but I don't know what to do about it.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">- 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).</div><div class=""><br class=""></div><div class="">- Is there a requirement about left-shifting into the sign bit, for '<<' and for '&<<'?</div><div class=""><div class=""><br class=""></div><div class="">- What is the ArithmeticOverflow type?</div><div class=""><br class=""></div><div class="">- When does the remainder operation overflow? (I just can't remember.)</div><div class=""><br class=""></div><div class="">- I feel a little weird having "someValue.and(mask)". Maybe bitwiseAnd or bitwiseAND to be more explicit?</div><div class=""><br class=""></div></div><div class="">- 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?</div><div class=""><br class=""></div><div class="">I think that's about it. Great work, all!</div><div class="">Jordan</div></div></div></blockquote></div><br class=""></div></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>