[Vm-dev] slip in LargeIntegers >> normalizePositive:

[Nicolas Cellier]

I'm trying to understand the negative case...

We have the magnitude on one side xMag
We minSmallInteger in two complement on the other side yTC
We know that the magnitude of minSmallInteger is yMag=bitInvert(yTC)+1
We know that all bytes of yTC are 0 but the MSB
Thus all bytes of bitInvert(yTC) are 16rFF
Thus all bytes of yMag are 0, but the highest which is (MSB(yTC) xOr: 256)
+ 1.

Thus, assuming same byte length:
MSB(xMag) < MSB(yMag) => x is a CSI
MSB(xMag) > MSB(yMag) => x is large
MSB(xMag) = MSB(yMag) => we must inquire the LSBs of xMag..
(1 to: len-1) anySatisfy: [:i | (xMag digitAt: i) ~= 0] => x isLarge
otherwise, x is minSmallInteger

Eliot, I fail to see the bitInvert(MSB(minSmallInteger))+1 in your code...
Did I miss something?

Nicolas

2015-03-06 0:37 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
> Hi Nicolas,
>
>    I found my misunderstanding.  Can you review this version instead?
>
>
>
> On Thu, Mar 5, 2015 at 11:41 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>> Hi Nicolas,
>>
>>      would you mind also reviewing the attached changes?  There's a bug
>> in them somewhere, although I think they're close to correct.  The ideas
>> here are to
>>
>> - avoid calling firstIndexableField: on every call to unsafeByteOf:at: in
>> isNormalized:, normalizePositive: and normalizeNegative:.  Do this by
>> cacheing firstIndexableField in a local pointer variable
>> - move the bounds check in cDigitOfCSI:at: out to clients that aren't
>> invoking cDigitOfCSI:at: with in-bounds indices
>> - avoid the immediate test in digitLengthOf: when it is known that the
>> object is non-immediate.  Do so by adding digitLengthOfNonImmediate:.
>>
>> Of course this approach can be extended to other LargeIntegers methods,
>> but one step at a time :-/
>>
>> On Wed, Mar 4, 2015 at 2:49 PM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>>
>>>
>>> sLen := interpreterProxy minSmallInteger > 16r3FFFFFFF
>>>
>>> sounds like a copy/paste error
>>> I would expect maxSmallInteger here.
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>
>
> --
> best,
> Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150306/4e5830a4/attachment-0001.htm