Is this a buglet? (SmallInteger>>printString related)

nicolas cellier ncellier at ifrance.com
Thu May 31 21:55:58 UTC 2007


nicolas cellier a écrit :

> For sure, (self negative or: [self isZero]) is a stupid copy paste.
> It was tailored for LargeInteger implementation for which both 
> operations are trivial.
> But when i think of it, LargeInteger < SmallInteger should be trivial too.
> I wonder which dialect might engage a costly useless arithmetic 
> operation when asked for it...
> 
> Nicolas
> 

For my defense, just gave it a try:
after defining LargePositiveInteger>>isZero ^false, i test:

| val |
val := (SmallInteger maxVal raisedTo: 4) + 1.
{Time millisecondsToRun: [100000 timesRepeat: [val < 1]].
Time millisecondsToRun: [100000 timesRepeat: [val negative or: [val 
isZero]]].
Time millisecondsToRun: [100000 timesRepeat: [val strictlyPositive not]].}
	#(457 118 106)

Hmm test < 1 is not the fastest.
Since primitive 23 seems to fail, i remove LargePositiveInteger>>#<
and i get #(399 121 113).
Then not much to gain, #digitCompare: must be half the cost, one trivial 
negative and two #< tests on small integers...

So i tried the double dispatching way:
LargePositiveInteger>>#< aNumber
	^aNumber isInteger
		ifTrue: [aNumber greaterThanLargePositiveInteger: self]
		ifFalse: [aNumber adaptToInteger: self andSend: #<]
LargePositiveInteger>>#greaterThanLargePositiveInteger: aNumber
	 ^(self digitCompare: aNumber) > 0
LargeNegativeInteger>>#greaterThanLargePositiveInteger: aNumber
	 ^false
SmallInteger>>#greaterThanLargePositiveInteger: aNumber
	 ^false

I now get    #(217 111 108).
Like for isZero and isNegative, I call two trivial methods but pay a 
penalty for intermediate #< method invocation.
(would need Exupery inlining if able to handle such polymorphic case).

I could also suppress the isInteger test and implement:
Object>>#greaterThanLargePositiveInteger: aNumber
	 ^self adaptToInteger: aNumber andSend: #<
Well  #(190 112 108) maybe does not deserve polluting Object protocol...

If you don't care, or think it's too much for such a ridiculous gain, 
then you're probably right.
Don't you optimize but in tight loops! And maybe arithmetics too...
Anyway it's fun when it can be done in Smalltalk without any additionnal 
primitive or plugin...

Nicolas




More information about the Squeak-dev mailing list