I recently used the shift operators in Java and noticed that the >> operator does not have the same meaning as >> in C. In Java >> is Signed shift that keeps the first bit at the same value. In Java the equivalent to C shift is the >>> operator. The left shift operator (<<) is the same as in C and just shifts ignoring the first bit.
The things I wondered are
Why make this change?
Why is the notation not consistent so >> and << are signed shift and >>> and <<< are unsigned?
Is there any use for a signed shift operator?
There is never any need for a sign-aware left shift, since 2:s complement representation stores the sign in the most significant bit.
There's no difference between a value shifted one bit to the left in some kind of "sign-aware" manner, there's nothing you can do differently. Shift the bits to the left, insert a 0 in the least significant bit, and you're done.
With signed numbers, shifting right is not so clear-cut, which is why there are two operators.
As far as I know the meaning of >> and >>> has always been the same in Java.
Why make this change?
Machine independence. The meaning of >> is somewhat implementation dependent in C.
Signed left shift and unsigned left shift are exactly equivalent, so there's no need to have a separate operator.
On the other hand, Java has no unsigned types, so it can't depend on the type to figure out what shift to use.
For reference, I think you have it backwards -- >> is signed right shift, >>> is unsigned right shift.
Related
I have a 3 byte signed number that I need to determine the value of in Java. I believe it is signed with one's complement but I'm not 100% sure (I haven't studied this stuff in more than 10 years and the documentation of my problem isn't super clear). I think the problem I'm having is Java does everything in two's complement. I have a specific example to show:
The original 3-byte number: 0xEE1B17
Parsed as an integer (Integer.parseInt(s, 16)) this becomes: 15604503
If I do a simple bit flip (~) of this I get (I think) a two's complement representation: -15604504
But the value I should be getting is: -1172713
What I think is happening is I'm getting the two's complement of the entire int and not just the 3 bytes of the int, but I don't know how to fix this.
What I have been able to do is convert the integer to a binary string (Integer.toBinaryString()) and then manually "flip" all of the 0s to 1s and vice-versa. When then parsing this integer (Integer.parseInt(s, 16)) I get 1172712 which is very close. In all of the other examples I need to always add 1 to the result to get the answer.
Can anyone diagnose what type of signed number encoding is being used here and if there is a solution other than manually flipping every character of a string? I feel like there must be a much more elegant way to do this.
EDIT: All of the responders have helped in different ways, but my general question was how to flip a 3-byte number and #louis-wasserman answered this and answered first so I'm marking him as the solution. Thanks to everyone for the help!
If you want to flip the low three bytes of a Java int, then you just do ^ 0x00FFFFFF.
0xFFEE1B17 is -1172713
You must only add the leading byte. FF if the highest bit of the 3-byte value is set and 00 otherwise.
A method which converts your 3-byte value to a proper intcould look like this:
if(byte3val>7FFFFF)
return byte3val| 0xFF000000;
else
return byte3val;
Negative signed numbers are defined so that a + (-a) = 0. So it means that all bits are flipped and then 1 added. See Two's complement. You can check that the condition is satisfied by this process by thinking what happens when you add a + ~a + 1.
You can recognize that a number is negative by its most significant bit. So if you need to convert a signed 3-byte number into a 4-byte number, you can do it by checking the bit and if it's set, set also the bits of the fourth byte:
if ((a & 0x800000) != 0)
a = a | 0xff000000;
You can do it also in a single expression, which will most likely perform better, because there is no branching in the computation (branching doesn't play well with pipelining in current CPUs):
a = (0xfffffe << a) >> a;
Here << and >> perform byte shifts. First we shift the number 8 bits to the right (so now it occupies the 3 "upper" bytes instead of the 3 "lower" ones), and then shift it back. The trick is that >> is so-called Arithmetic shift also known as signed shift. copies the most significant bit to all bits that are made vacant by the operation. This is exactly to keep the sign of the number. Indeed:
(0x1ffffe << 8) >> 8 -> 2097150
(0xfffffe << 8) >> 8 -> -2
Just note that java also has a unsigned right shift operator >>>. For more information, see Java Tutorial: Bitwise and Bit Shift Operators.
This is a really basic question, but I've never fully convinced myself that my intuitive answer of "it makes no difference" is correct, so maybe someone has a good way to understand this:
If all I want to do with one of the primitive numeric types in Java is bitwise arithmetic, can I simply treat it as if it was an unsigned value or do I need to avoid negative numbers, i.e. keep the highest order bit always set to 0? For example, can I use an int as if it was an unsigned 32-bit number, or should I only use the lowest 31 bits?
I'm looking for as general an answer as possible, but let me give an example: Let's say I want to store 32 flags. Can I store all of them in a single int, if I use something like
store = store & ~(1 << index) | (value << index)
to set flag index to value and something like
return (store & (1 << index)) != 0
to retrieve flag index? Or could I run into any sort of issues with this or similar code if I ever set the flag with index 31 to 1?
I know I need to always be using >>> instead of >> for right shifting, but is this the only concern? Or could there be other things going wrong related to the two's complement representation of negative numbers when I use the highest bit?
I know I need to always be using >>> instead of >> for right shifting, but is this the only concern?
Yes, this is the only concern. Shifting left works the same on signed and unsigned numbers; same goes for ANDing, ORing, and XORing. As long as you use >>> for shifting right, you can use all 32 bits of a signed int.
There are legitimate reasons to use >> as well in that context (a common case is when making a mask that should be 0 or -1 directly, without having to negate a mask that is 0 or 1), so there is really no concern at all. Just be careful of what you're doing to make sure it matches your intent.
Operations that care about signedness (ie they have distinct signed and unsigned forms with different semantics) are:
right shift
division (unsigned form not available in Java)
modulo (unsigned form not available in Java)
comparisons (except equality) (unsigned forms not available in Java)
Operations that don't care about signedness are:
and
or
xor
addition
subtraction
two's complement negation (-x means ~x + 1)
one's complement (~x means -x - 1)
left shift
multiplication
I know the binary representation of -127 is 10000001 (complement).
Can any body tell me why I right shift it by 1 digit, then I get 11000000 ?
(-127) = 10000001
(-127>>1) = 11000000 ???
Thanks.
If your programming language does a sign-extending right shift (as Java does), then the left-most 1 comes from extending the sign. That is, because the top bit was set in the original number it remains set in the result for each shift (so shifting by more than 1 has all 1's in the top most bits corresponding to the number of shifts done).
This is language dependent - IIRC C and C++ sign-extend on right shift for a signed value and do not for an unsigned value. Java has a special >>> operator to shift without extending (in java all numeric primitive values are signed, including the misleadingly named byte).
Right-shifting in some languages will pad with whatever is in the most significant bit (in this case 1). This is so that the sign will not change on shifting a negative number, which would turn into a positive one if this was not in place.
-127 as a WORD (2 bytes) is 1111111110000001. If you right shift this by 1 bit, and represent it as a single byte the result is 11000000 This is probably what you are seeing.
Because, if you divide -127 (two's-complement encoded as 10000001) by 2 and round down (towards -infinity, not towards zero), you get -64 (two's-complement encoded as 11000000).
Bit-wise, the reason is: when right-shifting signed values, you do sign-extension -- rather than shifting in zeroes, you duplicate the most significant bit. When working with two's-complement signed numbers, this ensures the correct result, as described above.
Assembly languages (and the machine languages they encode) typically have separate instructions for unsigned and signed right-shift operations (also called "logical shift right" vs. "arithmetic shift right"); and compiled languages typically pick the appropriate instruction when shifting unsigned and signed values, respectively.
It's sign extending, so that a negative number right shifted is still a negative number.
I am new to java, and came to know that there are two Right Shift operators in java >> and >>>, but only one left shift operator <<. Why is it so?
Because logical and arithmetic left-shift operations are identical (from wikipedia).
Arithmetic shift
Logical shift
Notice what happens to sign bit (left-most bit) in both left shifts.
The right shift operators are one with (>>) and one without (>>>) sign-extension. The left shift operation does not have a sign extension component.
For instance, the following expressions are both true:
(0x80000000 >> 1) == 0xC0000000
(0x80000000 >>> 1) == 0x40000000
This question already has answers here:
Difference between >>> and >>
(9 answers)
Closed 5 years ago.
What is the difference between the operator >> and >>>?
>>> right shifts and fills with 0 at the left end, while >> fills with the sign bit.
This makes a difference for the signed integral types (i.e. all but byte), where a negative value has a set sign bit.
>> Signed right shift operator and >>> unsigned right shift operator
Signed Right Shift Operator
The right shift >> operator shifts
the left operand to the right side
with sign extension by the number of
bits specified by its right operand.
This means that a value at n place
gets shifted to the right causing the
n high order bits that contains the
same value as that of unshifted value.
This operator never throws an
exception.
Unsigned Right Shift Operator
The unsigned right shift >>> operator
shifts a zero into the leftmost
position however the leftmost position
after ">>" depends on sign extension.
the signed right shift operator ">>"
shifts a bit pattern to the right. The
bit pattern is given by the left-hand
operand, and the number of positions
to shift by the right-hand operand.
The unsigned right shift operator
">>>" shifts a zero into the leftmost
position, while the leftmost position
after ">>" depends on sign extension.
From http://java.sun.com/docs/books/tutorial/java/nutsandbolts/op3.html
Here is an explanation with examples:
http://www.roseindia.net/java/master-java/bitwise-bitshift-operators.shtml
>> fills in the sign the sign bit on the left (i.e. fills in 1 for negative values, 0 for positive), whereas >>> doesn't (always 0). This is convenient when shifting negative values. There is no <<<, since the sign bit is on the left and << thus already behaves like <<< would (filling in zeros, nothing else).