Richard,
	I'm not arguing that popCount shouldn't emit an error. The latest 
change set does so. Thanks for pointing out the comments about negative 
integers and infinite numbers of bits. I think the last message was 
more about the problems with having small integers be two's complement 
and large integers be one's complement. I think this is a good example 
of where semantics diverge from implementation. Semantically, we can 
think of ones or twos complement negative integers as having an 
infinite number of one's bits in the higher order bits. In the same way 
we can consider positive integers having an infinite number of zero's 
in front of the high bit. But we also know that real implementations 
won't store the infinite numbers of high order bits. But at the end of 
the day, I don't think there's any significance in popCounts for 
negative numbers (though I also like your suggestion of returning the 
number of zero bits set in a negative number.)
	This discussion also gets back to the philosophical question of should 
an environment raise an exception/error if it's given bad inputs or 
should it quietly chug on doing something  that's unlikely to be 
correct, but will not stop the flow of a task. Smalltalk being an 
interactive environment certainly leans towards the "tell the user 
something bad has happened" camp. Ergo, I agree that the best course of 
action is probably to have popCount do the same thing that highBit 
does. And I agree that highBit for SmallInteger and Integer and 
popCount for Integer should raise a remarkably similar error. Attached 
are a pair of change-sets for Integer and LargeNegativeInteger that 
change the error message raised.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Integer.msh.4.cs
Type: application/octet-stream
Size: 484 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20041210/9596903f/Integer.msh.4.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LargeNegativeInteger.msh.1.cs
Type: application/octet-stream
Size: 593 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20041210/9596903f/LargeNegativeInteger.msh.1.obj
-------------- next part --------------



On Dec 9, 2004, at 10:20 PM, Richard A. O'Keefe wrote:

> Squeak 3.6
>
> Integer>>highBit
>     "... Raise an error if the receiver is negative, since
>      negative integers are defined to have an infinite number
>      of leading 1's in 2's complement arithmetic. ..."
>
> SmallInteger>>highBit
>     " ... same comment ... "
>     self < 0 ifTrue: [^self error:
> 		      'highBit is not defined for negative integers'].
>     ^self highBitOfPositiveReceiver
>
> LargeNegativeInteger>>highBit
>     " ... same comment ... "
>     self shouldNotImplement
>
> although I think that it would be better to make 
> LargeNegativeInteger>>highBit
> raise the same error as SmallInteger>>highBit.
>
> So here is precedent for
> (1) me saying that -1 has infinitely many 1s
> (2) my suggestion that Integer>>popCount be an error for a negative 
> receiver.
>
> One would expect Squeak's bitwise operations on integers of all sizes 
> to
> be compatible with Common Lisp's, where they worked out the rules very
> carefully.
>
>