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)

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)