JDK 8 code review request for initial unsigned integer arithmetic library support
Joseph Darcy
joe.darcy at oracle.com
Sat Jan 21 00:35:30 UTC 2012
On 1/19/2012 8:05 AM, Ulf Zibis wrote:
> Am 19.01.2012 07:43, schrieb Eamonn McManus:
>> Ulf Zibis writes:
>> > What about:
>> > private static final BigInteger BEYOND_UNSIGNED_LONG =
>> BigInteger.valueOf(1).shiftLeft(64);
>> > private static BigInteger toUnsignedBigInteger(long i) {
>> > BigInteger result = BigInteger.valueOf(i);
>> > if (i < 0L)
>> > result = result.add(BEYOND_UNSIGNED_LONG);
>> > return result;
>> > }
>>
>> That's a nice idea! But the problem is that it would mean that
>> BigInteger.class would be loaded as soon as Long.class is, which I
>> think is undesirable.
> Thanks for the critic. I didn't see that.
> The problem could be easily avoided if method
> toUnsignedBigInteger(long i) would be moved to class BigInteger as
> unsignedValueOf(long i), as I additionally noted in my last post.
>
>> However it does make me think that we could change...to this:
>>
>> if (i >= 0L) {
>> return BigInteger.valueOf(i);
>> } else {
>> return BigInteger.valueOf(i & Long.MAX_VALUE).setBit(63);
>> }
> Another nice idea!
> But again, moving the entire method to BigInteger would additionally
> avoid to clown around with the available BigInteger's public APIs.
> Having the method at BigInteger would allow elegant direct access to
> the private value fields.
>
>
If the operation in question starts becoming a bottleneck, these
alternate implementations can be explored. In the meantime, I plan to
stick with the straightforward code and not setup the infrastructure
needed to get at BigInteger internals.
Thanks,
-Joe
More information about the core-libs-dev
mailing list