The Metric System with Rounding is Garbage

First of all, my opponent states the problem of A * (X + Y) = AX + AY. In this problem, he only use the common method of rounding and uses no guard digits or any other technique to minimize the magnitude of rounding errors. To minimize the accumulated error, Round-to-even method is used. A. This method is also known as unbiased rounding, convergent rounding, statistician's rounding, Dutch rounding, Gaussian rounding, or bankers' rounding. It is identical to the common method of rounding except when the digit(s) following the rounding digit starts with a five and has no non-zero digits after it. The new algorithm is: * Decide which is the last digit to keep. * Increase it by 1 if the next digit is 6 or more, or a 5 followed by one or more non-zero digits. * Leave it the same if the next digit is 4 or less * Otherwise, if all that follows the last digit is a 5 and possibly trailing zeroes; then change the last digit to the nearest even digit. That is, increase the rounded digit if it is currently odd; leave it if it is already even. With all rounding schemes there are two possible outcomes: increasing the rounding digit by one or leaving it alone. With traditional rounding, if the number has a value less than the half-way mark between the possible outcomes, it is rounded down; if the number has a value exactly half-way or greater than half-way between the possible outcomes, it is rounded up. The round-to-even method is the same except that numbers exactly half-way between the possible outcomes are sometimes rounded up—sometimes down. Although it is customary to round the number 4.5 up to 5, in fact 4.5 is no nearer to 5 than it is to 4 (it is 0.5 away from both). When dealing with large sets of scientific or statistical data, where trends are important, traditional rounding on average biases the data upwards slightly. Over a large set of data, or when many subsequent rounding operations are performed as in digital signal processing, the round-to-even rule tends to reduce the total rounding error, with (on average) an equal portion of numbers rounding up as rounding down. This generally reduces upwards skewing of the result. Round-to-even is used rather than round-to-odd as it reduces rounding to a final digit of 5, and so reduces the likelihood of error resulting from double rounding. Source: . http://en.wikipedia.org... My opponent did not used this method so he got an accumulated error of 7 cents of the common method of rounding. If you use the rounding-to-even method, you would find that be a lot less than 7 cents. Unfortunately, I can't show you that, because only 8,000 characters are allowed. But you can try and find out in your free time. The rounding-to-even method can handle large sets of scientific or statistical data and will minimize the magnitude of rounding errors. My opponents thinks that I can't give him one function using rounding that will handle all possible data sets. In truth, no one can came up with a function using rounding that is perfect, because nothing is perfect. Rounding is the process of reducing the number of significant digits in a number. The result of rounding is a "shorter" number having fewer non-zero digits yet similar in magnitude. The result is less precise but easier to use. Therefore, rounding will make ALL functions include errors. So, someday, you can make a system better than metric, but when you include rounding, it WILL have errors. In conclusion, the future system with rounding is nothing better than the metric system with rounding. B. My opponent thinks that mathematical rounding errors and decimal conversion are the cause of computer rounding errors. However, I disagree. Floating-point numbers are represented in computer hardware as base 2 (binary) fractions. For example, the decimal fraction 0.125 has value 1/10 + 2/100 + 5/1000, and in the same way the binary fraction 0.001 has value 0/2 + 0/4 + 1/8. These two fractions have identical values, the only real difference being that the first is written in base 10 fractional notation, and the second in base 2. Unfortunately, most decimal fractions cannot be represented exactly as binary fractions. A consequence is that, in general, the decimal floating-point numbers you enter are only approximated by the binary floating-point numbers actually stored in the machine. No matter how many base 2 digits you're willing to use, the decimal value 0.1 cannot be represented exactly as a base 2 fraction. In base 2, 1/10 is the infinitely repeating fraction 0.0001100110011001100110011001100110011001100110011. .. Stop at any finite number of bits, and you get an approximation. This is why you see things like: >>> 0.1 0.10000000000000001 On most machines today, that is what you'll see if you enter 0.1 at a Python prompt. You may not, though, because the number of bits used by the hardware to store floating-point values can vary across machines, and Python only prints a decimal approximation to the true decimal value of the binary approximation stored by the machine. On most machines, if Python were to print the true decimal value of the binary approximation stored for 0.1, it would have to display >>> 0.1 0.1000000000000000055511151231257827021181583404541015625 Note that this is in the very nature of binary floating-point: this is not a bug in Python, and it is not a bug in your code either. You'll see the same kind of thing in all languages that support your hardware's floating-point arithmetic (although some languages may not display the difference by default, or in all output modes). The errors in Python float operations are inherited from the floating-point hardware, and on most machines are on the order of no more than 1 part in 2**53 per operation. That's more than adequate for most tasks, but you do need to keep in mind that it's not decimal arithmetic, and that every float operation can suffer a new rounding error. While pathological cases do exist, for most casual use of floating-point arithmetic you'll see the result you expect in the end if you simply round the display of your final results to the number of decimal digits you expect. Therefore, you can infer that binary number system is the cause of rounding and rounding errors in computers. Source: . http://www.python.org... C. 0.9999. .. (NOT 0.9999 as my opponent put) =1.0 This is a natural law, standard, and peer agreement as proven by various proofs written by many mathematicians. My opponent has misinterpreting the meaning of the use of the "…" (ellipsis) in 0.999… accounts for some of the misunderstanding about its equality to 1. The use here is different from the usage in language or in 0.99…9, in which the ellipsis specifies that some finite portion is left unstated or otherwise omitted. When used to specify a recurring decimal, "…" means that some infinite portion is left unstated, which can only be interpreted as a number by using the mathematical concept of limits. As a result, in conventional mathematical usage, the value assigned to the notation "0.999…" is the real number which is the limit of the convergent sequence (0.9, 0.99, 0.999, 0.9999, …). But I can't elaborate more since I'm almost out of characters. Source: . http://en.wikipedia.org... D. The same thing I would say for point B. I would put the source that elaborate my point such as the rounding problem in Excel that my opponent put in his first argument: . http://support.microsoft.com... In conclusion, the reason I said that rounding is not garbage is because our computers are not advance enough to store infinite numbers in a finite number of bits. Therefore, the computers has flaws, NOT the metric system. I would like to point out that my opponent did not even use sources to prove his point.