The Metric System with Rounding is Garbage

I apologize for my inconvenience of time delay. I am being educated at high school, but I will continue our debate. I also apologize for vocabulary and inexperience. First, I agree with your statement that rounding exist if for both the ease and speed of computation but will inevitably create accuracy or error. However, the error of rounding can be decreased to the extent where rounding in the metric system is not flawed. Let me get you the definition of round-off error: Round-off error, also called rounding error, is the difference between the calculated approximation of a number and its exact mathematical value. Numerical analysis specifically tries to estimate this error when using approximation equations and/or algorithms, especially when using finite digits to represent infinite digits of real numbers. Increasing the number of digits allowed in a representation reduces the magnitude of possible round off errors, but any representation limited to finitely many digits will still cause some degree of round off error for uncountably many real numbers. Now all we have to do is to reduce the magnitude of possible round off errors: Although this kind of error is unavoidable for conventional representations of numbers, but can be reduced by the use of guard digits. In case you don't know what guard digits are, let me tell you: In numerical analysis, one or more guard digits can be used to reduce the amount of round off error. For example, suppose that the final result of a long, multi-step calculation can be safely rounded off to N decimal places. That is to say, the round off error introduced by this final round off makes a negligible contribution to the overall uncertainty. However, it is quite likely that it is not safe to round off the intermediate steps in the calculation to the same number of digits. That is because round off errors can accumulate. If M decimal places are used in the intermediate calculation, we say there are M-N guard digits. Even though round off errors can accumulate, guard digits can decrease the magnitude of it. Guard Digits are also used in floating point operations in most computer systems. Given 21 * 0.100 − 20 * 0.111 we have to line up the binary points. This means we must add an extra digit to the first operand--a guard digit--this gives us 21 * 0.1000 − 21 * 0.0111 performing this operation gives us 21 * 0.0001 or 2 − 2 * 0.100. Without using a guard digit we have 21 * 0.100 − 21 * 0.011 this yields 21 * 0.001 or 2 − 1 * 0.100 This gives us a relative error of 1. Therefore we can see how important guard digits can be. Second, your case in point is the rounding issue on the targeting system for the Patriot Missiles System. I'm not familiar with the specifics of the programming related to those missile systems, but whenever I have to count with decimals I change my representation so I'm using integers. So instead of calling a millisecond 0.001s I call it just what it is, 1 millisecond. Then if I need to show something in seconds I just divide the milliseconds by ten for my output, but keep counting in milliseconds so that my data is not off. Computers have trouble with any number that is not an integer, and they would have just as much trouble with reciprocals of powers of two. Computers would not represent 1/32 as 1/32, but as 0.0009765, which is just another decimal number like 0.1. The downfall of the program wasn't the metric system, but a problem inherent with trying to accurately represent numbers that are not integers. The reason this bug occurred is because of a problem with storing time in a 24-bit register. The problem is that time is stored to an accuracy of 1/10th of a second, but a 24-bit register does not have enough precision to store 0.1, so a small fraction of each second is lost. The result is that the register used to keep track of time is off by 0.0001% of the amount of time that the system has been in operation. The problem is that computers do not store information as a standard decimal. Instead, they use binary code, which can not accurately store 1/10th of a second. But the REAL problem was not with inaccuracy, but with inconsistency. During one of the updates, Raytheon Labs, the developer of the patriot missile, had fixed the previously mentioned inaccuracy problem by creating code that used a pair of 24 bit registers to accurately make the time calculations. The problem was that that most, but not all of the time calculations made by the system were replaced by calls to the newer, more accurate function. So, the system was keeping track of the current time using a function that loses time in much the same way that a clock with a weak battery will gradually lose time. But, the system would track missiles, aim itself, and decide exactly when to launch it's own missiles using the internal clock, which was accurate. In effect, the system would use an accurate timepiece to decide where the missile is located and how fast it is moving, and when to fire the defensive missiles. But while waiting to fire the missiles, the system would use the less accurate clock to determine when it should fire. It was estimated that after running the system for twenty hours, the calculations made using the old algorithm and those made by the new algorithm differed by as much as 1/3 of a second[3]. A SCUD missile can travel more than one mile per second. Had the same piece of code been used for all time conversions, then the inaccuracy of the Patriot Missile would not have increased over time the way it did in this case. Instead, every time calculation would be off by approximately 0.000001 seconds, and the system would be much more likely to have defended against any missiles launched at it. This is a good argument for reuse of code whenever possible. Although the developers at Raytheon Labs had tried to replace all time conversions with calls to the new function, they missed a few and the result was a system that was less reliable than it would have been if they had chosen to ignore the conversion error. The above passage indicates that the problem was not actually rounding errors. At least one of these software modifications was the introduction of a subroutine for converting clock-time more accurately into floating-point. This calculation was needed in about half a dozen places in the program, but the call to the subroutine was not inserted at every point where it was needed. Hence, with a less accurate truncated time of one radar pulse being subtracted from a more accurate time of another radar pulse, the error no longer canceled. Fundamentally, the problem is that computers don't deal with numbers in any particularly sensible fashion. I think that you can build computers based on any numerical base, but i imagine they will be harder to create and manage (circuit-wise). A better alternative is to build an emulator that performs base 10 arithmetic and runs on a binary computer, without making use of the available floating point operations to perform floating point operations (i.e. use the available logical operations exclusively). It would be slower, but cheaper. Therefore it is not the fault of the metric system that we have accumulated rounding errors but the computer's. The rounding errors can be minimized so we can say the the metric system with rounding is not garbage. Thank you for debating with me and correcting what I am debating for. I would like to thank my opponent for his meaningful debate subject and would like to request that this debate be judged solely on who was the better debate and for the factors listed in voting above. Sources: http://www.physicsforums.com... http://seeri.etsu.edu... http://en.wikipedia.org... http://en.wikipedia.org...