Re: [squeak-dev] What should Integer>>digitCompare: return?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] What should Integer>>digitCompare: return?

Levente Uzonyi
 
On Mon, 29 Oct 2018, Eliot Miranda wrote:

> Hi Chris,
>
>> On Oct 28, 2018, at 3:41 PM, Chris Cunningham <[hidden email]> 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)
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] What should Integer>>digitCompare: return?

Eliot Miranda-2
 
Hi Levente,

On Mon, Oct 29, 2018 at 12:08 PM Levente Uzonyi <[hidden email]> wrote:
 On Mon, 29 Oct 2018, Eliot Miranda wrote:

> Hi Chris,
>
>> On Oct 28, 2018, at 3:41 PM, Chris Cunningham <[hidden email]> 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.

Right. The comment states: "Ensure that consecutive sends of this method return increasing values, by adding small values to the nanosecond part of the created object. The next few lines are assumed to be executed atomically - having no suspension points.".  Clever, Bert!