rcd@ico.UUCP (02/14/87)
In response to the hypothetical disaster caused by a bad, non-IEEE floating-point architecture, oster@lapis.berkeley.edu (David Phillip Oster) writes: > Whether the engineers responsible go to jail or not, whether building a system > that gives wrong answers is criminal or not, it is WRONG to build a > system that gives wrong answers. It is just plain morally wrong. They are > making a marketing decision that means that innocent people will die as a > direct result of their actions. This is fundamentally correct. Don't build systems that give <obviously> wrong answers. Do your best not to screw up; check what you've built; if you find a problem, don't hide it. But... > A system that gets the wrong answer fast is not what I need. In fact, it > has negative worth, because it lulls me into believing I know something > that in fact I do not know. ...here, we're beyond the fringe. I contend that there is not a computer system in existence which gives correct answers on floating-point calculations...so let's start to get realistic. First, to illustrate my point, unless you have a system which carries values as pairs of arbitrary- length integers (representing numerator and denominator) and DOES NOT ALLOW the use of any transcendental functions, it will give wrong answers! It's a first-semester problem to show that. What remains, after you've been dealt the psychological blow of knowing that everything useful that you ever attempt is going to be an approximation to the right answer, is an engineering problem: How can you get an answer that's good enough at reasonable cost? What we OUGHT to be saying, as far as the moral judgments are concerned, is NOT that it's morally wrong to build a computer system that gives wrong answers--since that makes all present-day computers with floating-point immoral! Rather, we ought to make the judgment that all parties concerned with causing the calculation to happen be aware of the limitations within which they work, and make known the limitations they create. As a final step, the engineer responsible for producing the final result bears the burden of deciding whether he can, in fact, produce an answer which is acceptably close to that which is desired, using an acceptable amount of computational resources. Just plain ol' engineering sense. Or, as the parent article got around to saying: > ...Sometimes you don't need a lot of > accuracy. But if you are going to use that component in a system, you as > the builder of the system, have a duty to see that the system doesn't > pretend to more accuracy than it has. You must be aware of the error > propagation behavior of all your algorithms,... etc. > The trouble is, many people who make decisions about purchasing > machines actually compare machines based on MFLOPS. True, but presumably only the stupidest and most irresponsible fail to look at precision. >...If one is running IEEE > standard and the other is not, then it is not a fair comparison, if only > in the human cost to write the software to compensate for the inaccuracy > of the non-IEEE flavor. We're heading off into idealism again. You don't just evaluate a system. You evaluate the ability of a system to serve a particular purpose. If there's no gain from having IEEE FP (or, more correctly, if the gain is not offset by a greater cost--like, for example, being unable to solve a real- time problem in real time...) then you don't need it. >...Like the word "mayonaise", "floating point" > should be a term reserved for things that meet the standard. If your > machine does something else, you should be required to call it "imitation > floating point" in your marketing brochures. Now THIS is rubbish--particularly holding up "mayonnaise" as a standard while misspelling it, but the idea is completely wrong. We have come to the point where "mayonnaise" needs to be defined, and its use controlled, because after a few centuries of the term meaning a particular mixture, we got "food" manufacturers creating synthetic glop and trying to pass it off as the real thing (to people whose palates are no more discriminating in that respect than is a programmer who thinks a 32-bit floating point value with a hexponent is useful for real numerical work). The IEEE floating point standard is an infant. We've seen a few decades of numerical work BEFORE the standard emerged. Don't try to come along in the '80's and relabel a concept that's been in use since the '50's or before (in computers, I mean; no lectures about Napier please)--or if you do, best not be upset when people think you're being parochial. As much as I would like to have IEEE floating point in every machine I have to deal with, I cannot for the life of me understand why it has become such a holy cause with some people. It IS useful for a broad range of work, but NOT for everything. Nor is it the only possible way that a useful system for floating-point arithmetic could be designed. Why is that so hard to understand? -- Dick Dunn {hao,nbires,cbosgd}!ico!rcd (303)449-2870 ...If you plant ice, you're gonna harvest wind.