On Mon, 29 Oct 2018, Eliot Miranda 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)
>
> 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.

I think DateAndTime >> #now:offset:'s comment gives a very good reason why 
#digitCompare: is used there. It doesn't go into details though.

Levente

>
> _,,,^..^,,,_ (phone)