Okay, I tried looking up what >>, or shift means, but it's way over my head as this site explains it: http://www.janeg.ca/scjp/oper/shift.html
What would the explanation be, if talking to a kid?
Computers are binary devices. Because of this, numbers are represented by a sequence of 1s and 0s.
Bitshifting is simply moving those sequences of 1s and 0s left or right.
So all the >> operator does is shift the bits towards the right one bit.
Consider the number 101:
// Assuming signed 8-bit integers
01100101 // How 101 is represented in binary
00110010 // After right shifting one bit, this represents 50
The least significant bit in this case was truncated. Obviously the devil's in the details, but that's all there is really to it.
The << operator does the opposite operation:
// Assuming signed 8-bit integers
01100101 // How 101 is represented in binary
11001010 // After left shifting one bit, this represents -54
// Assuming unsigned 8-bit integers
01100101 // How 101 is represented in binary
11001010 // After left shifting one bit, this represents 202
In this case, the most significant bit was truncated since I used only 8-bits. If the number had more bits, however:
// Assuming signed 16-bit integers
00000000 01100101 // How 101 is represented in binary
00000000 11001010 // After left shifting one bit, this represents 202
00000001 10010100 // After left shifting one bit again, this represents 404
So you may get different numbers depending on how many bits and the data types associated with those bits you're dealing with.
Addendum: If you're wondering how binary works, think about how the decimal number system works. Consider the number 5287. It can be written like this:
5287
But you can also write it out like this:
5287 = (5 * 1000) + (2 * 100) + (8 * 10) + (7 * 1)
Which you can then write out like this:
5287 = (5 * 10^3) + (2 * 10^2) + (8 * 10^1) + (7 * 10^0)
The above equation explains why the decimal number system is sometimes called the base-10 system. The decimal number system employs the use of 10 digits (0-9). Notice how the exponents correspond to digit position.
The binary number system, or the base-2 system, is the exact same thing but with the number two as the base of the exponents, and employing only two digits: 0 and 1.
5287 = 00010100 10100111 (base 2)
= (0 * 2^15) + (0 * 2^14) + (0 * 2^13) + (1 * 2^12)
+ (0 * 2^11) + (1 * 2^10) + (0 * 2^9) + (0 * 2^8)
+ (1 * 2^7) + (0 * 2^6) + (1 * 2^5) + (0 * 2^4)
+ (0 * 2^3) + (1 * 2^2) + (1 * 2^1) + (1 * 2^0)
Can I assume the kid I'm talking to knows a bit about binary? :)
All numbers can be represented in some kind of binary, like so:
Base 10 : Base 2
1 : 0001
2 : 0010
3 : 0011
4 : 0100
5 : 0101
6 : 0110
7 : 0111
8 : 1000
...
and so on.
The shift operators basically move all of the bits (1s or 0s) across one position. So, for example:
000111 >> 1
shifts all the bits in 000111 right by one number to produce this:
000011
000111 << 1
shifts all those bits left by one, to produce this:
001110
If you shift by more than one, then it just moves the bits further.
Now, depending on what language you're using and the kind of numbers you're working with, it can be a little bit more complicated than that. For example, if you are working in a language where the "most significant bit" (the one furthest to the left in a number) represents whether the number is signed or not, then the language will have to take that into account.
Mathematically speaking, if you take an integer (and ignore the risk of overflows, which are caused by the computer running out of space to store bits,) shift left by 1 (<< 1) is the equivalent of multiplying by 2, and shift right by 1 is the equivalent of dividing by 2. (Think a bit about what a "place value" in binary maths is worth, and that'll make sense)
>> the SHIFT RIGHT operator
Example:
class X
{
public static void main(String args[])
{
System.out.println("20>>2 = "+20>>2);
}
}
Output : 20>>2 = 5
Explanation:
Binary value of 20 is: 00000000000000000000000000010100
shift all bits 2 positions to right 00000000000000000000000000000101
It will give 5 ( 1*2^2 + 0*2^1 + 1*2^0 )
I once wrote an JApplet (bitorgel) and put it on my web page, where one can play around with bit operators. You can try it live, or download the source. AFAIK they work the same in C, C++ and Java - probably in C# too.
Related
This question already has answers here:
How are integers cast to bytes in Java?
(8 answers)
Type casting into byte in Java
(6 answers)
Explicit conversion from int to byte in Java
(4 answers)
Closed 4 months ago.
For example of this is my input:
byte x=(byte) 200;
This will be the output:
-56
if this is my input:
short x=(short) 250000;
This will be the output:
-12144
I realize that the output is off because the number does not fit into the datatype, but how can I predict what this output will be in this case? In my computer science exam this my be one of the questions and I do not understand why exactly 200 changes to -56 and so one.
I realize that the output is off because the number does not fit into the datatype, but how can I predict what this output will be in this case? In my computer science exam this my be one of the questions and I do not understand why exactly 200 changes to -56 and so one.
The relevant aspects are what overflow looks like, and how the bits that represent the underlying data are treated.
Computers are all bits, grouped together in groups of 8; a group of 8 bits is called a byte.
byte b = 5; for example, is stored in memory as 0000 0101.
Bits can be 0. Or 1. That's it. That's where it ends. And everything is, in the end, bits. This means: That - is not a thing. Computers do not know what - is and cannot store it. We need to write code and agree on some sort of meaning to represent them.
2's complement
So what's -5 in bits? It's 1111 1011. Which seems bizarre. But it's how it works. If you write: byte b = -5;, then b will contain 1111 1011. It is because javac made that happen. Similarly, if you then call System.out.println(b), then the println method gets the bit sequence 1111 1011. Why does the println method decide to print a - symbol and then a 5 symbol? Because it's programmed that way: We all are in agreement that 1111 1011 is -5. So why is that?
Because of a really cool property - signed/unsigned irrelevancy.
The rule is 2's complement: To switch the sign (i.e. turn 5, which is 0000 0101 into -5 which is 1111 1011), you flip every bit, and then add 1 to the end result. Try it with 0000 0101 - and you'll see it's 1111 1011. This algorithm is reversible - apply the same algorithm (flip every bit, then add 1) and you can turn -5 into 5.
This 2's complement thing has 2 great advantages:
There is only one 0 value. If we just flipped all bits, we'd have both 1111 1111 and 0000 0000 both representing some form of 0. In basic math, there's no such thing as 'negative 0' - it's the same as positive 0. Similarly if we just decided the first bit is the sign and the remaining 7 bits are the number, then we'd have both 1000 0000 and 0000 0000 both being 0, which is annoying and inefficient, why waste 2 different bit sequences on the same number?
plus and minus are sign-mode independent. The computer doesn't have to KNOW whether we are doing the 2's complement thing or not. Take the bit sequence 1111 1011. If we treat that as unsigned bits, then that is 251 (it's 128 + 64 + 32 + 16 + 8 + 2 + 1). If we treat that as a signed number, then the first bit is 1, so the thing is negative: We apply 2's complement and figure out that it is -5. So, is it -5 or 251? It's both, at once! Depends on the human/code that interprets this bit sequence which one it is. So how could the computer possibly do a + b given this? The weird answer is: It doesn't matter - because the math works out the same way. 251 - 10 is 241. -5 - 10 is -15. -15 and 241 are the exact same bit sequence.
Overflow
A byte is 8 bits, and there are 256 different sequences of bits, and then you have listed each and every possible variant. (2^8 = 256. Hence, a 16-bit number can be used to convey 65536 different things, because 2^16 is 65536, and so on). So, given that bytes are 8 bits and we decreed they are signed, and 2's complement signed, that means that the smallest number you can send with it is -128, which in bits is 1000 0000 (use 2's complement to check my work), and +127, which in bits is 0111 1111. So what happens if you add 1 to 127? That'd seemingly be +128 except that's not storable in 8 bits if we decree that we interpret these bits as 2's complement signed (which java does). What happens? The bits 'roll over'. We just add 1 as normal, which turns 0111 1111 into 1000 0000 which is -128:
byte b = 127;
b = (byte)(b + 1);
System.out.println(b); // prints -128
Imagine the number line - stretching out into infinity on both ends, from -infinite to +infinite. That's the usual way math works. Computers (or rather, int, long, etc) do not work like that. Instead of a line, it is a circle. Take your infinite number line and take some scissors, and snip that number line at -128 (because a 2's comp signed byte cannot represent -129 or anything else below -128), and at +127 (because our byte cannot represent 128 or anything above it).
And now tape the 2 cut ends together.
That's the number line. What's 'to the right' of 125? 126 - that's what +1 means: Move one to the right on the number line.
What's 'to the right' of +127? Why, -128. Because we taped it together.
Similarly, -127 - 5 is +123. '-5' is 'move 5 places to the left on the number line (or rather, number circle)'. Going in 1 decrements:
-127 (we start here)
-128 (-127 -1)
+127 (-127 -2)
+126 (-127 -3)
+125 (-127 -4)
+124 (-127 -5)
Hence, 124.
Same math applies to short (-32768 to +32767), char (which is really a 16-bit unsigned number - so 0 to 65535), int (-2147483648 to +2147483647), and even long (-2^63 to +2^63-1 - those get a little large).
short x = 32765;
x += 5;
System.out.println(x); // prints -32766.
This question already has answers here:
How does bitshifting work in Java?
(10 answers)
Closed 2 years ago.
Actually I know the declaration of array in java but here I am unable to understand the use of this syntax:
int a[] = new int[3 << 1];
In place of a size for the array, here << this symbol is used for?
The << symbol is known as the "left shift operator." As you can probably guess, it gets its name from shifting bit positions to the left.
There's a good example posted by another user at the following:
How do shift operators work in Java?
Right shift and left shift operators shift your number to the right of left in their binary representation. If you left shift by one the number 3 3<<1 this would mean that:
The binary for 3 which is 011 gets shifted to the left(basically a 0 is added in the front) 0110 and now your number is 6.
The opposite thing would happen with right shift: If you have the number 3 011 and you right shift it by 1 3>>1 the first bit will get chopped off 01 and you'll end up with the number 1.
Shift operators are useful for multiplying or dividing by powers of 2, and it's a bit faster than just saying 3*2.
<< is the left shift operator and belongs to the bitwise and bit shift operators. For a detailed explanation of how each bitwise and bit shift operator works, please refer to this answer by #DerekPark. Thus, 3 << 1 is an arthmetic expression that gets evaluated before the array is created. 3 << 1 evaluates to 6, thus an int[] of size 6 gets created.
Ideone Demo
<< is the bitwise left shift operator and is often used for efficiently multiplying for specific powers of two, as bitwise operators tend to be faster. x << n is usually equivalent to x*2n, except for cases involving int overflow.
3 in binary is represented as 11 and after shifting to the left by one, it becomes 110, which is 6 in decimal. It can be seen intuitively that shifting by n places to the left is equivalent to multiplying by two n times, as each shift adds a binary digit to the right, which increases the value of every other digit by a factor of 2.
I am new to bytes and bits and I'm also not very good in maths either. I kind of understand the bitwise operators, but I don't know how to solve math equations/formulas with 2 variables. I'm not sure this is the proper place to ask this but anyway.
I have an formula like this:
(Adr_MSB & 0x3F) << (8 + Adr_LSB)
Now what I want is that I would get an integer (for example 33) and the code would transform it into Adr_MSB and Adr_LSB (which are bytes).
It should work up to 128 (ok I guess it will be 127).
I know that this question might sound dumb or something, but I just don't know enough maths to solve this.
Thanks for all help.
EDIT: By experimenting I figured out, that Adr_MSB is a multiplier (e.g. if it's 10 the result is 10 times biger than if it's 1).
From what I understand
the (Adr_MSB & 0x3F) part of the takes the last six bits of the Adr_MSB and returns corresponding integer.
Eg: 125 (1111101) will return 61 (111101)
Note: This step is removing all bits other than last 6 bits, these bits are lost. Hence Lossless inverse function is not possible.
The (8 + Adr_LSB) just adds 8 to Adr_LSB.
<< is a bit wise Left Shift Operator.
Eg. 61 << 3 = 488 . Since 61 is 111101, adding three zeros to the right (Left Shifting three times) will give 111101000 which is 488.
Effective inverse of the expression (Adr_MSB & 0x3F) << (8 + Adr_LSB) to be applied to given number x
Take first six bits from x and convert it to int. This will be Adr_MSB.
Count the rest of the bits. Subtract 8 from this count and it will be Adr_LSB.
Does the following represent what you are looking for?
((Adr_MSB & 0x3F) << 8) | Adr_LSB
Would this work?
int x = 33;
byte Adr_MSB = (byte)x;
byte Adr_LSB = (byte)24;
System.out.println((Adr_MSB & 0x3F) << (8 + Adr_LSB));
Adr_LSB can also be -8.
Since you do bitwise AND on Adr_MSB and 111111, you have only six consecutive bits available to represent the number, so not all integers can be represented just by shifting those 6 bits. This solution works for x up to , so... you can argue that is not a good solution, but it is a start.
I confused with an operator which provides arithmetic shifts <<, >> in Java
For example I have this binary number:
0000 0101 // It is actually 5 in dec system
And now I want to shift this number to the left by 2 positions. I am doing this ( this is only concept of shifting bits) :
0000 0101 << 2
And now I do not know: if I need to shift high bit by 2 positions and fill with zero in right side OR I need to shift whole number (101) by 2 positions?
Second option :)
For instance, 0110001 << 2 = 1000100
The other operators are:
signed right shift (>>).
0011001 >> 2 = 0000110
1011001 >> 2 = 1110110
The leftmost bit is used as left padding. This is done to propagate the sign bit (highest bit).
unsigned right shift (>>>)
1110001 >> 2 = 0011100
Since the number is considered unsigned, there is nothing to propagate, just pad with zeros!
I need a little explanation of the following statement, What is it doing?:
int result = 154 + (153 << 8) + (25 << 16) + (64 << 24);
/* what would be the value of result after this line and how it is calculated
Why we need this? */
(153 << 8) is equivalent to 153 * pow(2, 8)
You are actually shifting your bits towards left..
Also: -
(153 >> 8) is equivalent to 153 / pow(2, 8)
You can guess why.. This is actually shifting bits towards right..
E.G: -
3 => 0011
3 << 2 is equal to 1100 -> (Which is code for 12)
3 >> 2 is equal to 0000 -> (Which is code for 0) -> you can see - **(3 / 4 = 0)**
NOTE :- Note that the right shifting rounds off towards negative infinity..
For E.G: -
-3 >> 1 --> -2 (-1.5 is rounded to -2)
Lets see how it happens: -
In binary string representation: -
-3 ==> 11111111111111111111111111111101
-3 >> 1 ==> 11111111111111111111111111111110 (-3 / 2 = -1.5 -> rounded to -2)
(Note the left most bit is filled by the bit that was present at the left most end before shift (1 in this case))
So, the value becomes, -2 (for -3>>1, which is greater than -3)
This happens for negative numbers.. Right shifting a negative number gives a number greater than the original number..
Which is contrary to the positive number where the left most bit will be filled by 0... Thus value obtained will be less than the original..
3 ==> 00000000000000000000000000000011
3 >> 1 ==> 00000000000000000000000000000001 (3 / 2 = 1.5 -> rounded to 1)
(So left most bit remains 0. So, the value is 1 (less than 3), i.e., value is rounded off towards negative infinity and becomes 1 from 1.5)
Similarly you can devise results for left-shifting positive and negative number..
The answer is 1075419546. The left shift operator is basically addings 0s to the binary representations of the decimal numbers so this would simply to
154 + 153 * 2^8 + 25 * 2^16 + 64*2^24
So you can convert 153 to its binary representation, then add 8 zeros and convert back to decimal etc etc..
in practical terms, if you use the given operator on a math expression it has the same meaning as the following:
123 << n is exactly the same as 123 * 2 ^ n
For example, 2 << 2 is 2 * 2 ^ 2 which is 8 or the same as 1000
Otherwise, you are just shifting bits to the left:
3 = 11 then 3 << 2 = 1100.
Hope it makes it clear.