Java bit wise operator (zero fill shift) not filling with zeros - java

I've been getting a weird problem with Java, and have tested on both a Windows and Mac system and have this problem come up consistently.
Take a look at this code
int a = -32; //11100000 as per two's complement
System.out.println(a >>> 2);
I expect this code to produce 56, which is 00111000 in its binary form. However, it produces the value 1073741816, 111111111111111111111111111000 in its binary form. I understand ints are 32-bits in java, but setting the type of byte also does the same thing.
However if I declare a binary literal like this
int b = 0b11100000;
System.out.println(b);
System.out.println(b >>> 2);
The first statement produces the value 224 (expected -32), while the second statement produces the expected value of 56
Am I going insane?

Your bit pattern in b is not 11100000 like you say, but 11111111 11111111 11111111 11100000
You're using an int which is 32 bits - not a byte - and using binary literals doesn't change that.
Even if you used byte rather than int it wouldn't fix your problem, because the Java bitshift operators first promote any type less than 32 bits to 32 bits.
So the resulting bit pattern is 00111111 11111111 11111111 11111000 after the shift.
If you want to mimic working with an 8-bit value, you need to bit-mask the 32-bit value to the lower 8 bits before applying the bitshift (you may as well use >> rather than >>> now)
System.out.println((b & 0xff) >>> 2);

Related

Converting 0xFF gives me -1 -> Signed vs Unsigned?

Here is my code:
byte b = (byte) 0xFF;
System.out.println(b);
I expect to see 255, but instead I see -1. What's happening? Is the compiler using a signed instead of an unsigned byte?
Maybe you are confused about the difference between storage and representation.
As the others told you, Java only uses signed integral types. As a byte is only 8 bit, this means you have a range from -128 to 127. But keep in mind: This is only a decimal representation that does not tell you about the binary storage!
A better reminder for the range of Java's byte type would be the following (decimal) representation:
0 1 ... 126 127 -128 -127 ... -2 -1
This directly corresponds to the following binary representation:
00000000 00000001 ... 11111110 11111111
The signed decimal representation is called the two's complement. As you can see, the binary value 11111111, which is exactly 0xFF, corresponds to the (signed) decimal value -1.
If you now send this value via a stream, you will get the full 0xFF value, regardless what you see in a Java program's console output.
In Java type byte is signed, it is not possible to use an "unsigned byte" in java. A workaround would be to use short types
Everytime you operate on a byte variable in Java, (byte) 0xFF is going to be implicitly converted to (int) 0xFFFFFF (i.e. -1). You can do 0xFFFFFF & 0xFF and then you'll get (int) 255 as you wish (you will never be able to get (byte) 255, only (int) 255).
If you only need to store bytes, it doesn't matter how 0xFF is printed on the screen, it's still (byte) 0xFF internally. If you need to operate on them (comparing to an int, adding, subtracting, converting to a string, printing on the screen, and basically anything else), then you need to be aware that they'll get converted to int 0xFFFFFF which is interpreted -1.

What is the meaning of >> and & operator in java code color example

I am working on a small project. During the searching on google I see some code in java .
int red = (pixel >> 16) & 0x000000FF;
But I do not understand what is the meaning of that ? CAn anybody explain summary of that logical operation ? I read that it is shifted sth like that but shift of what ?
The red component of a color is stored as a number between 0-255, but "packed" into an integer. Here's my ASCII art, in binary, 32 bits per integer, showing the 8 bits each for Alpha,Red,Green,and Blue. Read the bit number vertically! I'm numbering from 1, not 0. (Also, you can argue that the numbers go the wrong direction - they are there just to help you count!)
11111111112222222222333
12345678901234567890123456789012
AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB the pixel value
The pixel >> 16 will shift the result right by 16 bits. In effect, this removes the G and B stuff
AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB move everything 16 to the right, this becomes
----------------AAAAAAAARRRRRRRR
where the - depends on sign. You can look it up but in this case it doesn't matter.
So, you have your Red number, almost. There is still the Alpha component, all that AA.... If you mask ("and") with 0xFF, which is the lowest 8 bits
----------------AAAAAAAARRRRRRRR (result of the bit shift)
00000000000000000000000011111111 (0xFF)
you get
000000000000000000000000RRRRRRRR
which is the result desired, a number between 0 and 255.
This is a bitwise "AND" operator. When it is applied to the number FF (hex) it clears all bits of an int except the final 8.
Recall that bitwise "AND" goes through a binary representation of a number, and puts ones in the result only in positions where both operands have ones. Since a 32-bit mask containing FF looks like this in binary
00000000000000000000000011111111
the upper three bytes of the result are going to be zeros. The last byte, where FF has all ones, will be equal to the last byte of the first operand.
& - bitwise AND operator
>> - right shift operator - shifts a bit pattern to the right
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/op3.html
For example
4 in binary 100, if you do >>1 that would be 010 which is 2
8 in binary 1000, if you do >>1 that would be 0100 which is 4
See also
What are bitwise shift (bit-shift) operators and how do they work?

Declaring masks for bitwise operations

I'm new to low level operations like this, I'm hoping someone can point out the obvious mistake I must be making here.
//Input value - 00111100
//I want to get the value of the bits at indexes 1-3 i.e 0111.
byte mask = (byte)0x00001111; // This gives 17 not the 15 I'd expect
byte shifted = (byte)(headerByte >> 3);
//shifted is 7 as expected
byte frameSizeValue = (byte)(shifted & mask); //Gives 1 not 7
It looks like the problem lies with the way the mask is defined, but I can't see how to fix it.
First of all 0x00001111 is in hex, which is a larger number than 255 - 16^3 + 16^2 + 16 + 1 = 4369 and byte overflows. Look here how to represent binary numbers or just use shifted & 15.
Your mask needs to be binary 00001111, which is equal to hex 0x0F.
byte mask = (byte)0x0F;
With java 7 you can create binary literals
byte binaryLit = (byte)0b00001111;
0xsomenumbers is a hex literal, and pre java7 there is no support for binaries.
You say you want to mask the first three bits but as Petar says, 0x001111 are not bits. If you want to mask the three bits you need to mask with 7

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.

Why byte b = (byte) 0xFF is equals to integer -1?

Why byte b = (byte) 0xFF is equal to integer -1?
Ex:
int value = byte b = (byte) 0xFF;
System.out.println(value);
it will print -1?
Bytes are signed in Java. In binary 0x00 is 0, 0x01 is 1 and so on but all 1s (ie 0xFF) is -1, 0xFE is -2 and so on. See Two's complement, which is the binary encoding mechanism used.
b is promoted to an int in determining which overload of system.out.println to call.
All bytes in Java are signed.
The signed byte 0xff represents the value -1. This is because Java uses two's complement to represent signed values. The signed byte 0xff represents -1 because its most significant bit is 1 (so therefore it represents a negative value) and its value is -128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = -1.
perhaps your confusion comes from why (byte)0xFF is somehow equal to (int)0xFFFFFFFF. What's happening here is the promotion from smaller to larger signed types causes the smaller value to be sign extended, whereby the most significant bit is copied to all of the new bits of the promoted value. an unsigned type will not become sign-extended, they get zero extended, the new bits will always be zero.
If it helps you to swallow it, think of it this way, every integer of any size also has some 'phantom' bits that are too significant to be represented. they are there, just not stored in the variable. a negative number has those bits nonzero, and positive numbers have all zeros for phantom bits when you promote a smaller value to a larger one, those phantom bits become real bits.
If you are using a signed int then 0xFF = -1 due to the 2-complement.
This wiki article explains it well, see the table on the right:
http://en.wikipedia.org/wiki/Two%27s_complement
Because Java (and most languages) represent negative integer values using two's-complement math. In two's-complement, 0xFF (11111111) represents (in a signed int) the value -1.
reduced modulo
byte = 256
0xff = 255
255 / 256 -> remainder 255
So 255 - 256 = -1
Simple Logic
Cheers
Its not just Java that does 2's complement math. That is the way every microprocessor and DSP that I can think of does math. So, its the way every programming language represents it.

Categories