This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.

Write out its bit pattern. HInt: you can get it from Integer.toBinaryString(Integer.Min_VALUE). It might be 1 and thirty-one 0s. Or it might not be.
Work out its two's complement when negated: Hint: Write out the bit pattern for 2 to the 32nd. That is 1 and thirty-two 0s. Subtract the binary pattern for -2147483648 from that. And what do you get . . . Tadaaa!

Avinash Haridasu wrote:Can any one tell me
how do we decide whether a number is negative or positive just by looking at the binary representation

0 0 0 0 0 0 0 1 = 1
1 1 1 1 1 1 1 1 = −1

.
In binary number system we can use only 2 things and that is 0 and 1 and we have to use 0 and 1 for representing the negative numbers also.There is something known as MSB(most significant bit) and LSB(least significant bit). Now the left-most-bit is your MSB and right-most-bit is LSB. Example 01010101 Here the one in red color is MSB and the one in green color is LSB..
.
So you must have understood what is MSB and LSB. Now if the MSB is 0 then the number is positive and if the MSB is 1 then the number is negative. So the conclusion is MSB represents the sign of the number and other numbers(i would say bits ) are the actual value. So
Since MSB is 0 therefore number is positive and waht about the value 0000001 is equal to 1 and therefor ans is . Now Now MSB is 1 therefore number is negative and Java uses 2's complement for negative numbers and the 2's complement of 11111111 is 00000001 and therefore the ans is -1 (Please find out how to find 2's complement if you are not aware).
.
As for your second question about >> i am not sure.

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 43975

33

posted

0

Your description of the values of LSB and MSB is correct, but you ought to remember that only applies to two's complement numbers. The char for example is unsigned and behaves differently.

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 43975

33

posted

0

Look in the Java Language Specification and you find that the number of bits shifted is calculated % i where i is the number of bits in the datatype. So for everything except a long, shift 37 and shift 5 have the same effect.
i >> 5 is equivalent to i / 32

Rameshwar Soni
Ranch Hand

Joined: Feb 03, 2011
Posts: 247

posted

0

Campbell Ritchie wrote:but you ought to remember that only applies to two's complement numbers. The char for example is unsigned and behaves differently.

Behaves differently ? Can you give an example so that i can understand it better?

char is like an unsigned 16-bit number. You can't store negative values in a char. So a char with the bit pattern 1111 1111 1111 1111 has the value 65536, not -32768. In other words, for a char, two's complement is not used.

The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 43975

33

posted

0

Actually it's not quite i % 32, but more like i & 31, which behaves similarly to i % 32 but gives a positive result from a negative left operand.

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 43975

33

posted

0

Stephan van Hulst wrote:Did you mean -1?

No, Jesper actually means 65535, assuming that is the bit pattern for a char. That is equivalent to the Unicode character for ffff, and you can find what that is here.

char is like an unsigned 16-bit number. You can't store negative values in a char. So a char with the bit pattern 1111 1111 1111 1111 has the value 65535, not -1. In other words, for a char, two's complement is not used.

Avinash Haridasu
Ranch Hand

Joined: Jul 12, 2011
Posts: 31

posted

0

Campbell Ritchie wrote:Look in the Java Language Specification and you find that the number of bits shifted is calculated % i where i is the number of bits in the datatype. So for everything except a long, shift 37 and shift 5 have the same effect.
i >> 5 is equivalent to i / 32

As per Specification:

If the promoted type of the left-hand operand is int, only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & with the mask value 0x1f. The shift distance actually used is therefore always in the range 0 to 31, inclusive.

But why it is "only the five lowest-order bits" ???

When 32>>6 is itself 0 - Then how 32>>33 is 16, 32>>38 is 0 ???

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 43975

33

posted

0

The Java Language Specification link I gave you yesterday explains it all. There are 32 bits to an int, so you cannot shift an int more than 31 bits. You can fit 31 into 5 bits. [A long can be shifted up to 63 bits, and you can fit 63 into 6 bits.] If you shifted it 32 bits, you would come back to where you started, so i >> 32 is the same as i, which is the same as i >> 0. So you can shift an int by |n % 32| bits, where || is the absolute value operator. Now the absolute value of n % 32 is the same (in binary arithmetic) as n & 32 - 1. And as we all know, 32 - 1 = 0x1f. If you write the bit pattern for 0x1f you find it has 5 1s in. So you get 5 bits masked.

32 bits in an int.
32 = 2 to the 5th.
So you shift an int by the rightmost (least significant) five bits (six for a long).

I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com

subject: How is -Integer.MIN_VALUE Equal to Integer.MIN_VALUE