Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 03 Sep 2011 14:37:41 -0500
Date: Sat, 03 Sep 2011 12:37:10 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer
Subject: Re: BitSet vs BigInteger (false Android doc)
References: <j3rbtv$d5g$1@news.albasani.net> <4e613b65$0$311$14726298@news.sunsite.dk> <yJCdnamwfpVooPzTnZ2dnUVZ_umdnZ2d@earthlink.com> <j3rflb$lh6$2@news.albasani.net> <KOmdnWyhfYV_FPzTnZ2dnUVZ_s-dnZ2d@earthlink.com> <j3tqr7$vp8$1@news.albasani.net>
In-Reply-To: <j3tqr7$vp8$1@news.albasani.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <_ZGdna1ucfWYH__TnZ2dnUVZ_oudnZ2d@earthlink.com>
Lines: 56
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 70.230.204.158
X-Trace: sv3-5EBlWMSctg5WWGoAd7mdkkHzUHsClwSrLQd32PoJQziwYdjf0ij/nnw0683wCzngaaJCGI9yJAhlJvL!tI2pMXTRXvu35KPmQib5GTCBgawBdH90XNNTJeYua9MvSlkKSlTI408nBtp6t387pKRzjUMK7LVX!sLfHkY0+3o36CkI67bcSOhJ09qR0FtC4Vi4ni3hZkk1Hiog=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3558
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7552

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