Binary presentation of negative integer in Java

Question

Please, help me to understand binary presentation of negative integers.

For example we have 5. Binary presentation of 5 is 00000000.00000000.00000000.00000101 .

And as I understand binary presentation of -5 should be like 10000000.00000000.00000000.00000101 .

But output is 11111111.11111111.11111111.11111011 .

I have 2 question:

1) Why here is so much 1 bits.

2) What I really cant understand it last 3 bits 011 . It looks like 3 . Even +1 or -1 it'll be 100 or 010

Thanks

Answer 1

Your understanding of what those negative numbers should look like is flawed. Java uses two's complement for negative numbers and the basic rule is to take the positive, invert all bits then add one. That gets you the negative.

Hence five is, as you state:

0000...00000101

Inverting that gives you:

1111...11111010

Then adding one gives:

1111...11111011

The bit pattern you have shown for -5 is what's called sign/magnitude, where you negate a number simply by flipping the leftmost bit. That's allowed in C implementations as one of the three possibilities ^(a) , but Java uses two's complement only (for its negative integers).

---

^(a) But keep in mind there are current efforts in both C and C++ to remove the other two encoding types and allow only two's complement.

Answer 2

And as I understand binary presentation of -5 should be like 10000000.00000000.00000000.00000101 .

That would be right if Java used a Sign and Magnitude representation for integers. However, Java uses Two's Complement representation, so the rest of the bits are changed in accordance with the rules of that representation.

The idea behind two's complement representation is that when you add a number in such representation to another value dropping the extra bit on the most significant end, the result would be as if you subtracted a positive number of the same magnitude.

You can illustrate this with decimal numbers. In a two-digit representation, the value of 99 would behave like -1, 98 would be like -2, 97 like -3, and so on. For example, if you drop the top digit in 23 + 99 = [1]22 , so 99 behaved like -1. 23 + 98 = [1]21 , so 98 behaved like -2.

This works the same way with two's complement representation of binary numbers, except you would drop the extra bit at the top.

Answer 3

http://en.wikipedia.org/wiki/Two%27s_complement

The way negative numbers are stored is that the most significant bit (eg the bit representing 2^31 for a 32 bit number) is regarded as negative. So if you stored all 1s, you would add up

(-2^31) + 2^30 + 2^29 + ... + 2^1 + 2^0

which makes -1 .

Small negative numbers will be mostly ones under this representation.

Answer 4

Here is an example for 2's compliment:

If you have -30, and want to represent it in 2's complement, you take the binary representation of 30:

0000 0000 0000 0000 0000 0000 0001 1110

Invert the digits.

1111 1111 1111 1111 1111 1111 1110 0001

And add one.

1111 1111 1111 1111 1111 1111 1110 0010

Converted back into hex, this is 0xFFFFFFE2. And indeed, suppose you have this code:

#include <stdio.h>

int main() {
    int myInt;
    myInt = 0xFFFFFFE2;
    printf("%d\n",myInt);

    return 0;
}

That should yield an output of -30. Try it out if you like.

Answer 5

With two's complement it's true that a MSB of 1 indicates a negative number. But the remaining bits are not the binary representation of its value. On the other hand, if the MSB is 0 the remaining bits represent the binary value. But it cannot be said that the number is positive then. Zero is neither positive nor negative.

This picture helped me to understand the principle when I started to learn that there are more representations of numbers than with 0..9:

           0
    -1    000    1
       111   001  
-2  110         010  2
       101   011
    -3    100    3
          -4