For I = 0, Why Is (I += I++) Equal to 0

For i = 0, why is (i += i++) equal to 0?

This:

int i = 0;
i += i++

Can be seen as you doing (the following is a gross oversimplification):

int i = 0;
i = i + i; // i=0 because the ++ is a postfix operator and hasn't been executed
i + 1; // Note that you are discarding the calculation result

What actually happens is more involved than that - take a look at MSDN, 7.5.9 Postfix increment and decrement operators:

The run-time processing of a postfix increment or decrement operation of the form x++ or x-- consists of the following steps:

• If x is classified as a variable:

  • x is evaluated to produce the variable.
  • The value of x is saved.
  • The selected operator is invoked with the saved value of x as its argument.
  • The value returned by the operator is stored in the location given by the evaluation of x.
  • The saved value of x becomes the result of the operation.

Note that due to order of precedence, the postfix ++ occurs before +=, but the result ends up being unused (as the previous value of i is used).

---

A more thorough decomposition of i += i++ to the parts it is made of requires one to know that both += and ++ are not atomic (that is, neither one is a single operation), even if they look like they are. The way these are implemented involve temporary variables, copies of i before the operations take place - one for each operation. (I will use the names iAdd and iAssign for the temporary variables used for ++ and += respectively).

So, a closer approximation to what is happening would be:

int i = 0;
int iAdd = i; // Copy of the current value of i, for ++
int iAssign = i; // Copy of the current value of i, for +=

i = i + 1; // i++ - Happens before += due to order of precedence
i = iAdd + iAssign;

How to check for equals? (0 == i) or (i == 0)

I prefer the second one, (i == 0), because it feel much more natural when reading it. You ask people, "Are you 21 or older?", not, "Is 21 less than or equal to your age?"

Difference in the two ways of checking equality i==0 vs 0==i in C++

The former has the advantage that it prevents the programmer from accidentally leaving out an equals sign.

if (i = 0)

The above is legal, and sets i to zero, and is false (since zero is considered false).

if (0 = i)

The above is illegal in all contexts.

Today, most compilers will warn about if (i = 0), but it is not a requirement, and they didn't always do so.

expected '0th' to equal '0'

if you gonna devide a unknown input you wanna check if the input given might be zero. Else there might be an devisionbyzero exception thrown.

function numberToOrdinal(i) { if(i === 0){ // since we devide i we wanna check if it might be zero.   return i ; } var j = i % 10, k = i % 100; //if (j == 0 && k == 100) { didnt seem to be doing anything    //return '0th'; //} if (j == 1 && k != 11) {  return i + "st"; } if (j == 2 && k != 12) {  return i + "nd"; } if (j == 3 && k != 13) {  return i + "rd"; } return i + "th";}console.log(numberToOrdinal(0));

Why is !0 equal to 1 and not -1?

The reason is that in standard C, it has been specified that all operators returning a boolean return either 1 or 0. !0 calculates the logical not of 0, i.e. 1. The logical not of 1 would be then 0.

What you want to use is the bitwise NOT operator, i.e. ~0 which should be 0xFFFFFFFF == -1.

Why in Python does 0, 0 == (0, 0) equal (0, False)?

The first two expressions both parse as tuples:

1. (0, 0) == 0 (which is False), followed by 0
2. 0, followed by 0 == (0, 0) (which is still False that way around).

The expressions are split that way because of the relative precedence of the comma separator compared to the equality operator: Python sees a tuple containing two expressions, one of which happens to be an equality test, instead of an equality test between two tuples.

But in your second set of statements, a = 0, 0 cannot be a tuple. A tuple is a collection of values, and unlike an equality test, assignment has no value in Python. An assignment is not an expression, but a statement; it does not have a value that can be included into a tuple or any other surrounding expression. If you tried something like (a = 0), 0 in order to force interpretation as a tuple, you would get a syntax error. That leaves the assignment of a tuple to a variable – which could be made more explicit by writing it a = (0, 0) – as the only valid interpretation of a = 0, 0.

So even without the parentheses on the assignment to a, both it and b get assigned the value (0,0), so a == b is therefore True.

Why does (0 && 1 == 0) not evaluate to true?

The == operator has a higher priority than the && operator, so this line:

if(0 && (a++)==0)

is treated like this:

if(  0 && ((a++)==0) )

So the whole expression under the if is false, and a++ is not even evaluated due to short circuitry of the && operator.

You can read about Operator Precedence and Associativity on cppreference.com.

When in doubt, you should use parenthesis to express your intention clearly. In this case, it should be:

if( (0 && (a++)) == 0  )

Though, it does not make any sense, as it always evaluates to true and a++ is not incremented here, either.

---

Related Topics