We Keep Coding

Value of y = x + x++ in Java [duplicate]

This question already has answers here:
Is there a difference between x++ and ++x in java?
(18 answers)
Java: pre-,postfix operator precedences
(5 answers)
Closed 6 years ago.
Say we have Java code below:
int x = 1;
int y = x + x++;
'Cause the precedence of "postfix-increment" operator is higher than "add" operator. I think x++ should be calculate and evaluated first. Then it comes to x + (x++). So the y should be "new_x(2) + 1 = 3".
Though it turns out "2" instead of "3". Any ideas? Thanks.
This question is greatly different from Is there a difference between x++ and ++x in java?. That question mentions nothing about the operator precedence.
Someone has explained that expression is read from left to right. Does it conflict with the precedence of those operators?
Just as I mentioned before, I think x++ should be calculated first. It seems that I mess up with the "evaluation" and "calculation".

The difference between x++ and ++x is quite evident and known. ++ can be used as preadd (Add 1 and then use x ) or postadd (use x and add 1).
Check this out.
As tested and seen
1. x + x++ will give 2
2. x + ++x will give 3
3. x++ + x will give 3
4. ++x + x will give 4
Now the interesting case here is 2nd and 4th which basically explains pre-add operator.
In these cases, the value of x is incremented first and then used in both the places.
However in case of test 2 the first operand i.e. x is already used up for addition so the answer is 3
while in the test 4 the operand x is first incremented and used in both the operands. This happens because the expressions are evaluated from left to right.

x++ would first return x then increment x.
++x would increment x first then return x.
Therefore :
int y = x + x++; //y (2) = x(1) + x(1, then becomes 2 right after)
int y = x + ++x; //y (3) = x(1) + x(becomes 2 before being returned)

Use of postfix/prefix expressions

I understand in prefix/postfix, there is no need to bother about precedence of operators.
But where do we use prefix/postfix expressions?
Are they internally converted by the compiler?
Is there a way I could write expression in prefix/postfix and the compiler evaluates it for me?

EDIT: Ff you're actually talking about postfix (RPN) notation, then no, the compiler uses infix notation for expressions. You could write an algorithm that converts an RPN expression into an infix expression, try this
Postfix and prefix operators are just like a binary operator, but they work on only one operand.
Postfix increment (the increment occurs after the variable is evaluated):
int x = 1;
int y = x++; // y = 1 but after the assignment occurs x = 2
int z = x; // z = 2
Prefix increment:
int x = 1;
int y = ++x; // y = 2 and before the assignment occurs x = 2
int z = x; // z = 2
The rules that apply to the increment operator also apply to the decrement operator.
Prefix NOT (inverts a boolean expression):
boolean a = true;
boolean b = !a; // b = false, a = true
I think I have understood the question correctly, but I'm not sure what you mean about the compiler "evaluating" them "for you".

I suspect that prefix and postfix operations and notations are mostly useful for theories these days, but they have been used "for real". See e.g. https://en.wikipedia.org/wiki/Stack_machine, https://en.wikipedia.org/wiki/Forth_%28programming_language%29, http://linux.about.com/library/cmd/blcmdl1_dc.htm, and https://en.wikipedia.org/wiki/Reverse_Polish_notation#Hewlett-Packard

Few languages use postfix notation (the only one I know of would be PostScript), but the resulting CPU instructions would be the same as for infix notation:
a = (3 + 4) * 5
or
a = * + 3 4 5
Would be converted (in an imaginary, very simple, instruction sets):
add r0 3 4 # r0 = 3 + 4
mul r1 r0 5 # r1 = r0 * 5
Your CPU does not care about the initial notation, all it accepts is a set of « basic » instructions, so the compiler has to convert the notation you use to instructions understandable by your CPU.

Why is the operator precedence not followed here? [duplicate]

This question already has answers here:
What are the rules for evaluation order in Java?
(5 answers)
If parenthesis has a higher precedence then why is increment operator solved first?
(5 answers)
Closed 7 years ago.
In this code:
int y = 10;
int z = (++y * (y++ + 5));
What I expected
First y++ + 5 will be executed because of the precedence of the innermost parentheses. So value of y will be 11 and the value of this expression will be 15. Then ++y * () will be executed. So 12 * 15 = 180. So z=180
What I got
z=176
This means that the VM is going from left to right not following operator precedence. So is my understanding of operator precedence wrong?

The expression (++y * (y++ + 5)); will be placed in a stack something like this:
1. [++y]
2. [operation: *]
3. [y++ + 5] // grouped because of the parenthesis
And it will be executed in that order, as result
1. 10+1 = [11] // y incremented
2. [operation: *]
3. 11+5 = [16] // y will only increment after this operation
The the expression is evaluated as
11 * 16 = 176

First y++ + 5 will be executed because of the precedence of the innermost parentheses
Precedence and evaluation order are not the same thing. All binary expressions except the assignment expression are evaluated left-to-right. Therefore y++ is evaluated before the parenthesized expression on the right.

The parentheses just describe how the sub-expressions will be grouped together. Parenthesizing doesn't mean it will be evaluated first. Rather, the rule in java is evaluate each sub-expression strictly from left to right.
Always remember that the order of evaluation has absolutely nothing to do with operator precedence and associativity.
Java Oracle documentation says that:
15.7. Evaluation Order
The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.
Therefore, the expression (++y * (y++ + 5)) will be evaluated as
temp1 = ++y = 11
temp2 = y++ + 5 = 11 + 5 = 16
z = temp1*temp2 = 11*16 = 176
Further reading: Eric Lippert's blog, Precedence vs Associativity vs Order, explained in detailed about precedence, associativity and order of evaluation. Though this blog addresses c# but equally valid for java too.

First will be executed ++y. y will be 11.
Then will be executed y + 5 (actually y++ + 5 can be written as 5 + y++ which is interpreted as (5 + y) and then y++). z will become 11 * 16 = 176.
y will be 12 after the calculation finishes.

The calculation is going on following order
z= (++10 * (10++ + 5))
z= (11 * (11 + 5))//++ (prefix or postfix) has higher precedence than + or *
z= (11 * 16)
z= 176

Data values and types

Given:
int x = 10;
double d = -3.0;
boolean f = false;
1.
Why does the following remain a double after it is cast as an int... For the second one also, why does it output a float when defined as a long?:
(int) d / 2.0
(long) d * 2f
2.
Why does the first of the following print a string(?), and the latter a number?
"2" + x + 2
"3" + 3 * x
But then there is an error with the following:
"5" + i + 2
3.
Also, with the follwing, what is actually happening and what is the result?
d++ + d
4.
When Math.round is used, why does it convert the following double into a float, or are they the same thing?
Math.round(x / d)

1.
This:
(int) d / 2.0
is the same as this:
((int) d) / 2.0
Perhaps you meant this?
(int)(d / 2.0)
2.
They both "print" strings (assuming you're talking about using them as the argument to System.out.println).
These:
"2" + x + 2
"3" + 3 * x
are the same as these:
("2" + x) + 2
"3" + (3 * x)
which are the same as these (assuming x = 10):
("2" + 10) + 2
"3" + 30
which are the same as these:
"2102"
"330"
3.
I can't remember what should happen here. But you should never need/want to write code like that, so it doesn't matter!
4.
The return type of Math.round is an integer type, not a floating-point type.

Why does the following remain a double after it is cast as an int... For the second one also, why does it output a float when defined as a long?:
(int) d / 2.0
(long) d * 2f
Because priority of cast (int) operator is higher that / and * operators.
You should read it like this:
((int) d) / 2.0
((long) d) * 2f
Why does the first of the following print a string(?), and the latter a number?
"2" + x + 2
"3" + 3 * x
I think it's string in both casesm you must "read" this expressions like this:
("2" + x) + 2
"3" + (3 * x)
But then there is an error with the following:
"5" + i + 2
What is the error?
Also, with the follwing, what is actually happening and what is the result?
d++ + d
This is a sequence of actions:
tmp = d
d = d + 1
return tmp + d
When Math.round is used, why does it convert the following double into a float, or are they the same thing?
Math.round(x / d)
It converts to long, because return type of Math.round(double) is long

(int) d / 2.0
(long) d * 2f
You still do floating point math, i.e. one operand is still a double/float and thus the result is a double/float.
"2" + x + 2
"3" + 3 * x
The first would just be concatenation, i.e. the type of the expression is String and thus all operands are converted to a string. For x=1 you'd get "212".
The second is subject to operator precendence, i.e. * is evaluated before + and thus the expression 3 * x is an integer math operation whose result will then be converted to a string by "3" + result.
"5" + i + 2
The error lies in your code, post the exception. Most probably i is undefined.
d++ + d
Have a look at operator precedence and post increment operators. x++ would return the value of x and then increment it. Then the previous value of x will be added to the new value. You can think of it being similar to x + (x+1).
When Math.round is used, why does it convert the following double into a float, or are they the same thing?
Math.round(x / d)
There's no conversion, just an overloaded method (one taking a double and one taking a float). Basically float has less precision than double but both are floating point numbers.

Too many questions in one.
You're casting the operand, not the expression, and types will be promoted.
What do they actually print, and how are you differentiating their types? Check out Java operator precedence.
Because there's no i.
You can print the result.
The Conversions and Promotions JLS section may also be helpful; many of your questions are answered there.

Bitwise Multiply and Add in Java

I have the methods that do both the multiplication and addition, but I'm just not able to get my head around them. Both of them are from external websites and not my own:
public static void bitwiseMultiply(int n1, int n2) {
int a = n1, b = n2, result=0;
while (b != 0) // Iterate the loop till b==0
{
if ((b & 01) != 0) // Logical ANDing of the value of b with 01
{
result = result + a; // Update the result with the new value of a.
}
a <<= 1; // Left shifting the value contained in 'a' by 1.
b >>= 1; // Right shifting the value contained in 'b' by 1.
}
System.out.println(result);
}
public static void bitwiseAdd(int n1, int n2) {
int x = n1, y = n2;
int xor, and, temp;
and = x & y;
xor = x ^ y;
while (and != 0) {
and <<= 1;
temp = xor ^ and;
and &= xor;
xor = temp;
}
System.out.println(xor);
}
I tried doing a step-by-step debug, but it really didn't make much sense to me, though it works.
What I'm possibly looking for is to try and understand how this works (the mathematical basis perhaps?).
Edit: This is not homework, I'm just trying to learn bitwise operations in Java.

Let's begin by looking the multiplication code. The idea is actually pretty clever. Suppose that you have n1 and n2 written in binary. Then you can think of n1 as a sum of powers of two: n2 = c30 230 + c29 229 + ... + c1 21 + c0 20, where each ci is either 0 or 1. Then you can think of the product n1 n2 as
n1 n2 =
n1 (c30 230 + c29 229 + ... + c1 21 + c0 20) =
n1 c30 230 + n1 c29 229 + ... + n1 c1 21 + n1 c0 20
This is a bit dense, but the idea is that the product of the two numbers is given by the first number multiplied by the powers of two making up the second number, times the value of the binary digits of the second number.
The question now is whether we can compute the terms of this sum without doing any actual multiplications. In order to do so, we're going to need to be able to read the binary digits of n2. Fortunately, we can do this using shifts. In particular, suppose we start off with n2 and then just look at the last bit. That's c0. If we then shift the value down one position, then the last bit is c0, etc. More generally, after shifting the value of n2 down by i positions, the lowest bit will be ci. To read the very last bit, we can just bitwise AND the value with the number 1. This has a binary representation that's zero everywhere except the last digit. Since 0 AND n = 0 for any n, this clears all the topmost bits. Moreover, since 0 AND 1 = 0 and 1 AND 1 = 1, this operation preserves the last bit of the number.
Okay - we now know that we can read the values of ci; so what? Well, the good news is that we also can compute the values of the series n1 2i in a similar fashion. In particular, consider the sequence of values n1 << 0, n1 << 1, etc. Any time you do a left bit-shift, it's equivalent to multiplying by a power of two. This means that we now have all the components we need to compute the above sum. Here's your original source code, commented with what's going on:
public static void bitwiseMultiply(int n1, int n2) {
/* This value will hold n1 * 2^i for varying values of i. It will
* start off holding n1 * 2^0 = n1, and after each iteration will
* be updated to hold the next term in the sequence.
*/
int a = n1;
/* This value will be used to read the individual bits out of n2.
* We'll use the shifting trick to read the bits and will maintain
* the invariant that after i iterations, b is equal to n2 >> i.
*/
int b = n2;
/* This value will hold the sum of the terms so far. */
int result = 0;
/* Continuously loop over more and more bits of n2 until we've
* consumed the last of them. Since after i iterations of the
* loop b = n2 >> i, this only reaches zero once we've used up
* all the bits of the original value of n2.
*/
while (b != 0)
{
/* Using the bitwise AND trick, determine whether the ith
* bit of b is a zero or one. If it's a zero, then the
* current term in our sum is zero and we don't do anything.
* Otherwise, then we should add n1 * 2^i.
*/
if ((b & 1) != 0)
{
/* Recall that a = n1 * 2^i at this point, so we're adding
* in the next term in the sum.
*/
result = result + a;
}
/* To maintain that a = n1 * 2^i after i iterations, scale it
* by a factor of two by left shifting one position.
*/
a <<= 1;
/* To maintain that b = n2 >> i after i iterations, shift it
* one spot over.
*/
b >>>= 1;
}
System.out.println(result);
}
Hope this helps!

It looks like your problem is not java, but just calculating with binary numbers. Start of simple:
(all numbers binary:)
0 + 0 = 0 # 0 xor 0 = 0
0 + 1 = 1 # 0 xor 1 = 1
1 + 0 = 1 # 1 xor 0 = 1
1 + 1 = 10 # 1 xor 1 = 0 ( read 1 + 1 = 10 as 1 + 1 = 0 and 1 carry)
Ok... You see that you can add two one digit numbers using the xor operation. With an and you can now find out whether you have a "carry" bit, which is very similar to adding numbers with pen&paper. (Up to this point you have something called a Half-Adder). When you add the next two bits, then you also need to add the carry bit to those two digits. Taking this into account you can get a Full-Adder. You can read about the concepts of Half-Adders and Full-Adders on Wikipedia:
http://en.wikipedia.org/wiki/Adder_(electronics)
And many more places on the web.
I hope that gives you a start.
With multiplication it is very similar by the way. Just remember how you did multiplying with pen&paper in elementary school. Thats what is happening here. Just that it's happening with binary numbers and not with decimal numbers.

EXPLANATION OF THE bitwiseAdd METHOD:
I know this question was asked a while back but since no complete answer has been given regarding how the bitwiseAdd method works here is one.
The key to understanding the logic encapsulated in bitwiseAdd is found in the relationship between addition operations and xor and and bitwise operations. That relationship is defined by the following equation (see appendix 1 for a numeric example of this equation):
x + y = 2 * (x&y)+(x^y) (1.1)
Or more simply:
x + y = 2 * and + xor (1.2)
with
and = x & y
xor = x ^ y
You might have noticed something familiar in this equation: the and and xor variables are the same as those defined at the beginning of bitwiseAdd. There is also a multiplication by two, which in bitwiseAdd is done at the beginning of the while loop. But I will come back to that later.
Let me also make a quick side note about the '&' bitwise operator before we proceed further. This operator basically "captures" the intersection of the bit sequences against which it is applied. For example, 9 & 13 = 1001 & 1101 = 1001 (=9). You can see from this result that only those bits common to both bit sequences are copied to the result. It derives from this that when two bit sequences have no common bit, the result of applying '&' on them yields 0. This has an important consequence on the addition-bitwise relationship which shall become clear soon
Now the problem we have is that equation 1.2 uses the '+' operator whereas bitwiseAdd doesn't (it only uses '^', '&' and '<<'). So how do we make the '+' in equation 1.2 somehow disappear? Answer: by 'forcing' the and expression to return 0. And the way we do that is by using recursion.
To demonstrate this I am going to recurse equation 1.2 one time (this step might be a bit challenging at first but if needed there's a detailed step by step result in appendix 2):
x + y = 2*(2*and & xor) + (2*and ^ xor) (1.3)
Or more simply:
x + y = 2 * and[1] + xor[1] (1.4)
with
and[1] = 2*and & xor,
xor[1] = 2*and ^ xor,
[1] meaning 'recursed one time'
There's a couple of interesting things to note here. First you noticed how the concept of recursion sounds close to that of a loop, like the one found in bitwiseAdd in fact. This connection becomes even more obvious when you consider what and[1] and xor[1] are: they are the same expressions as the and and xor expressions defined INSIDE the while loop in bitwiseAdd. We also note that a pattern emerges: equation 1.4 looks exactly like equation 1.2!
As a result of this, doing further recursions is a breeze, if one keeps the recursive notation. Here we recurse equation 1.2 two more times:
x + y = 2 * and[2] + xor[2]
x + y = 2 * and[3] + xor[3]
This should now highlight the role of the 'temp' variable found in bitwiseAdd: temp allows to pass from one recursion level to the next.
We also notice the multiplication by two in all those equations. As mentioned earlier this multiplication is done at the begin of the while loop in bitwiseAdd using the and <<= 1 statement. This multiplication has a consequence on the next recursion stage since the bits in and[i] are different from those in the and[i] of the previous stage (and if you recall the little side note I made earlier about the '&' operator you probably see where this is going now).
The general form of equation 1.4 now becomes:
x + y = 2 * and[x] + xor[x] (1.5)
with x the nth recursion
FINALY:
So when does this recursion business end exactly?
Answer: it ends when the intersection between the two bit sequences in the and[x] expression of equation 1.5 returns 0. The equivalent of this in bitwiseAdd happens when the while loop condition becomes false. At this point equation 1.5 becomes:
x + y = xor[x] (1.6)
And that explains why in bitwiseAdd we only return xor at the end!
And we are done! A pretty clever piece of code this bitwiseAdd I must say :)
I hope this helped
APPENDIX:
1) A numeric example of equation 1.1
equation 1.1 says:
x + y = 2(x&y)+(x^y) (1.1)
To verify this statement one can take a simple example, say adding 9 and 13 together. The steps are shown below (the bitwise representations are in parenthesis):
We have
x = 9 (1001)
y = 13 (1101)
And
x + y = 9 + 13 = 22
x & y = 9 & 13 = 9 (1001 & 1101 = 1001)
x ^ y = 9^13 = 4 (1001 ^ 1101 = 0100)
pluging that back into equation 1.1 we find:
9 + 13 = 2 * 9 + 4 = 22 et voila!
2) Demonstrating the first recursion step
The first recursion equation in the presentation (equation 1.3) says that
if
x + y = 2 * and + xor (equation 1.2)
then
x + y = 2*(2*and & xor) + (2*and ^ xor) (equation 1.3)
To get to this result, we simply took the 2* and + xor part of equation 1.2 above and applied the addition/bitwise operands relationship given by equation 1.1 to it. This is demonstrated as follow:
if
x + y = 2(x&y) + (x^y) (equation 1.1)
then
[2(x&y)] + (x^y) = 2 ([2(x&y)] & (x^y)) + ([2(x&y)] ^ (x^y))
(left side of equation 1.1) (after applying the addition/bitwise operands relationship)
Simplifying this with the definitions of the and and xor variables of equation 1.2 gives equation 1.3's result:
[2(x&y)] + (x^y) = 2*(2*and & xor) + (2*and ^ xor)
with
and = x&y
xor = x^y
And using that same simplification gives equation 1.4's result:
2*(2*and & xor) + (2*and ^ xor) = 2*and[1] + xor[1]
with
and[1] = 2*and & xor
xor[1] = 2*and ^ xor
[1] meaning 'recursed one time'

Here is another approach for Multiplication
/**
* Multiplication of binary numbers without using '*' operator
* uses bitwise Shifting/Anding
*
* #param n1
* #param n2
*/
public static void multiply(int n1, int n2) {
int temp, i = 0, result = 0;
while (n2 != 0) {
if ((n2 & 1) == 1) {
temp = n1;
// result += (temp>>=(1/i)); // To do it only using Right shift
result += (temp<<=i); // Left shift (temp * 2^i)
}
n2 >>= 1; // Right shift n2 by 1.
i++;
}
System.out.println(result);
}