Re: BitSet vs BigInteger (false Android doc)
Jan Burse wrote:
Arne Vajh=F8j 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, sign-plus-
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 componen=
t 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 c=
leared. One _BitSet_ may be used to modify the contents of another _BitSet_=
through logical AND, logical inclusive OR, and logical exclusive OR operat=
ions.
By default, all bits in the set initially have the value _false_."
As you must be aware, booleans and integers are distinct and incompatible t=
ypes, 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 sign-magnitude, 1s- or 2s-complement, sign, sign extension,=
and negative and positive values are all equally meaningless and completel=
y irrelevant for BitSet.
=00
Also, BitSet does indeed have a "not" operation, which it calls 'flip()'.
=00
Furthermore, from the remark that "[t]he length of a bit set relates to log=
ical length of a bit set and is defined independently of implementation", w=
e conclude that the implementation doesn't matter as long as it meets the c=
ontract.
- BigInteger is also not dependent for positive values on some
two's complement, sign-plus-maginitude 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 menti=
on of any of the aforementioned irrelevant concepts pertaining to integer t=
ypes.
Are you referring to Android's documentation for BigInteger, which states, =
"This API includes operations for bitwise operations in two's complement [s=
ic] representation. Two's complement is not the internal representation use=
d by this implementation, so such methods may be inefficient. Use _BitSet_ =
for high-performance bitwise operations on arbitrarily-large sequences of b=
its."?
How is that false? It's obviously factual and correct. The BigInteger API=
does include operations for two's-complement bitwise operations, no? Two'=
s complement is not the internal representation of BigInteger in Android, i=
s it? Such methods are likely to be inefficient, aren't they? So what's f=
alse?
As for relevance, it's rather important in an Android context to be aware o=
f performance considerations, so the need for speed in bitwise operations m=
akes relevant the comment. Clearly.
What's irrelevant is trying to speak of BitSet as if it were an integral ty=
pe. This is not a mistake the Android Javadocs make. Let's see, now - whe=
re did I see that error? I wonder ...
Oh, yeah, the remark, "BitSet and BigInteger are the same on the common dom=
ain of positive integers."
--
Lew