2008/12/2 John M McIntosh
<johnmci@smalltalkconsulting.com>
Eliot thanks for this. I went with
(negative and: [value = (1<<31)])
ifTrue: [^value].
But value doesn't equal 1 << 31. It equals -(1 << 31). It only appears to equal 1 << 31 because 1 << 31 overflows. I think therefore mine is clearer.
Think about it, all less negative values must still be negative when one subtracts one. Only the most negative value will no longer be negative if one subtracts one. So I think mine also clearly selects the most negative value and only the most negative value.
I've attached the analogous fix for signed64BitValueOf:
versus
(negative and: [value - 1 > 0])
ifTrue: [^value].
I had hardcoded -2147483648 but got some ansi 99 compiler warning so I did the shift, I'd *think* the compiler will do the 1<<31 constant resolving
and use the final value so we only have the compare, versus a subtraction and compare. Not that you could measure any performance differences
The problem is that 1<<31 is a large constant whereas -1 is small. So the cost is not really in the arithmetic but in the memory fetch :) I bet there will be more bytes in the instructions for 1 << 31 than for the - 1 on most architectures. On the ARM 1<<31 is cheap, but TTBOMK only on ARM :)
In the Alien Sunits I cover the cases of 0 4294967295 -2147483648 2147483647 (for signed/unsigned)
then do random sampling (10,000) elements of
unsignedIntegerIntervalue := (0 to: 4294967295).
signedIntegerIntervalue := (-2147483648 to: 2147483647).
signedIntegerIntervalue := (-4294967295 to: -2147483649). should prim value
signedIntegerIntervalue := (2147483648 to: 4294967295). should prim fail
If someone wants to try they could run *all* the values from -0xFFFFFFFF 0xFFFFFFFF just to confirm *every* value works as expected since that would
only take a few hours or less on the fast machines today.
I note I do the 0xFFFFFFFF * (-1) because it's possible someone might pass that in and ask for a signed integer, in that case we of course fail until we
reach the lowest 32bit signed integer value of -2147483648 (I so I assume) since I've not run the entire range, which is feasible.
Obviously running the 64bit range could take a while. Anyone want to estimate?
On 2-Dec-08, at 11:32 AM, Eliot Miranda wrote:
Hi John,
here's the fix for signed32BitValueOf:
On Tue, Nov 25, 2008 at 11:15 PM, John M McIntosh <johnmci@smalltalkconsulting.com> wrote: