CODEWITHSUNDEEP
java
mekings
mekings

Reputation: 456

Reducing a long to an integer in java via bit shifting

My use case is this,

I wish to reduce an extremely long number like 97173329791011L to a smaller integer by shifting down and be able to get back the long number 97173329791011L from the smaller integer by shifting up .I have implemented a function called reduceLong to implement this as shown below

private int reduceLong(long reduceable) {
        return (int) (reduceable >> 32);
    }

However, I feel the function I have is in a way wrong as the result produced is incorrect. Here is the result from my console output when trying to reduce 97173329791011L to a smaller integer

Trying to reduce 97173329791011L
Result= 0

Your help would be greatly appreciated. Thanks alot.

Upvotes: 0

Views: 503

Answers (2)

rzwitserloot
rzwitserloot

Reputation: 103883

The int datatype can hold all integral values in the range [-2^31, +2^31-1], inclusive. That's, in decimal, [-2147483648, 2147483647]. The total range covers 2^32 different numbers, and that makes sense because ints are 32 bits in memory. Just like you can't store an elephant in a matchbox, you can't store an infinite amount of data in 32 bits worth of data. You can store at most... 32 bits worth of data.

3706111600L is a long; it is (slightly) outside of the range of the int. In binary, it is:

11011100111001101100011001110000

How do you propose to store these 64 bits into a mere 32 bits? There is no general strategy here, and that is mathematically impossible to have: You can store exactly 2^64 different numbers in a long, and that's more unique values than 2^32, so whatever 'compression' algorithm you suggest, it cannot work except for at most 2^32 unique long values, which is only a very small number of them.

Separate from that, running your snippet: first, you do 11011100111001101100011001110000 >> 32, which gets rid of all of the bits. (there are exactly 32 bits there), hence why you get 0.

Perhaps you want this 'compression' algorithm: The 2^32 longs we decree as representable in this scheme are:

all the longs from 0 to 2^31-1, by mapping them to the same integer value, and then also another batch of 2^31 longs that immediately follow that, by mapping them bitwise, although, given that in java all numbers are signed, these then map to negative ints. All other long values (so all values above 2^32-1 and all negative longs) cannot be mapped (or if you try, they'd unmap to the wrong value).

If you want that, all you need to do:

int longToInt = (int) theLong;
long backToLong = 0xFFFFFFFFL & theLong;

Normally if you cast an int to a long it 'sign extends', filling the top 32 bits with 1s to represent the fact that your int is negative. The bitwise & operation clears the top 32 bits all back down to 0 and you're back to your original... IF the original long had 32 zero-bits at the top (which 3706111600L does).

Upvotes: 2

Torsten Fehre
Torsten Fehre

Reputation: 567

Your test number is too small. Converted into Hexadecimal, 3706111600L is 0x00000000DCE6C670. If you shift this number 32 bits to the right, you will lose the last 8 nibbles; your resulting number is 0x00000000L. Casted to int this value is still 0.

Upvotes: 1

Related Questions