> On Oct 29, 2018, at 11:46 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Hi Chris,
> 
>> On Oct 28, 2018, at 3:41 PM, Chris Cunningham <cunningham.cb at gmail.com> wrote:
>> 
>> Looking at LargeIntegers (I'm 64 bit, so these are big):
>> {
>> 1152921504606846977 digitCompare:  -1152921504606846977.
>> 1152921504606846977 digitCompare:  -1152921504606846978.
>> 1152921504606846978 digitCompare:  -1152921504606846977.
>> }  "#(0 -1 1)"
>> 
>> {
>> 1249 digitCompare: -1249.
>> 1249 digitCompare: -1250.
>> 1250 digitCompare: -1249.
>> } #(1 1 1)
> 
> this is correct.  The primitive is supposed to answer -1, 0 or 1 depending on whether the (receiver digitAt: n) is <, =, or > the (argument digitAt: n) where n is either the first digit at which the receiver and argument differ or the last digit.  Since digitAt: does not answer the 2’s complement bit-anded SmallIntegers are not actually inconsistent
> 
> -1 digitAt: 1 => 1
> -1 digitAt: 2 => 0
> 1 digitAt: 1 => 1
> 1 digitAt: 2 => 0
> 
> SmallInteger minVal - 1 digitAt: Smalltalk wordSize => 16 (64-bits) 64 (32-bits)
> SmallInteger maxVal + 1 digitAt: Smalltalk wordSize => 16 (64-bits) 64 (32-bits)

or more clearly:

(SmallInteger minVal digitCompare: SmallInteger maxVal + 1) = 0

As the comment says, digitCompare: compares the magnitudes, not the 2’s complement representations.

> 
> So the method needs a) a really good comment and b) a warning that this is private to the Integer hierarchy implementation and not for general use.
> 
> It looks to me like the use in DateAndTime is a hack that works because LastClockValue is always +ve.
> 
> _,,,^..^,,,_ (phone)