[Haskell-cafe] Re: A question about "monad laws"
jerzy.karczmarczuk at info.unicaen.fr
jerzy.karczmarczuk at info.unicaen.fr
Tue Feb 12 06:58:02 EST 2008
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
More information about the Haskell-Cafe
mailing list