I can't find out what << means in Java because I can't search for it on Google - I am absolutely lost!
The code in question is:
public int getRGB() {
return ((red << 16) | (green << 8) | blue);
}
It's taken from: http://java.sun.com/docs/books/tutorial/essential/concurrency/example/ImmutableRGB.java
I would really appreciate someone telling me, thanks!
Left shift of the bits
If red == 4 (which in binary is: 00000100) then red << 16 will insert sixteen 0-bits at its right, yielding: 000001000000000000000000 which is 262144 in decimal
Q. What is this?
A. An "operator"
Q. How do I get to know about operators in java?
A. Google for "Java operators"
And the result is this:
The signed left shift operator "<<" shifts a bit pattern to the left, and 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.
Left shift a number of bits. It is equivalent to multiplying by two that many times.
It's used for setting specific bits in a byte, or specific bytes in a word.
It is the left shift operator. Here's some more information on shift operators from the Java Tutorial.
In your example code the three integer values: red, green and blue will typically have values 0-255. Hence, it is possible to combine these values and represent them as a single integer by shifting the red value by 16 bits, shifting the green value by 8 bits and then performing a bitwise-OR operation to combine the values.
its a bit shift. search for operators java, it will return you detailed explanations.
"<<" means left shift the bits of a value.
">>" means right shift the bits of a value.
example:
int a = 5; //the binary value of 5 is 101
a = a << 3; //left shift 3 bits on 101, 101 000<< add 3 bits(0) on the right, become '101000'
System.out.println(a); //this will display 40, the decimal for '101000'
int b = 9; //the binary value of 8 is 1001
b = b >> 3; //right shift 3 bits on >>000 1001 add 3 bits(0) on the left, truncate the last 3 bits on the right become '001'
System.out.println(b); //this will display 1, the decimal for '001'
Its a left bit shift
Its left shifting and convert Red, Green, Blue into 24 bit Number
Related
private static long permute(byte[] table, int srcWidth, long src) {
long dst = 0;
for (int i=0; i<table.length; i++) {
int srcPos = srcWidth - table[i];
dst = (dst<<1) | (src>>srcPos & 0x01);
}
return dst;
}
here dst = (dst<<1) | (src>>srcPos & 0x01); how does this work?? i am assuming | is an OR operator?
One way to think about the bitwise "and" and "or" operations are as ways to set (turn on) and reset (turn off) bits in your result.
You think as one operand as your "mask" - ones and zeros that represent what needs to be set or reset. The other operand is going to be "masked" by that "mask". In the following way:
If the operator is &, then each bit in the "mask" that is zero is going to be zero in the result. Each bit that is 1 is going to have the value from the other operand.
So for example result = x & 0b11111111_11111111_11111111_11110111 (that big number is our mask and I'm showing it in binary) is going to have all the bits the same as x, except the fourth bit from the right, which is going to be 0, no matter if it's 0 or 1 in x.
So doing & with a "mask" is considered to be a "bit-reset" operation, or a "zeroing" operation.
For the | (or) operator, you can think of it as a "bit-set" operation. Every bit in the mask that is 1 is going to be 1 in the result. Every bit that is 0 is going to have whatever is in the other operand. So in the result, all the bits that were 1 in the mask are going to be set.
For example result = x | 0b1000 is going to have all the bits that were in x, except the fourth bit from the right, which is going to be 1 regardless of what it was in x.
Writing masks in binary is long and is a pretty recent thing in Java, so you are more likely to see masks written in hexadecimal. In this case 0xfffffff7 for the & example, and 0x8 for the | example.
Now let's look at your expression with a "mask" point of view:
dst<<1 means shifting dst by 1. All its bits are moved one position to the left, and the rightmost bit is set to zero. In essence, this is "making room" for something in the rightmost bit.
In the right parenthesis, the shift operator has precedence, so it is evaluated first. src is moved srcPos positions to the right. So the bit that was srcPos+1 places from the right is now the rightmost bit.
Now we "mask" that with 0x01. That is, 0b00000000_00000000_00000000_00000001. This is an & mask, so everything that is not the rightmost bit is going to be zero. Only the rightmost bit is saved. The end result is that it's the bit that used to be in the srcPos+1 place in src, and only that bit - all the rests are reset.
And now we "mask" this with the dst<<1 thing that we prepared. Since it is an | operation, it's a "setting" mask. Our mask only has one significant bit - the one that we didn't erase in the & operation. And it is on the rightmost position. If it's 1, it will be 1 in the result, and if it's 0, it will be 0 in the result (because the left operand has zero in that position).
So basically what it does is:
Push the bits in dst to the left.
Place the bit from the srcPos + 1 place from the right in the rightmost bit of it.
If the values in table are all unique positions between 0 and srcWidth, then this will give you a scrambling of the bits of src - in each round one bit will be pushed into dst based on the value of table[i].
" | " is Binary OR Operator which copies a bit if it exists in either operand.
as an example :
A|B
will give 61 which is 0011 1101.
" || " is called Logical OR Operator. If any of the two operands are non-zero, then the condition becomes true. as an example:
(A || B) is true.
| is bitwise OR not a logical OR
A bitwise OR operates on every bit in that long individually. This changes it's value, which is not the same as defining it.
Breaking down this line:
dst = (dst<<1) | (src>>srcPos & 0x01);
dst<<1 // means left shift 1 place. The same as multiply by 2. Zeros lowest bit.
src>>srcPos // means right shift srcPos places. The same as divide by 2 to the srcPos
// this puts the selected bit in the lowest place
& 0x01 // means set every bit to zero except the rightmost one which will stay the same
(src>>srcPos & 0x01) // means give me the value of the src bit at srcPos
(dst<<1) | (src>>srcPos & 0x01); // means shift dst left and put a src bit at the end
Here the bitwise OR works like it's appending a bit. That only works because the bits that won't be used have been carefully zero'ed on each side.
As the loop goes around table is controlling what bit to sample from src and whatever it picks is appended to the right end of dst. Thus table controls how src is permuted.
I have an int 00000000000000000000000000001101 which represents 13 in base ten. I am trying to circular rotate the the bits by treating the 32 bit integer as a 4 bit integer because if I rotate the integer the value becomes very large. My desired answer after a right rotation of 2 for the above example would be 00000000000000000000000000000111 which is 7 in base 10.
Any help on doing this is greatly appreciated.
Try this:
x = (x >> 2) | ((x & 3) << 2);
This is just simulating the rotation via shifts and masks. I don't think there is anything better you could do, short of maybe making a lookup table (which may not actually be better); the CPU doesn't have opcodes for natively dealing with nybbles.
To rotate the lower 4 bits to the right by n, where n is 1, 2, or 3:
((x >> n) | (x << (4-n))) & 0xF;
The first part shifts the leftmost 4-n bits to the right; the second part shifts the rightmost n bits to the left. Then you or them together, and use & 0xF to zero extra bits that may have been set by the left shift.
I stumbled upon a question that asks whether you ever had to use bit shifting in real projects. I have used bit shifts quite extensively in many projects, however, I never had to use arithmetic bit shifting, i.e., bit shifting where the left operand could be negative and the sign bit should be shifted in instead of zeros. For example, in Java, you would do arithmetic bit shifting with the >> operator (while >>> would perform a logical shift). After thinking a lot, I came to the conclusion that I have never used the >> with a possibly negative left operand.
As stated in this answer arithmetic shifting is even implementation defined in C++, so – in contrast to Java – there is not even a standardized operator in C++ for performing arithmetic shifting. The answer also states an interesting problem with shifting negative numbers that I was not even aware of:
+63 >> 1 = +31 (integral part of quotient E1/2E2)
00111111 >> 1 = 00011111
-63 >> 1 = -32
11000001 >> 1 = 11100000
So -63>>1 yields -32 which is obvious when looking at the bits, but maybe not what most programmers would anticipate on first sight. Even more surprising (but again obvious when looking at the bits) is that -1>>1 is -1, not 0.
So, what are concrete use cases for arithmetic right shifting of possibly negative values?
Perhaps the best known is the branchless absolute value:
int m = x >> 31;
int abs = x + m ^ m;
Which uses an arithmetic shift to copy the signbit to all bits. Most uses of arithmetic shift that I've encountered were of that form. Of course an arithmetic shift is not required for this, you could replace all occurrences of x >> 31 (where x is an int) by -(x >>> 31).
The value 31 comes from the size of int in bits, which is 32 by definition in Java. So shifting right by 31 shifts out all bits except the signbit, which (since it's an arithmetic shift) is copied to those 31 bits, leaving a copy of the signbit in every position.
It has come in handy for me before, in the creation of masks that were then used in '&' or '|' operators when manipulating bit fields, either for bitwise data packing or bitwise graphics.
I don't have a handy code sample, but I do recall using that technique many years ago in black-and-white graphics to zoom in (by extending a bit, either 1 or 0). For a 3x zoom, '0' would become '000' and '1' would become '111' without having to know the initial value of the bit. The bit to be expanded would be placed in the high order position, then an arithmetic right shift would extend it, regardless of whether it was 0 or 1. A logical shift, either left or right, always brings in zeros to fill vacated bit positions. In this case the sign bit was the key to the solution.
Here's an example of a function that will find the least power of two greater than or equal to the input. There are other solutions to this problem that are probably faster, namly any hardware oriented solution or just a series of right shifts and ORs. This solution uses arithmetic shift to perform a binary search.
unsigned ClosestPowerOfTwo(unsigned num) {
int mask = 0xFFFF0000;
mask = (num & mask) ? (mask << 8) : (mask >> 8);
mask = (num & mask) ? (mask << 4) : (mask >> 4);
mask = (num & mask) ? (mask << 2) : (mask >> 2);
mask = (num & mask) ? (mask << 1) : (mask >> 1);
mask = (num & mask) ? mask : (mask >> 1);
return (num & mask) ? -mask : -(mask << 1);
}
Indeed logical right shift is much more commonly used. However there are many operations that require an arithmetic shift (or are solved much more elegantly with an arithmetic shift)
Sign extension:
Most of the time you only deal with the available types in C and the compiler will automatically sign extend when casting/promoting a narrower type to a wider one (like short to int) so you may not notice it, but under the hood a left-then-right shift is used if the architecture doesn't have an instruction for sign extension. For "odd" number of bits you'll have to do the sign extension manually so this would be much more common. For example if a 10-bit pixel or ADC value is read into the top bits of a 16-bit register: value >> 6 will move the bits to the lower 10 bit positions and sign extend to preserve the value. If they're read into the low 10 bits with the top 6 bits being zero you'll use value << 6 >> 6 to sign extend the value to work with it
You also need signed extension when working with signed bit fields
struct bitfield {
int x: 15;
int y: 12;
int z: 5;
};
int f(bitfield b) {
return (b.x/8 + b.y/5) * b.z;
}
Demo on Godbolt. The shifts are generated by the compiler but usually you don't use bitfields (as they're not portable) and operate on raw integer values instead so you'll need to do arithmetic shifts yourself to extract the fields
Another example: sign-extend a pointer to make a canonical address in x86-64. This is used to store additional data in the pointer: char* pointer = (char*)((intptr_t)address << 16 >> 16). You can think of this as a 48-bit bitfield at the bottom
V8 engine's SMI optimization stores the value in the top 31 bits so it needs a right shift to restore the signed integer
Round signed division properly when converting to a multiplication, for example x/12 will be optimized to x*43691 >> 19 with some additional rounding. Of course you'll never do this in normal scalar code because the compiler already does this for you but sometimes you may need to vectorize the code or make some related libraries then you'll need to calculate the rounding yourself with arithmetic shift. You can see how compilers round the division results in the output assembly for bitfield above
Saturated shift or shifts larger than bit width, i.e. the value becomes zero when the shift count >= bit width
uint32_t lsh_saturated(uint32_t x, int32_t n) // returns 0 if n == 32
{
return (x << (n & 0x1F)) & ((n-32) >> 5);
}
uint32_t lsh(uint32_t x, int32_t n) // returns 0 if n >= 32
{
return (x << (n & 0x1F)) & ((n-32) >> 31);
}
Bit mask, useful in various cases like branchless selection (i.e. muxer). You can see lots of ways to conditionally do something on the famous bithacks page. Most of them are done by generating a mask of all ones or all zeros. The mask is usually calculated by propagating the sign bit of a subtraction like this (x - y) >> 31 (for 32-bit ints). Of course it can be changed to -(unsigned(x - y) >> 31) but that requires 2's complement and needs more operations. Here's the way to get the min and max of two integers without branching:
min = y + ((x - y) & ((x - y) >> (sizeof(int) * CHAR_BIT - 1)));
max = x - ((x - y) & ((x - y) >> (sizeof(int) * CHAR_BIT - 1)));
Another example is m = m & -((signed)(m - d) >> s); in Compute modulus division by (1 << s) - 1 in parallel without a division operator
I am not too sure what you mean. BUt i'm going to speculate that you want to use the bit shift as an arithmetic function.
One interesting thing i have seen is this property of binary numbers.
int n = 4;
int k = 1;
n = n << k; // is the same as n = n * 2^k
//now n = (4 * 2) i.e. 8
n = n >> k; // is the same as n = n / 2^k
//now n = (8 / 2) i.e. 4
hope that helps.
But yes you want to be careful of negative numbers
i would mask and then turn it back accordingly
In C when writing device drivers, bit shift operators are used extensively since bits are used as switches that need to be turned on and off. Bit shift allow one to easily and correctly target the right switch.
Many hashing and cryptographic functions make use of bit shift. Take a look at Mercenne Twister.
Lastly, it is sometimes useful to use bitfields to contain state information. Bit manipulation functions including bit shift are useful for these things.
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?
I would think it is 00010010
i.e. it tries to maintain the sign bit as is
On the other hand, the logical left shift by 1 pos would be
10010010
Is this correct?
For left shift, arithmetic and logical shift are the same.
The difference is for right shift only, where an arithmetic right shift will copy the old MSB to the new MSB after having shifted, thus keeping a negative number from being converted to a positive when shifting.
Wikipedia has a more detailed explanation.
In Java << is a logical left-shift. 0 is always added as the LSB.
(Do note that Java will promote the [byte] value in question, so care must be taken to mask back to an octect! Otherwise you'll keep the shifted bit(s), which might have included "1".)
However, the Wikipedia article on Arithmetic shift indiciates that an arithmetic left shift may result in an overflow error:
...Note that arithmetic left shift may cause an overflow; this is the only way it differs from logical left shift.
(This is not the case in Java, but just to keep in mind.)
Happy coding.
Yes it is correct.
The arithmetic left shift of x by n places is equal to x * (2^n). So in your example is the ar-left-shift of 01001001 by 1 place equal to 10010010 (73 * 2¹ = 146).
You are correct when you left shift by 1 bit postion. It equals 10010010.
when you shift 4 bits to the left as follows, you get the following answer.
01001001 << 4 = 10010000
when you shift 4 bits to the right as follows, you get the following answer.
01001001 >> 4 = 00000100
Bits that are left empty as a result of shifting are filled with zeros.