Bitwise operation : FitsBits

Question

I meet some problems when i am writing the FitsBits for a long time,so i googled it,and find a solution which is right for the test program,but i can not figure out what that means.

Problem Description:

fitsBits - return 1 if x can be represented as an n-bit, two's complement integer.
1 <= n <= 32
Examples:

fitsBits(5,3) = 0, fitsBits(-4,3) = 1
Legal ops: ! ~ & ^ | + << >> Max ops: 15

A Right solution is that:

int fitsBits(int x, int n)
{   
int move;  
move = 32 +(~n+1);
return !(x^((x<<move)>>move)); 
}

But I don't know

!( x ^ ( ( x<< move ) >> move ) )

means what.

I really need some help.Thx!

score 5 · Accepted Answer · edited May 23 '17 at 12:25

This question is a duplicate of Bitwise operations and shifts, the user asks to understand the same code. unfortunately I don't have the reputation to mark it.

To reiterate Code-Apprentice's answer and AnT's, with some modifications based on the solution you found and more explanation of my own

move = 32 +(~n+1);

This is actually the difference between 32 (the max value of n, and size of integer in this problem) and n.

To understand why look into twos complement signed integers. In this format you convert a unsigned integer, for example in the original example, 5 (0101) into -5 via inverting the bits and adding one,

~5 + 1 = -5

or

~(0101) + 1 = 1011

Notice how 1011 cannot fit into 3 bits and still be a negative number (negative numbers in 2s complement must start with 1)

so

move = 32 +(~n+1);

is actually

move = 32 - n;

The final line is actually several ideas in one line

!(x^((x<<move)>>move));

so lets decompose it.

invert the truthiness of 
    (x xor a number) 
        where the number is x first shifted left then right amount move
            and move is the difference between n and 32.

Lets use the 5 and 3 example again. We know that move should be 32 -3, so move is 29.

but why shift left and right the same amount? Typically when you see some one do this in code, they are attempting to 'zero out' of a number. In this case, the author isn't doing that, but sign extending. Look below

for example:

given 0000 0000 0000 0000 0000 0000 0000 0101 = 5
5 << 29 = 1010 0000 0000 0000 0000 0000 0000 0000 = -1610612736
-1610612736 >> 29 = 1111 1111 1111 1111 1111 1111 1111 1101 = -3

The author is using a implementation level quirk of rshift, if the number starts out as a signed, it keeps its sign and sign fills the rest of the number as its shifted.

Notice how because of sign filling (5 >> 29) << 29 does not result in the same number, because when we shifted 5 to the end of a 32 bit signed number, it started with 1, and therefore becomes signed itself.

the next line is much simpler

(x ^ number)

will be 0 if x == number, since 0 xor 1 = 1, and 1 xor 1 = 0, and 0 xor 0 = 0. So by that logic, when we invert the truthiness of x, we are checking if

x == (sign shifted x)

If 5 was, say, 8 instead (1000) we would simply lose the last digit (1) and we would find out that

!(8 ^ 0) == false.

If we chose to use a number that actually worked (say 3) since 3 = 011, and shifting 3 by 29 right would result in a 0 in the first bit, we would preserve the value of 3 when shifting back and forth, so we would find

!(3 ^ 3) == true;

To summarize the function really just does the following

given int x and int n,
check if x == (x shifted left then sign shifted right by (size of int in bits - n) )

Bitwise operation : FitsBits

1 Answers1