Integer>even Fast but Integer>odd Slow?

[pepe4321]

Hi.
Since Vast 6.0.4 the implementation of Integer>>even changed from this:
Integer>>even

"Answer a Boolean, true if the
receiver is an even number;
answer false otherwise. Even means divisible
by 2 with no remainder."

^(self rem: 2 ) = 0

to this:
Integer>>even

"Answer a Boolean true if the receiver is an even number;
answer false otherwise. Even means divisible by 2 with
no remainder."

^(self bitAnd: 1) ~= 0

But not the implementation of Integer>>odd, which is this:
Integer>>odd

"Answer a Boolean indicating true if
the receiver is an odd number; answer
false otherwise. Odd is defined as
divisable by 2 with a non-zero remainder."

^(self rem: 2 ) ~= 0

Is there any reason for it?

Thanks,
JP

[wembley]

I suppose it was an oversight by whoever made Integer>>#even run faster -- let's see, that was me

Anyway, a similar change will be made to Integer>>#odd.

Case 42456 opened -- fixed in V8.0.1.

[koschate]

Maybe it's naive of me, but I would have expected #odd to have been implemented as

odd
^self even not

both for obviousness and DRY principles. In terms of performance, I don't think there's a hit, and this would have avoided the problem.

[wembley]

Maybe it's naive of me, but I would have expected #odd to have been implemented as

odd
^self even not

both for obviousness and DRY principles. In terms of performance, I don't think there's a hit, and this would have avoided the problem.

It actually makes a big difference:

100,000,000 loops of self even not takes 3.930 seconds on my VMware Ubuntu machine

100,000,000 loops of (self bitAnd: 1) == 1 takes 2.784 seconds on the same machine

In very small methods, one extra message send can make a big difference -- I suppose that is why the methods weren't implemented in terms of themselves in the first place.