Jan Burse wrote:
> Arne Vajhøj schrieb:
>> The BigInteger API has methods for converting between internal
>> representation and bytes in two complements. It should be obvious
>> that at least code that uses that feature will carry overhead
>> for an implementation not using two;s complement.
>
> No, the point is that this light handed reasoning does not
> work. Namely because:
>
>  BitSet is not dependent on some two's complement, signplus
> magnitude or one's complement etc.., since these representations
> were invented for negative values. And BitSet does not work
> with an infinitely extended sign bit, which corresponds to
> a negative value. It has no not() operation.
BitSet doesn't represent integer values at all. According to its Javadoc:
"This class implements a vector of bits that grows as needed. Each component of the bit set has a _boolean_ value. The bits of a _BitSet_ are indexed by nonnegative integers. Individual indexed bits can be examined, set, or cleared. One _BitSet_ may be used to modify the contents of another _BitSet_through logical AND, logical inclusive OR, and logical exclusive OR operations.
By default, all bits in the set initially have the value _false_."
As you must be aware, booleans and integers are distinct and incompatible types, never mind vectors of booleans. From the Javadocs it is quite clear that BitSet is not intended to represent any kind of arithmetic type.
The concepts of signmagnitude, 1s or 2scomplement, sign, sign extension,and negative and positive values are all equally meaningless and completely irrelevant for BitSet.
\0
Also, BitSet does indeed have a "not" operation, which it calls 'flip()'.
\0
Furthermore, from the remark that "[t]he length of a bit set relates to logical length of a bit set and is defined independently of implementation", we conclude that the implementation doesn't matter as long as it meets the contract.
>  BigInteger is also not dependent for positive values on some
> two's complement, signplusmaginitude or one's complement etc..,
> since these presentation were invented for negative values.
>
> So the Android javadoc [sic] comment is false in that it mentions an
> irrelevant aspect of the matter.
Of which comment do you speak? Android's Javadocs for BitSet make no mention of any of the aforementioned irrelevant concepts pertaining to integer types.
Are you referring to Android's documentation for BigInteger, which states, "This API includes operations for bitwise operations in two's complement [sic] representation. Two's complement is not the internal representation used by this implementation, so such methods may be inefficient. Use _BitSet_ for highperformance bitwise operations on arbitrarilylarge sequences of bits."?
How is that false? It's obviously factual and correct. The BigInteger APIdoes include operations for two'scomplement bitwise operations, no? Two's complement is not the internal representation of BigInteger in Android, is it? Such methods are likely to be inefficient, aren't they? So what's false?
As for relevance, it's rather important in an Android context to be aware of performance considerations, so the need for speed in bitwise operations makes relevant the comment. Clearly.
What's irrelevant is trying to speak of BitSet as if it were an integral type. This is not a mistake the Android Javadocs make. Let's see, now  where did I see that error? I wonder ...
Oh, yeah, the remark, "BitSet and BigInteger are the same on the common domain of positive integers."

Lew
