possiblt bug in #lowBit and #highBit
David Hopwood
david.nospam.hopwood at blueyonder.co.uk
Fri Jan 7 13:30:40 PST 2005
Douglas Brebner wrote:
> I'm writing some bit manipulation code and think I've found a bug in
> #lowBit and #highBit (from numeric.slate and integer.slate)
>
> It appears that these methods don't handle the case of the integer = 0
>
> Slate 69> 0 lowBit.
> 0
> Slate 70> 1 lowBit.
> 0
> Slate 71> 2 lowBit.
> 1
> Slate 72> 4 lowBit.
> 2
>
> and the same for highBit.
>
> Any suggestions as to how they should handle this case?
When n is positive, 'n highBit = k' means that k is the smallest
integer such that 2^(k+1) > n.
This definition would make 'n highBit' undefined when n <= 0, since
there is no such smallest integer. However, -infinity would also
be consistent for '0 highBit' (there are infinitely many zeroes
to the right of the binary point).
When n is positive, 'n lowBit = k' means that k is the largest
integer such that n / 2^k is an integer.
This definition would also make 'n lowBit' undefined when n = 0,
since there is no such largest integer. However, +infinity would
also be consistent for '0 lowBit' (there are infinitely many
zeroes to the left of the binary point).
Note that the definition for 'n lowBit' above makes sense when
n is negative, and both definitions also make sense (and are
useful) for non-integers.
--
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the Slate
mailing list