How does bitshifting work in Java?
Firstly, you can not shift a byte
in java, you can only shift an int
or a long
. So the byte
will undergo promotion first, e.g.
00101011
-> 00000000000000000000000000101011
or
11010100
-> 11111111111111111111111111010100
Now, x >> N
means (if you view it as a string of binary digits):
- The rightmost N bits are discarded
- The leftmost bit is replicated as many times as necessary to pad the result to the original size (32 or 64 bits), e.g.
00000000000000000000000000101011 >> 2
-> 00000000000000000000000000001010
11111111111111111111111111010100 >> 2
-> 11111111111111111111111111110101
What are bitwise shift (bit-shift) operators and how do they work?
The bit shifting operators do exactly what their name implies. They shift bits. Here's a brief (or not-so-brief) introduction to the different shift operators.
The Operators
>>
is the arithmetic (or signed) right shift operator.>>>
is the logical (or unsigned) right shift operator.<<
is the left shift operator, and meets the needs of both logical and arithmetic shifts.
All of these operators can be applied to integer values (int
, long
, possibly short
and byte
or char
). In some languages, applying the shift operators to any datatype smaller than int
automatically resizes the operand to be an int
.
Note that <<<
is not an operator, because it would be redundant.
Also note that C and C++ do not distinguish between the right shift operators. They provide only the >>
operator, and the right-shifting behavior is implementation defined for signed types. The rest of the answer uses the C# / Java operators.
(In all mainstream C and C++ implementations including GCC and Clang/LLVM, >>
on signed types is arithmetic. Some code assumes this, but it isn't something the standard guarantees. It's not undefined, though; the standard requires implementations to define it one way or another. However, left shifts of negative signed numbers is undefined behaviour (signed integer overflow). So unless you need arithmetic right shift, it's usually a good idea to do your bit-shifting with unsigned types.)
Left shift (<<)
Integers are stored, in memory, as a series of bits. For example, the number 6 stored as a 32-bit int
would be:
00000000 00000000 00000000 00000110
Shifting this bit pattern to the left one position (6 << 1
) would result in the number 12:
00000000 00000000 00000000 00001100
As you can see, the digits have shifted to the left by one position, and the last digit on the right is filled with a zero. You might also note that shifting left is equivalent to multiplication by powers of 2. So 6 << 1
is equivalent to 6 * 2
, and 6 << 3
is equivalent to 6 * 8
. A good optimizing compiler will replace multiplications with shifts when possible.
Non-circular shifting
Please note that these are not circular shifts. Shifting this value to the left by one position (3,758,096,384 << 1
):
11100000 00000000 00000000 00000000
results in 3,221,225,472:
11000000 00000000 00000000 00000000
The digit that gets shifted "off the end" is lost. It does not wrap around.
Logical right shift (>>>)
A logical right shift is the converse to the left shift. Rather than moving bits to the left, they simply move to the right. For example, shifting the number 12:
00000000 00000000 00000000 00001100
to the right by one position (12 >>> 1
) will get back our original 6:
00000000 00000000 00000000 00000110
So we see that shifting to the right is equivalent to division by powers of 2.
Lost bits are gone
However, a shift cannot reclaim "lost" bits. For example, if we shift this pattern:
00111000 00000000 00000000 00000110
to the left 4 positions (939,524,102 << 4
), we get 2,147,483,744:
10000000 00000000 00000000 01100000
and then shifting back ((939,524,102 << 4) >>> 4
) we get 134,217,734:
00001000 00000000 00000000 00000110
We cannot get back our original value once we have lost bits.
Arithmetic right shift (>>)
The arithmetic right shift is exactly like the logical right shift, except instead of padding with zero, it pads with the most significant bit. This is because the most significant bit is the sign bit, or the bit that distinguishes positive and negative numbers. By padding with the most significant bit, the arithmetic right shift is sign-preserving.
For example, if we interpret this bit pattern as a negative number:
10000000 00000000 00000000 01100000
we have the number -2,147,483,552. Shifting this to the right 4 positions with the arithmetic shift (-2,147,483,552 >> 4) would give us:
11111000 00000000 00000000 00000110
or the number -134,217,722.
So we see that we have preserved the sign of our negative numbers by using the arithmetic right shift, rather than the logical right shift. And once again, we see that we are performing division by powers of 2.
Is java bit shifting circular?
Bit shifting is not circular; for bit-shifting int
s, Java only uses the 5 least-significant bits, so that (b << 0)
is equivalent to (b << 32)
(is equivalent to (b << 64)
, etc.). You can simply take the bit-shifting amount and take the remainder when dividing by 32.
Something similar occurs for bit-shifting long
s, where Java only uses the 6 least-significant bits, so that (aLong << 0)
is equivalent to (aLong << 64)
.
Section 15.19 of the JLS talks about this:
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 & (§15.22.1) with the mask value 0x1f (0b11111). The shift distance actually used is therefore always in the range 0 to 31, inclusive.
If the promoted type of the left-hand operand is long, then only the six 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 & (§15.22.1) with the mask value 0x3f (0b111111). The shift distance actually used is therefore always in the range 0 to 63, inclusive.
(emphasis mine)
(You can't bit-shift float
s or double
s, and attempting to bit-shift a short
or a byte
would be subject the value to unary numeric promotion to an int
anyway.)
You get 0
from 16 << 30
, because the 1-bit from 16
00000000 00000000 00000000 00010000
gets shifted off the end of the int
and gets discarded.
// Discarded - Result-----------------------------
(00000100) 00000000 00000000 00000000 00000000
Weird behaviour of bit-shifting with byte in Java
This happens exactly because byte
is promoted to int
prior performing bitwise operations. int -128
is presented as:
11111111 11111111 11111111 10000000
Thus, shifting right to 7 or 8 bits still leaves 7-th bit 1, so result is narrowed to negative byte
value.
Compare:
System.out.println((byte) (b >>> 7)); // -1
System.out.println((byte) ((b & 0xFF) >>> 7)); // 1
By b & 0xFF
, all highest bits are cleared prior shift, so result is produced as expected.
Java Bit Shifting Tutorial?
Well, the official Java tutorial Bitwise and Bit Shift Operators covers the actual operations that are available in Java, and how to invoke them.
If you're wondering "what can I do with bit-shifting", then that's not Java specific, and since it's a low-level technique I'm not aware of any list of "cool things you can" do per se. It'd be worth becoming familiar with the definitions, and keeping your eyes open for other code where this is used, to see what they've done.
Note that often bit-twiddling is an efficiency gain at the expense of clarity. For example, a << 1
is usually the same as a * 2
but arguably less clear. Repeated XORs can swap two numbers without using a temporary variable, but it's generally considered better form to write the code more clearly with the temporary variable (or even better, in a utility method). So in this respect it's hard to give great examples, because you're not likely to achieve anything new or profound on an architecture level; it's all about the low-level details. (And I'd estimate that a vast number of uses of bit-twiddling "in the wild" are instances of premature optimisation.)
How does this approximation of division using bit shift operations work?
>>
is bitshift. Every bit you shift right, in effect divides the number of 2.
Therefore, (length >> 3)
is length/8
(rounded down), and (length >> 6)
is length/64
.
Take (length/8)+(length/64)
is approximately length*(1/8+1/64)
= length*0.140625
(approximately)
1/7 = 0.142857...
The +1
at the end can be split into +0.5
for each term, so that length/8
is rounded to nearest (instead of down), and length/64
is also rounded to nearest.
In general, you can easily approximate 1/y
, where y = 2^n+-1
with a similar bit-shift approximation.
The infinite geometric series is:
1 + x + x^2 + x^3 + ... = 1 / (1 - x)
Multiplying by x:
x + x^2 + x^3 + ... = x/(1 - x)
And substituting x = 1/2^n
1/2^n + 1/2^2n + 1/2^3n + ... = (1/2^n) / (1 - 1/2^n)
1/2^n + 1/2^2n + 1/2^3n + ... = (1/2^n) / ((2^n - 1)/2^n)
1/2^n + 1/2^2n + 1/2^3n + ... = 1 / (2^n - 1)
This approximates y = 2^n - 1
.
To approximate y = 2^n + 1
, substitute x = -1/2^n
instead.
- 1/2^n + 1/2^2n - 1/2^3n + ... = (-1/2^n) / (1 + 1/2^n)
1/2^n - 1/2^2n + 1/2^3n - ... = (1/2^n) / ((2^n + 1)/2^n)
1/2^n - 1/2^2n + 1/2^3n - ... = 1 / (2^n + 1)
Then just truncate the infinite series to the desired accuracy.
Bitshifting a long in Java
It's because 1 is an int
literal, so <<
is applied to an integer. The result is cast to a long
, but by then it's too late.
If you write 1L << 32, etc., then all will be well. L
is used to denote a long
literal.
Bit shifting for 32 bit long
The type of decryptedVCW[2] & 0xff
is int
, since the first operand is byte
and the second is an int
literal.
When the first operand of the <<
operator is int
, you are shifting an int
, so if the second operand is 32, you'll get int
overflow.
You can cast the first operand of the <<
operator to long
:
(((long)(decryptedVCW[2] & 0xff)) << 32)
or you can force the first operand to be a long
by using a long
literal in the &
operation, as suggested by @shmosel :
(decryptedVCW[2] & 0xFFL) << 32
Related Topics
Why Does Java Code with an Inner Class Generates a Third Someclass$1.Class File
Accessing a File Inside a .Jar File
How to Include Test Classes into Maven Jar and Execute Them
Creating Runnable Jar with External Files Included
Managing Dll Dependencies with Maven
Scanner Class Skips Over Whitespace
Hibernate/JPA - Annotating Bean Methods VS Fields
Why Do Java If Statement Fail When It Ends in Semicolon
How to Include External Jar on My Netbeans Project
What Code Does the Compiler Generate for Autoboxing
JPA SQL Server No Dialect Mapping for Jdbc Type: -9
How to Listen for Key Presses (Within Java Swing) Across All Components
Writing in the Beginning of a Text File Java