On Mon, 29 Oct 2018, Eliot Miranda wrote:
Hi Chris,
On Oct 28, 2018, at 3:41 PM, Chris Cunningham cunningham.cb@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)