🚀 go-pugleaf

The discussion revolves around the difficulty of supporting IEEE 754 in a
very fast machine...an objection:

> Scenario: Someone (mis)designs a jetliner using `very fast' floating
> point because it does not correctly handle an arithmetic condition
> which would be correctly handled by an IEEE conforming system.
> The liner crashes because of the defect and 300 people are killed.

Possible?  Sure, but the scenario requires several assumptions which aren't
necessarily so in the real world:
	- The `very fast' non-754 FP has to be misdesigned in some sig-
	  nificant way.  (This is pretty likely if the "fast" machines I've
	  seen in the past are any indication!:-)
	- The programmer has to be unaware of the fact that he's failing
	  to catch a potential error.
	- The condition has to be one which is caught by a 754-conforming
	  system.  The detection of the condition must either always occur
	  or be pretty difficult to disable.
What I'm really saying is that 754 isn't perfect, let alone foolproof (!)
and non-754 is not inherently flawed.

Slight digression:

I spoke to someone who's taking a numerical analysis course, doing some of
the standard see-how-the-errors-work problems.  One of the exercises
involves determining "machine epsilon".  Running this on a machine with a
processor like a 287, which as far as I know is supposed to meet the 754
standard, the answer you get depends on how the compiler works, since the
FPU has 80-bit internal regs but values are stored in memory in the 64-bit
format.  (It's not a full 16 bits more precision since the exponents are
different for the two formats, but it's certainly enough to notice.)

Mostly I avoid numerical work, but I've been told that there are various
commonly-used programs which determine machine precision and then use it to
control other aspects of the program.  Suppose that these programs are run
on a machine with 754 FP which manages to do the epsilon computation (which
is pretty simple) in registers, but ends up dumping a lot of the real
computation results into memory, losing precision in the process.  I'm
guessing that if this caused the program to fail without notice and it
ended up causing a liability case, it would be about a four-way tossup as
to who was at fault.
-- 
Dick Dunn    {hao,nbires,cbosgd}!ico!rcd	(303)449-2870
   ...If you plant ice, you're gonna harvest wind.