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
