System.out.println(-Integer.MIN_VALUE == Integer.MIN_VALUE);//output: true

System.out.println(-Integer.MIN_VALUE); // output : -2147483648

Why is that a negative int remains negative when negated???

----------------------------------

Regards

Avinash

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!

Google for arithmetic overflow and two's complement binary integers, and you will get a different explanation of the same thing.

`int`and getting the same value works for the value you have shown, and one other value. I shall let you guess which other value.

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

and

System.out.println( 32 >> 37); // output: 1

System.out.println( 32 >> 5); // output: 1

How is this possible???

- 1

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.

`char`for example is unsigned and behaves differently.

`long`, shift 37 and shift 5 have the same effect.

i >> 5 is equivalent to i / 32

Campbell Ritchie wrote:but you ought to remember that only applies to two's complement numbers. The

charfor 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.*

No, Jesper actually means 6553Stephan van Hulst wrote:Did you mean -1?

__5__, 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.

not -32768

*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.*

`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.

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" ???

Can any one please explain ??

*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.*

32 In Binary: 0000 0000 - 0000 0000 - 0000 0000 - 0010 0000

32>>1:

0000 0000 - 0000 0000 - 0000 0000 - 0001 0000

32>>2:

0000 0000 - 0000 0000 - 0000 0000 - 0000 1000

32>>1:

0000 0000 - 0000 0000 - 0000 0000 - 0000 0001

32>>6:

0000 0000 - 0000 0000 - 0000 0000 - 0000 0000

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

`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`).

Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |