Slashdot Mirror
Why Computers Suck At Math
antdude writes "This TechRadar article explains why computers suck at math, and how simple calculations can be a matter of life and death, like in the case of a Patriot defense system failing to take down a Scud missile attack: 'The calculation of where to look for confirmation of an incoming missile requires knowledge of the system time, which is stored as the number of 0.1-second ticks since the system was started up. Unfortunately, 0.1 seconds cannot be expressed accurately as a binary number, so when it's shoehorned into a 24-bit register — as used in the Patriot system — it's out by a tiny amount. But all these tiny amounts add up. At the time of the missile attack, the system had been running for about 100 hours, or 3,600,000 ticks to be more specific. Multiplying this count by the tiny error led to a total error of 0.3433 seconds, during which time the Scud missile would cover 687m. The radar looked in the wrong place to receive a confirmation and saw no target. Accordingly no missile was launched to intercept the incoming Scud — and 28 people paid with their lives.'"
Most unfortunately, the only solution for those rocket attacks is preventing they're fired in the first place. Which obviously requires either palestinians police their own terrorists, or someone does it for them (that's called "occupation").
This is exactly what's wrong with you and most of the Israeli government. First, you call it "unfortunate" that the only solution is to prevent the rockets being fired. Bit of a clue there. In any case, the only way that can be done in any permanent manner is to not give Hezbollah any reason to fire rockets in the first place. Not "occupation".
In the process Reagan bankrupted us by spending billions of dollars more on our defense budget than we could afford. We've just not maxed out our credit cards from the Bank of China yet, so it's not as obvious.
The problem was error accumulated in the clock register itself due to the imprecision of the clock, and overflows due to the inappropriately small size of the register. Both are hardware issues and represent bad design decisions. They way to fix them is to design the hardware properly in the first place so that it is appropriate for the job at hand.
...so your suggested solution is an infinitely precise register, and an infinitely large register?
You're obviously not a hardware designer, so I'll spare the clue-by-four. But there are some things that are better handled by software. It would certainly be *possible* to make a register look almost infinitely large; in the event the hardware detects an overflow, it allocates some space in memory, and calls that the upper bits of the register. Then it resets the register itself, and can start counting from zero again. You've extended your register size from, say 64 bits to 64 bits plus whatever amount of memory you have. But it's still not quite infinite. What happens when you run out of memory? (OK, so then the hardware starts saving to the hard drive. And if that fills up? Why, then the hardware signs you up for an online backup service using your credit card number and starts sending the overflow there. And when you get a new credit card?)
As you can see, you've delayed the problem - perhaps even by enough that almost nobody will ever encounter it. But it's still there, lying in wait for somebody to stumble across.
The better hardware solution? Provide the tools for the programmer to do what's appropriate for his application. Almost nobody designs hardware for just one application any more - I'd be willing to make a sizable bet that all of the cases cited in TFA used general-purpose hardware, so the general-purpose solution is software. Metaphorically, the hardware should give the programmer a loaded gun and let him decide how to use it. He can use it to shoot a deer and eat for a month, or shoot a bear to protect himself, or shoot fish in a barrel if he needs entertainment. Of course, he might also shoot himself in the foot because he doesn't know what he's doing.
Now if you want to make an argument over what layer of software takes advantage of the tools that the hardware provides, that's a legitimate discussion. Perhaps the compiler should make the hardware look infinite (this has same problems as the hardware doing it, but you save transistors). Or maybe provide a math library with the capability of making the hardware look infinite, and making sure the programmer tells it what to do if it eventually does overflow (but your programmer still has to recognize that he needs to use the library).
In any case, basically every solution to these problems come down to one thing: how many programmers need to know that the hardware really isn't infinite? If the answer is "every damn one of them," that really simplifies picking the idiots out of the crowd.