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.
Related
What function does the ^ (caret) operator serve in Java?
When I try this:
int a = 5^n;
...it gives me:
for n = 5, returns 0
for n = 4, returns 1
for n = 6, returns 3
...so I guess it doesn't perform exponentiation. But what is it then?
The ^ operator in Java
^ in Java is the exclusive-or ("xor") operator.
Let's take 5^6 as example:
(decimal) (binary)
5 = 101
6 = 110
------------------ xor
3 = 011
This the truth table for bitwise (JLS 15.22.1) and logical (JLS 15.22.2) xor:
^ | 0 1 ^ | F T
--+----- --+-----
0 | 0 1 F | F T
1 | 1 0 T | T F
More simply, you can also think of xor as "this or that, but not both!".
See also
Wikipedia: exclusive-or
Exponentiation in Java
As for integer exponentiation, unfortunately Java does not have such an operator. You can use double Math.pow(double, double) (casting the result to int if necessary).
You can also use the traditional bit-shifting trick to compute some powers of two. That is, (1L << k) is two to the k-th power for k=0..63.
See also
Wikipedia: Arithmetic shift
Merge note: this answer was merged from another question where the intention was to use exponentiation to convert a string "8675309" to int without using Integer.parseInt as a programming exercise (^ denotes exponentiation from now on). The OP's intention was to compute 8*10^6 + 6*10^5 + 7*10^4 + 5*10^3 + 3*10^2 + 0*10^1 + 9*10^0 = 8675309; the next part of this answer addresses that exponentiation is not necessary for this task.
Horner's scheme
Addressing your specific need, you actually don't need to compute various powers of 10. You can use what is called the Horner's scheme, which is not only simple but also efficient.
Since you're doing this as a personal exercise, I won't give the Java code, but here's the main idea:
8675309 = 8*10^6 + 6*10^5 + 7*10^4 + 5*10^3 + 3*10^2 + 0*10^1 + 9*10^0
= (((((8*10 + 6)*10 + 7)*10 + 5)*10 + 3)*10 + 0)*10 + 9
It may look complicated at first, but it really isn't. You basically read the digits left to right, and you multiply your result so far by 10 before adding the next digit.
In table form:
step result digit result*10+digit
1 init=0 8 8
2 8 6 86
3 86 7 867
4 867 5 8675
5 8675 3 86753
6 86753 0 867530
7 867530 9 8675309=final
As many people have already pointed out, it's the XOR operator. Many people have also already pointed out that if you want exponentiation then you need to use Math.pow.
But I think it's also useful to note that ^ is just one of a family of operators that are collectively known as bitwise operators:
Operator Name Example Result Description
a & b and 3 & 5 1 1 if both bits are 1.
a | b or 3 | 5 7 1 if either bit is 1.
a ^ b xor 3 ^ 5 6 1 if both bits are different.
~a not ~3 -4 Inverts the bits.
n << p left shift 3 << 2 12 Shifts the bits of n left p positions. Zero bits are shifted into the low-order positions.
n >> p right shift 5 >> 2 1 Shifts the bits of n right p positions. If n is a 2's complement signed number, the sign bit is shifted into the high-order positions.
n >>> p right shift -4 >>> 28 15 Shifts the bits of n right p positions. Zeros are shifted into the high-order positions.
From here.
These operators can come in handy when you need to read and write to integers where the individual bits should be interpreted as flags, or when a specific range of bits in an integer have a special meaning and you want to extract only those. You can do a lot of every day programming without ever needing to use these operators, but if you ever have to work with data at the bit level, a good knowledge of these operators is invaluable.
It's bitwise XOR, Java does not have an exponentiation operator, you would have to use Math.pow() instead.
XOR operator rule =>
0 ^ 0 = 0
1 ^ 1 = 0
0 ^ 1 = 1
1 ^ 0 = 1
Binary representation of 4, 5 and 6 :
4 = 1 0 0
5 = 1 0 1
6 = 1 1 0
now, perform XOR operation on 5 and 4:
5 ^ 4 => 1 0 1 (5)
1 0 0 (4)
----------
0 0 1 => 1
Similarly,
5 ^ 5 => 1 0 1 (5)
1 0 1 (5)
------------
0 0 0 => (0)
5 ^ 6 => 1 0 1 (5)
1 1 0 (6)
-----------
0 1 1 => 3
It is the XOR bitwise operator.
Lot many people have already explained about what it is and how it can be used but apart from the obvious you can use this operator to do a lot of programming tricks like
XORing of all the elements in a boolean array would tell you if the array has odd number of true elements
If you have an array with all numbers repeating even number of times except one which repeats odd number of times you can find that by XORing all elements.
Swapping values without using temporary variable
Finding missing number in the range 1 to n
Basic validation of data sent over the network.
Lot many such tricks can be done using bit wise operators, interesting topic to explore.
XOR operator rule
0 ^ 0 = 0
1 ^ 1 = 0
0 ^ 1 = 1
1 ^ 0 = 1
Bitwise operator works on bits and performs bit-by-bit operation. Assume if a = 60 and b = 13; now in binary format they will be as follows −
a = 0011 1100
b = 0000 1101
a^b ==> 0011 1100 (a)
0000 1101 (b)
------------- XOR
0011 0001 => 49
(a ^ b) will give 49 which is 0011 0001
As others have said, it's bitwise XOR. If you want to raise a number to a given power, use Math.pow(a , b), where a is a number and b is the power.
AraK's link points to the definition of exclusive-or, which explains how this function works for two boolean values.
The missing piece of information is how this applies to two integers (or integer-type values). Bitwise exclusive-or is applied to pairs of corresponding binary digits in two numbers, and the results are re-assembled into an integer result.
To use your example:
The binary representation of 5 is 0101.
The binary representation of 4 is 0100.
A simple way to define bitwise XOR is to say the result has a 1 in every place where the two input numbers differ.
With 4 and 5, the only difference is in the last place; so
0101 ^ 0100 = 0001 (5 ^ 4 = 1) .
It is the Bitwise xor operator in java which results 1 for different value of bit (ie 1 ^ 0 = 1) and 0 for same value of bit (ie 0 ^ 0 = 0) when a number is written in binary form.
ex :-
To use your example:
The binary representation of 5 is 0101.
The binary representation of 4 is 0100.
A simple way to define Bitwise XOR is to say the result has a 1 in every place where the two input numbers differ.
0101 ^ 0100 = 0001 (5 ^ 4 = 1) .
To perform exponentiation, you can use Math.pow instead:
https://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Math.html#pow%28double,%20double%29
As already stated by the other answer(s), it's the "exclusive or" (XOR) operator. For more information on bit-operators in Java, see: http://java.sun.com/docs/books/tutorial/java/nutsandbolts/op3.html
That is because you are using the xor operator.
In java, or just about any other language, ^ is bitwise xor,
so of course,
10 ^ 1 = 11.
more info about bitwise operators
It's interesting how Java and C# don't have a power operator.
It is the bitwise xor operator in java which results 1 for different value (ie 1 ^ 0 = 1) and 0 for same value (ie 0 ^ 0 = 0).
^ is binary (as in base-2) xor, not exponentiation (which is not available as a Java operator). For exponentiation, see java.lang.Math.pow().
It is XOR operator. It is use to do bit operations on numbers. It has the behavior such that when you do a xor operation on same bits say 0 XOR 0 / 1 XOR 1 the result is 0. But if any of the bits is different then result is 1.
So when you did 5^3 then you can look at these numbers 5, 6 in their binary forms and thus the expression becomes (101) XOR (110) which gives the result (011) whose decimal representation is 3.
As an addition to the other answers, it's worth mentioning that the caret operator can also be used with boolean operands, and it returns true (if and only if) the operands are different:
System.out.println(true ^ true); // false
System.out.println(true ^ false); // true
System.out.println(false ^ false); // false
System.out.println(false ^ true); // true
^ = (bitwise XOR)
Description
Binary XOR Operator copies the bit if it is set in one operand but not both.
example
(A ^ B) will give 49 which is 0011 0001
In other languages like Python you can do 10**2=100, try it.
I have something like this:
byte[0] = 0001 0100 0011 0100 (dec value: 5172)
byte[1] = 0000 0000 0111 1100 (dec value: 124)
byte[2] = 0000 0000 0000 0000 (dec value: 0)
byte[3] = 0000 0000 0000 0000 (dec value: 0)
I would like to combine them and make one long value in Java. How to do that?
Can it be converted on this way?
result = 0 + (0 x 2^16) + (0 x 2^16) + (124 x 2^32) + (5127 x 2^48)
ie.
result = byte[3] + (byte[2] x 2^16) + (byte[1] x 2^32) + (byte[0] x 2^48)
Edit: Let me try to explain better. When I open tool ModScan32 and connect to my device I see some registers. In this tool there are different kind of options how to show data. One of them are to represent them as binary or decimal. When I choose binary or decimal I get values as they are in my example above. When I read this data with my software I get exactly the same (converted values) in the decimal. Now my question is if it is necessary to hold data in 4 16 bit registers and i know their decimal values what is the proper way to combine those values from registers and get real value?
Your idea is basically OK. There are a few things to be aware of.
I believe the result you are after in your case is 0001010000110100000000000111110000000000000000000000000000000000.
Here’s an attempt that does not work:
int[] registers = { 5172, 124, 0, 0 };
long result = registers[0] << 48 | registers[1] << 32 | registers[2] << 16 | registers[3];
System.out.println(Long.toBinaryString(result));
<< 48 means shift 48 bits to the left, that should be good enough, right? | is a bitwise logical or, it fills the 1 bits from either operand into the same bit posistion of the result. You could use + instead if you preferred.
This prints:
10100001101000000000001111100
We only have the first 32 bits of the result, that’s not good enough. When trying to read it, note that Long.toBinaryString() does not include leading zeroes. Just imagine 3 zeroes in front of the number.
But what went worng? Where did the last 32 bits go? Even when they were all zeroes. The problem is that we are doing the calculation in ints, they are 32 bits, not 64. EDIT: My previous explanation was not entirely correct on this point. The truth is: When doing << on an int, only the last 5 bits of the right operand are considered, so since 48 is 110000 in binary, only 10000 is used, so the shift is the same as << 16. Similarly << 32 is the same as << 0, no shift at all. So registers[0] and [1] have ended up in the wrong bit posistion. The solution is easy when you know it: we need to convert to long before doing the calculation. Now the last 6 bits of the right operand are used, so 48 and 32 are understood as 48 and 32:
long result = ((long) registers[0]) << 48 | ((long) registers[1]) << 32 | registers[2] << 16 | registers[3];
This time we get
1010000110100000000000111110000000000000000000000000000000000
Again, imagine 3 zero bits in front and all is as expected.
There is one more thing. Say you got a negative value from a register, for example:
int[] registers = { 5172, -124, 0, 0 };
The calculation that just worked now gives us
1111111111111111111111111000010000000000000000000000000000000000
This time there are 64 bits printed, so it’s easy to see there are too many 1s in the beginning. They come from the int representation of -124. The solution is to mask them out:
int[] registers = { 5172, -124, 0, 0 };
long result = ((long) registers[0] & 0xFFFF) << 48
| ((long) registers[1] & 0xFFFF) << 32
| (registers[2] & 0xFFFF) << 16
| (registers[3] & 0xFFFF);
System.out.println(Long.toBinaryString(result));
0xFFFF is 16 1 bits, and & is the bitwise logical ‘and’, giving a 1 bit in the result only in positions where both operands have a 1 bit. Now -124 gets masked to 1111111110000100 so the result is the expected:
1010000110100111111111000010000000000000000000000000000000000
That should do it.
I executed this (~(1 << 3)) statement and I am getting -9 as a result.
Statement : (~(1 << 3))
Result : -9
Numbers in computers are stored in 2's complement form.
Your original number is 1,which is 0...0001 in binary. I'm skipping bit 4 to 30 as they all will be zero (consider 32-bit system).
Doing 1 << 3 will yield 0...1000 i.e. +8. In simple terms, it means multiply 1 by 2^i, where i = 3 here.
Now, inverting this yields 1111 1111 1111 1111 1111 1111 1111 1000 which is a negative number in 2's complement form.
To get the value of the number, drop the first 1(sign bit), invert the entire number again and add 1.
So, inverting again will give you 0...1000. Add 1 to this, so 0...1001.
This is the value of the number which is 9. And sign is negative because the first sign bit is 1.
<< is the left-shift operator, which in simple terms, when applied to a number, multiplies it by 2^i, where i is the number of bits to be shifted, for example :
1 << 3 = 8 (multiply 1 by 2^3)
2 << 4 = 32 (multiply 2 by 2^4)
and ~ is the NOT operator, which takes each bit in a number and toggles it. In simple terms, ~x = -x - 1 For example :
~100102 = 011012
~8 = -9
Now coming to your question, (~(1 << 3)) = (~8) = -9. For more info, check this answer : NOT(~) vs NEGATION(!).
Line 294 of java.util.Random source says
if ((n & -n) == n) // i.e., n is a power of 2
// rest of the code
Why is this?
Because in 2's complement, -n is ~n+1.
If n is a power of 2, then it only has one bit set. So ~n has all the bits set except that one. Add 1, and you set the special bit again, ensuring that n & (that thing) is equal to n.
The converse is also true because 0 and negative numbers were ruled out by the previous line in that Java source. If n has more than one bit set, then one of those is the highest such bit. This bit will not be set by the +1 because there's a lower clear bit to "absorb" it:
n: 00001001000
~n: 11110110111
-n: 11110111000 // the first 0 bit "absorbed" the +1
^
|
(n & -n) fails to equal n at this bit.
The description is not entirely accurate because (0 & -0) == 0 but 0 is not a power of two. A better way to say it is
((n & -n) == n) when n is a power of two, or the negative of a power of two, or zero.
If n is a power of two, then n in binary is a single 1 followed by zeros.
-n in two's complement is the inverse + 1 so the bits lines up thus
n 0000100...000
-n 1111100...000
n & -n 0000100...000
To see why this work, consider two's complement as inverse + 1, -n == ~n + 1
n 0000100...000
inverse n 1111011...111
+ 1
two's comp 1111100...000
since you carry the one all the way through when adding one to get the two's complement.
If n were anything other than a power of two† then the result would be missing a bit because the two's complement would not have the highest bit set due to that carry.
† - or zero or a negative of a power of two ... as explained at the top.
You need to look at the values as bitmaps to see why this is true:
1 & 1 = 1
1 & 0 = 0
0 & 1 = 0
0 & 0 = 0
So only if both fields are 1 will a 1 come out.
Now -n does a 2's complement. It changes all the 0 to 1 and it adds 1.
7 = 00000111
-1 = NEG(7) + 1 = 11111000 + 1 = 11111001
However
8 = 00001000
-8 = 11110111 + 1 = 11111000
00001000 (8)
11111000 (-8)
--------- &
00001000 = 8.
Only for powers of 2 will (n & -n) be n.
This is because a power of 2 is represented as a single set bit in a long sea of zero's.
The negation will yield the exact opposite, a single zero (in the spot where the 1 used to be) in a sea of 1's. Adding 1 will shift the lower ones into the space where the zero is.
And The bitwise and (&) will filter out the 1 again.
In two's complement representation, the unique thing about powers of two, is that they consist of all 0 bits, except for the kth bit, where n = 2^k:
base 2 base 10
000001 = 1
000010 = 2
000100 = 4
...
To get a negative value in two's complement, you flip all the bits and add one. For powers of two, that means you get a bunch of 1s on the left up to and including the 1 bit that was in the positive value, and then a bunch of 0s on the right:
n base 2 ~n ~n+1 (-n) n&-n
1 000001 111110 111111 000001
2 000010 111101 111110 000010
4 000100 111011 111100 000100
8 001000 110111 111000 001000
You can easily see that the result of column 2 & 4 is going to be the same as column 2.
If you look at the other values missing from this chart, you can see why this doesn't hold for anything but the powers of two:
n base 2 ~n ~n+1 (-n) n&-n
1 000001 111110 111111 000001
2 000010 111101 111110 000010
3 000011 111100 111101 000001
4 000100 111011 111100 000100
5 000101 111010 111011 000001
6 000110 111001 111010 000010
7 000111 111000 111001 000001
8 001000 110111 111000 001000
n&-n will (for n > 0) only ever have 1 bit set, and that bit will be the least significant set bit in n. For all numbers that are powers of two, the least significant set bit is the only set bit. For all other numbers, there is more than one bit set, of which only the least significant will be set in the result.
It's property of powers of 2 and their two's complement.
For example, take 8:
8 = 0b00001000
-8 = 0b11111000
Calculating the two's complement:
Starting: 0b00001000
Flip bits: 0b11110111 (one's complement)
Add one: 0b11111000
AND 8 : 0b00001000
For powers of 2, only one bit will be set so adding will cause the nth bit of 2n to be set (the one keeps carrying to the nth bit). Then when you AND the two numbers, you get the original back.
For numbers that aren't powers of 2, other bits will not get flipped so the AND doesn't yield the original number.
Simply, if n is a power of 2 that means only one bit is set to 1 and the others are 0's:
00000...00001 = 2 ^ 0
00000...00010 = 2 ^ 1
00000...00100 = 2 ^ 2
00000...01000 = 2 ^ 3
00000...10000 = 2 ^ 4
and so on ...
and because -n is a 2's complement of n (that means the only bit which is 1 remains as it is and the bits on left side of that bit are sit to 1 which is actually doesn't matter since the result of AND operator & will be 0 if one of the two bits is zero):
000000...000010000...00000 <<< n
&
111111...111110000...00000 <<< -n
--------------------------
000000...000010000...00000 <<< n
Shown through example:
8 in hex = 0x000008
-8 in hex = 0xFFFFF8
8 & -8 = 0x000008
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.