Yitzchak Gale writes:
Jerzy Karczmarczuk wrote:
Would you say that *no* typical floating-point software is reliable?
It depends on how you define "reliable".
Floating point intentionally trades accuracy for speed,
...
It used to be true - and may still be - that the engineers
who implement floating point in the hardware of our
CPUs would never fly on commercial airliners. Would you?
Would you entrust your country's nuclear arsenal to an
automated system that depends on floating point arithmetic?
1. This is not a possible "trade-off" or not. In scientific/engineering
computation there is really no choice, since you have to compute
logarithms, trigonometric functions, etc., and some inaccuracy is
unavoidable. Of course, one may use intervals, and other extremely
costly stuff, but if the stability of the algorithms is well controlled,
and in normal case it is (especially if the basic arithmetics has some
extra control bits to do the rounding), th issue is far from being
mortal.
2. The story about engineering not flying commercial planes is largely
anecdotical, and you know that. Repeating it here doesn't change much.
3. Nuclear arsenal is never really "entrusted to an automated system",
because of reasons much beyond the fl.point inaccuracies.
On the other hand, in all those software one has to deal with
probabilities, and with imprecise experimental data, so even if for God
knows which purpose everything used exact algebraic numbers, or
controlled transcendental extensions, the input imprecision would kill
all the sense of infinitely precise computations thereupon.
4. The non-reliability of engineering software has many more important
reasons, sometimes incredibly stupid, such as the confusion between
metric and English units in the Mars Climate Orbiter crash...
The Ariane 5 crash was the result not of the floating-point computation
but of the conversion to signed 16-bit numers (from a 64bit double).
5. Of course, in the original posting case, the underlying math/logic is
discrete, and has no similar inaccuracies, so the two worlds should
not be confounded... Here, if some laws get broken, it is the result of
bad conventions, which usually can be easily avoided.
Jerzy Karczmarczuk
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
