Does integer addition in a computer satisfy the binding law?

Today read the concept of programming language (concepts of programming Language), the seventh chapter of the "Binding" section:The addition of integers in some computers does not have a binding nature. For example, suppose a program calculates "A + B + C + D" where A and C are large positive numbers, and B, D is a negative number with a large absolute value. In this case, adding B to a does not cause an overflow, but adding c to a will overflow. B and D are similar to this. This passage is well understood, because as long as the programmer, Integer calculation may overflow is the basic common sense. But this passage only refers to the case where the intermediate result of the calculation overflows. If you focus on the final results without considering the intermediate results, will the calculation order still affect the results? In other words, does the addition in the computer satisfy the binding law? That is: (A + B) + c must be equal to (A + C) + b? First, if each intermediate result and the final result are not overflow, it is certain that the binding law must be satisfied, otherwise the computer itself is wrong. What happens if the intermediate result overflows? We might as well write a simple program to verify it. Here we select four integers, a and C are two are very large positive numbers, B and D are two very small negative numbers (that is, the absolute value of a large negative number).

intA = 2147483392;//0x7fffff00;intb =-2147479553;//0x80000fff;intc = 2146500592;//0x7ff0fff0;intD =-2147421968;//0x8000f0f0;intSum1 = ((A + B) + C) +D;intSum2 = (A + b) + (C +d);intSUM3 = (A + c) + (b +d); System.out.println ("((A + B) + C) + d=" +sum1); System.out.println ("(A + B) + (c + D) =" +sum2); System.out.println ("(A + C) + (b + D) =" + sum3);

SUM1 calculates the sum of a+b+c+d from left to right, Sum2 calculates A+b and C+d first, and then calculates the sum of the two; Sum3 calculates A+c and B+d first, then sums it up. The code shows that the intermediate results of SUM1 and sum2 did not overflow, but sum3 overflow when calculating a+c and b+d. Let's take a look at the actual running results:

((A + B) + c) + d=-917537(A + B) + (C + d)=-917537(A + c) + (b + d)=-917537

You can see that the results are correct regardless of the order. So we can come to the conclusion that integer addition in computer satisfies the binding lawHere is another problem, in the example above, although the intermediate result has been overflow, but the end result is not overflow. What happens if the end result overflows? The answer is that the results are still the same for different calculation orders, except that the results are all wrong (both overflow). This is caused by the limited precision of the computer itself, which is independent of the binding law, so this situation is still considered to be in accordance with the binding law. You can write a program yourself to verify this.note, however, that this conclusion is conditional, which is true for most modern computer systems, because these systems usually use "twos complement" to store integers, while the addition of twos complement is consistent with the law. There are examples of not satisfying the binding law, such as the addition of BCD code. ------------------------------------------------------------------wrote here, I thought of an old topic: How do I exchange 2 integer values without introducing a temporary variable? Generally speaking, there are 2 ways to do this, one is to use addition, the other is to use XOR or:

A = a += A-= a-B;

A = a ^= a ^= a ^ b;

Some people say that the first method is problematic because the addition of a and B can overflow. If you read this article, you will know that this is wrong-although a+b may overflow, but in the end can still get the correct results. The disadvantage is that it is less efficient than the second. But then again, it is more readable than the second. ------------------------------------------------------------------ Introduction to complementThe following is a brief introduction to the complement, if you are not interested in this or are more familiar please skip. The binary complement (two ' s complement) stores the integer encoding in the form of "2^n" (where n is the bit length of an integer). In contrast, another way of storing "anti-code" is "1 of the complement", that is, the complement of each bit of bit-wise (1 of the complement of 0,0 1, in binary this is the same as the inverse), so the English name of the anti-code is "one's complement". Complement can be regarded as the improvement of the anti-code, not only because the complement of the unification of "positive zero and negative 0", but also because its calculation is easier than the anti-code. The main point is that the complement does not have to consider the carry (i.e. overflow bit), and the inverse code must be considered. Another advantage of the complement is that its sign bit is also a computed bit, so it is not necessary to treat positive and negative numbers differently, which is the same as anti-code. Unlike the complement and the inverse code, the original code must consider both positive and negative and carry, so few systems use the original code to store integers. The following is a complementary and anti-code method to calculate the "10-1", so as to deepen understanding. Since most computers only implement addition without subtraction, "10-1" is actually converted to "10 + (-1)" to calculate. For simplicity, this assumes that integers are only 8 bits. The complement calculation process is as follows (1 of the complement is "1111 1111"): 0000 1010+ 1111 1111 ——————10000 1001 The result is an overflow, which produces a carry, which is simply ignored for the complement, so the final result is "9".Note that the overflow here is normal overflow. In contrast, if a positive + positive result is a negative number, or a negative + negative result is a positive number, an abnormal overflow occurs. The normal overflow result is still correct (this is the feature of the complement), and an abnormal overflow results in a wrong result. The inverse code calculation process is (-1 of the anti-code for "1111 1110"): 0000 1010+ 1111 1110 ——————10000 1000 also overflow, but at this time cannot ignore carry, otherwise you will get the error result "8", so also need to add the carry to the result: 0000 1000+ 1 —————— 0000 1001 Get the final result "9". SummaryFinally, let's summarize briefly. In most computer systems, the addition of integers satisfies the binding law. Specifically, if the final result does not overflow, the final result is not affected even if the intermediate result of the calculation process overflows. And if the final result itself is overflow, the change in the order of calculation will still get consistent results, it is still considered to satisfy the binding law. Although this article may be of little use to practical programming, we usually only need to pay attention to the final results do not overflow, no need to care about the intermediate process. But this article provides some theoretical support for this conclusion to help us deepen our understanding of computer integer addition operations. Reference: Signed number of the expression: Http://en.wikipedia.org/wiki/Signed_number_representations anti-code: HTTP://EN.WIKIPEDIA.ORG/WIKI/ONES%27 _complement Complement: Http://en.wikipedia.org/wiki/Two%27s_complementBCD Code: Http://en.wikipedia.org/wiki/BCD_code

Does integer addition in a computer satisfy the binding law?