We Keep Coding

Binary presentation of negative integer in Java

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

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.

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.

http://en.wikipedia.org/wiki/Two%27s_complement
The way negative numbers are stored is that the most significant bit (e.g. 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.

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.

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

Java file operations [duplicate]

This question already has answers here:
What does << mean in Java?
(8 answers)
Closed 8 years ago.
I'm doing an assignment using Java, and our lecturers provided an example code for us. I'm unable to understand some of the code so can anyone explain?
private long magic;
private int minor;
magic = file.readUnsignedShort() << 16 | file.readUnsignedShort();
mnior = file.readUnsignedShort();
I don't understand why did he use "readUnsignedShort" for both of them and why did he add
"<< 16 | file.readUnsignedShort()" for magic. Any help will be much appreciated

A short uses 16 bits, an int uses 32 and a long uses 64 bits.
Given this, there are not unsigned values in Java, so if the most significant bit is 1, it means the value is negative.
Splitting the code you have:
file.readUnsignedShort() <- reads 16 bits
<< 16 <- moves them 16 positions "to the left", adding zeros (it's like multiply by 2^16)
| file.readUnsignedShort(); <- in those 16 zeros, puts the next 16 bites read, using the OR operation, which works as follows:
xxxx0000 | 0000YYYY = xxxxYYYY

Okay, let's start at the beginning.
RandomAccessFile.readUnsignedShort() reads 16 bits of information from the file, without interpreting it as a 2s complement representation.
So in the first line you do this: <first two bytes of the file> << 16 | <third and fourth bytes of the file>
<<16 means shift the number left by 16 bits. For unsigned numbers, this is the equivalent of multiplying by 65536.
| means do a bitwise or. Because we know the first number was shifted, in our case this is equivalent to just adding the numbers.
So this is what it does, why it does it is anybody's guess. You should ask your teacher really, but my guess is that it might have something to do with the fact that this is the only way to read a 32-bit unsigned number via RandomAccessFile.

This operation is like concat for bits.
short is 16 bit and integer is 32 bit long. Concatenating 2 short you will obtain a integer.
The << Operator stands for bitshift, in this way you are shifting the bits by sixteen positions.
Example:
NUMBER1 1111 1111 1111 1111
NUMBER2 0000 0000 0000 0000
NUMBER1 << 16 | NUMBER2 = 1111 1111 1111 1111 0000 0000 0000 0000
(thanks for hints)

magic = file.readUnsignedShort() << 16 | file.readUnsignedShort();
<< is bit shift operation
| is bitwise operation.
Read more here.

What is the meaning of 0x1234ABCD when working with raw bytes

When dealing with byte operations in Java, I saw sometimes that people masked a 0xFFFFFFFF long value (32bit value) with 0x1234ABCD
I know that Java does not support unsigned integer values (except char) but I would like to understand the meaning (if any) of these numbers 0x1234ABCD and 0xABCD1234 and also what is the significance to use them when working with raw bytes in Java?

Not sure what you are asking but anyway...
With Java, integer values (whether that be byte, short, char, int or long) are expressed as big endian, two's complement signed values. What you see here is another way than the decimal way of expressing such constants.
For instance, 28 as an int is internally represented as:
binary: 0000 0000 0000 0000 0000 0000 0001 1100
hex: 0 0 0 0 0 0 1 c
= 0x1c
Which means these two are equivalent:
int i = 28;
int i = 0x1c;
It is useful to express integer constants as hexadecimal when working with bit masks, because with a little habit, you can "translate" from hexadecimal to binary. For instance, when you want an integer with the last 4 bits of another one, it is more obvious what you do if you write:
i & 0xf
rather than:
i & 15
0xffffffff is -1 (or Integer.MIN_VALUE).

Everytime you calculate something, you´re dealing with numbers.
10 Dollars, 50 percent, 20 degree Celsius.
And the "nexadezimal" notations is just another way to write these numbers.
0xA Dollar, 0x32 percent, 0x14 degree Celsius.
What they mean depends on what you´re doing.
Calculating your money, temperature or something else.
When dealing with "raw byte" stuff, it´s often just more convenient
to write hex. numbers instead of normal decimal one´s,
because in such cases, they can actually improve readability.
Like 0x80000000 instead of 2147483648

Decimal to Binary Format Conversion

I have to write a Java program as part of an assignment to convert decimal inputs to the following formats: unsigned binary, unsigned hex, signed-magnitude, 1’s complement and 2’s complement. The issue is that I am not allowed to use any of the built-in java components that would otherwise not make this so difficult. I've been working on this for a number of hours, and the last thing I wanted to do was come on here and ask for help, but I really am stumped here. I do not expect, nor am I looking for anyone to complete my homework for me. All I ask is for a nudge in the right direction.
The output/input of the program must be as follows:
Enter num bytes: 2
Enter number (or Q to quit): 4095
Input number=4095
Unsigned binary = 0000 1111 1111 1111 (0x0fff)
Signed-magnitude = 0000 1111 1111 1111
One's complement = 0000 1111 1111 1111
Two's complement = 0000 1111 1111 1111
Excess 32768 = 1000 1111 1111 1111
Enter number (or Q to quit): -4095
Input number=-4095
Unsigned binary = undefined
Signed-magnitude = 1000 1111 1111 1111
One's complement = 1111 0000 0000 0000
Two's complement = 1111 0000 0000 0001
Excess 32768 = 0111 0000 0000 0001
I have a good understanding of how to calculate these values, and I have worked out many of the algorithms accordingly. The issue I'm having is that I don't know how to properly organize my classes to make this program efficient. Mostly, I'm getting confused by the instructions I've been given.
They read as follows:
Don’t use the byte data type in Java. We want to show the algorithms we use to do binary encodings. I created a simplistic BitString class. It’s one field is an array of char’s. It has methods like: BitString( numBytes), clear(), invert(), encodeUnsigned( num), setBit( pos, char).
I don't understand why we would want to use a char array to store these bit values. I've set this up so that the constructor in BitString accepts an argument for the number of bytes, multiplies that by 8 and creates a new char array using this number. Then to obtain the unsigned binary value of the decimal, I've implemented the following:
String unsigned = "";
while(decimal > 0)
{
unsigned = decimal%2 + unsigned;
decimal = decimal >> 1;
}
I don't know what I'm supposed to do from here to be able to store these values in that array so that I can use it to calculate the other formats. I can't seem to be able to store integers as chars and I'm confused on how I am supposed to use that data structure to perform the other operations. To complicate matters further, you'll notice that I need to pad the data so that it contains the correct number of bits.
If this were your problem, how would you solve it and how would you lay it out? I'm looking for the most fundamental solution that would be easy for a novice like me to understand.
Thank you very much.

The instructions probably mean that, instead of
String unsigned = "";
The data would be more easily manipulated into other formats with something like (this is pseudo-code, I don't really know java):
char unsigned[numBytes * 8];
The array stores one bit per location.
To do bitwise operations, you just iterate through the array and operate on each "bit."

Understanding Java bytes

So at work yesterday, I had to write an application to count the pages in an AFP file. So I dusted off my MO:DCA spec PDF and found the structured field BPG (Begin Page) and its 3-byte identifier. The app needs to run on an AIX box, so I decided to write it in Java.
For maximum efficiency, I decided that I would read the first 6 bytes of each structured field and then skip the remaining bytes in the field. This would get me:
0: Start of field byte
1-2: 2-byte length of field
3-5: 3-byte sequence identifying the type of field
So I check the field type and increment a page counter if it's BPG, and I don't if it's not. Then I skip the remaining bytes in the field rather than read through them. And here, in the skipping (and really in the field length) is where I discovered that Java uses signed bytes.
I did some googling and found quite a bit of useful information. Most useful, of course, was the instruction to do a bitwise & to 0xff to get the unsigned int value. This was necessary for me to get a length that could be used in the calculation for the number of bytes to skip.
I now know that at 128, we start counting backwards from -128. What I want to know is how the bitwise operation works here--more specifically, how I arrive at the binary representation for a negative number.
If I understand the bitwise & properly, your result is equal to a number where only the common bits of your two numbers are set. So assuming byte b = -128, we would have:
b & 0xff // 128
1000 0000-128
1111 1111 255
---------
1000 0000 128
So how would I arrive at 1000 0000 for -128? How would I get the binary representation of something less obvious like -72 or -64?

In order to obtain the binary representation of a negative number you calculate two's complement:
Get the binary representation of the positive number
Invert all the bits
Add one
Let's do -72 as an example:
0100 1000 72
1011 0111 All bits inverted
1011 1000 Add one
So the binary (8-bit) representation of -72 is 10111000.
What is actually happening to you is the following: You file has a byte with value 10111000. When interpreted as an unsigned byte (which is probably what you want), this is 88.
In Java, when this byte is used as an int (for example because read() returns an int, or because of implicit promotion), it will be interpreted as a signed byte, and sign-extended to 11111111 11111111 11111111 10111000. This is an integer with value -72.
By ANDing with 0xff you retain only the lowest 8 bits, so your integer is now 00000000 00000000 00000000 10111000, which is 88.

What I want to know is how the bitwise operation works here--more specifically, how I arrive at the binary representation for a negative number.
The binary representation of a negative number is that of the corresponding positive number bit-flipped with 1 added to it. This representation is called two's complement.

I guess the magic here is that the byte is stored in a bigger container, likely a 32 bit int. And if the byte was interpreted as being a signed byte it gets expanded to represent the same number in the 32 bit int, that is if the most significant bit (the first one) of the byte is a 1 then in the 32 bit int all the bits left of that 1 are also turned to 1 (that's due to the way negative numbers are represented, two's complement).
Now, if you & 0xFF that int you cut off those 1's and end up with a "positive" int representing the byte value you've read.

Not sure what you really want :) I assume you are asking how to extract a signed multi-byte value? First, look at what happens when you sign extend a single byte:
byte[] b = new byte[] { -128 };
int i = b[0];
System.out.println(i); // prints -128!
So, the sign is correctly extendet to 32 bits without doing anything special. The byte 1000 0000 extends correctly to 1111 1111 1111 1111 1111 1111 1000 0000.
You already know how to suppress sign extension by AND'ing with 0xFF - for multi byte values, you want only the sign of the most significant byte to be extendet, and the less significant bytes you want to treat as unsigned (example assumes network byte order, 16-bit int value):
byte[] b = new byte[] { -128, 1 }; // 0x80, 0x01
int i = (b[0] << 8) | (b[1] & 0xFF);
System.out.println(i); // prints -32767!
System.out.println(Integer.toHexString(i)); // prints ffff8001
You need to suppress the sign extension of every byte except the most significant one, so to extract a signed 32-bit int to a 64-bit long:
byte[] b = new byte[] { -54, -2, -70, -66 }; // 0xca, 0xfe, 0xba, 0xbe
long l = ( b[0] << 24) |
((b[1] & 0xFF) << 16) |
((b[2] & 0xFF) << 8) |
((b[3] & 0xFF) );
System.out.println(l); // prints -889275714
System.out.println(Long.toHexString(l)); // prints ffffffffcafebabe
Note: on intel based systems, bytes are often stored in reverse order (least significant byte first) because the x86 architecture stores larger entities in this order in memory. A lot of x86 originated software does use it in file formats, too.

To get the unsigned byte value you can either.
int u = b & 0xFF;
or
int u = b < 0 ? b + 256 : b;

For bytes with bit 7 set:
unsigned_value = signed_value + 256
Mathematically when you compute with bytes you compute modulo 256. The difference between signed and unsigned is that you choose different representatives for the equivalence classes, while the underlying representation as a bit pattern stays the same for each equivalence class. This also explains why addition, subtraction and multiplication have the same result as a bit pattern, regardless of whether you compute with signed or unsigned integers.