Re: BitSet vs BigInteger (false Android doc)
On 9/3/2011 11:15 AM, Jan Burse wrote:
Patricia Shanahan schrieb:
On 9/2/2011 1:51 PM, Jan Burse wrote:
Patricia Shanahan schrieb:
Also, they have more freedom of action in implementing BitSet
True, actually I was expecting to see a more clever BitSet,
but in JDK 1.6.0_26 its just this long array.
Are you looking at the actual Android implementations for the classes?
Patricia
I don't think that Android uses some special BitSet resp. BigInteger,
since then classes are java.*.
That just means that they must support exactly the interface specified
in the API documentation.
But it looks that nevertheless the implementation in JDK and Android are
not verbatim the same:
Here is the Android BitSet XOR:
....
http://www.java2s.com/Open-Source/Android/android-core/platform-libcore/java/util/BitSet.java.htm
Thanks for the link. I found their BigInteger implementation at
http://www.java2s.com/Open-Source/Android/android-core/platform-libcore/java/math/BigInteger.java.htm
It uses a NativeBN implementation, which appears from various comments
and fields to be sign-and-magnitude based, not 2's complement. The bit
manipulation methods use a method prepareJavaRepresentation that I think
converts to 2's complement.
It is definitely not the implementation in the normal JDK, so any
arguments based on how it is coded, or on the internal representation it
uses, are inapplicable to the Andriod implementation.
It does appear to be consistent with the comment you quoted in the first
message of this thread:
Slow Two's Complement Bitwise Operations
This API includes operations for bitwise operations
in two's complement representation. Two's complement
is not the internal representation used by this
implementation, so such methods may be inefficient.
Use BitSet for high-performance bitwise operations
on arbitrarily-large sequences of bits.
On something like this, I would be inclined to believe the developers,
and follow their advice. I certainly don't see any reason to assume the
documentation is false.
Patricia