Conference rusure::math

543.0. "Attaboy" by REX::MINOW (Martin Minow -- DECtalk Engineering) Thu Jul 24 1986 09:23

The Arpanet RISKS in Computers Digest (highly recommended) was discussing
engineering failures caused by computer errors.  You might find the
following interesting (especially the last message).

From:	RHEA::DECWRL::"[email protected]"
	"RISKS FORUM   (Peter G. Neumann -- Coordinator)" 24-JUL-1986 06:16
To:	[email protected]
Subj:	RISKS-3.24


Date: Tue, 22 Jul 86 23:26:59 EDT
To: RISKS FORUM   (Peter G. Neumann -- Coordinator) <[email protected]>
Subject: Re: Comet and Electra
From: Jerome H. Saltzer <[email protected]>

> - I also heard that the structural defect in the Electra I wing design had
> not been caught by the stress analysis program because of an undetected
> overflow on a critical run.  Can anyone provide documentation for this?  (I
> think this story was on the grapevine at the NATO Software Engineering
> Conferences in 68-69.)

In case it helps anyone recall where that one might be documented:  the
version of the story that came through here had it that some piece of
simulation input data was typed with the wrong minus sign.  (The commonly
available version of the 026 key punch had a minus sign and a hyphen as
distinct characters.  And the input format conversion routines in those days
were both unforgiving and silent about errors.)
                                                       Jerry

------------------------------

Date: Wed, 23 Jul 86 09:57:25 edt
From: [email protected] (Marvin Zelkowitz)
To: [email protected]
Subject: Re: Comet and Electra

Horning's recent comment reminds me of two related items:

- On the Electra I wing design defect: My version of the story goes
that the undetected overflow error was finally detected when these
"correct" programs were used as benchmarks for a new computer (a
Burroughs I think), which gave radically different answers. I do not have 
any proof of this, but it might give some additional help in tracking it
down.

- On overflow detection: In the late 60s, a certain vendor's FORTRAN
did not detect overflow. At a users' group meeting, the vendor offered
to add overflow detection at an execution penalty of one instruction
per arithmetic operation (e.g., branch-on-overflow). This was voted down.
The only conclusion is that users would rather be fast than right. 
The issue for RISKS is "Are these people the ones 'still in control'?"

--Marv Zelkowitz

------------------------------

Date: Wed 23 Jul 86 09:17:42-ADT
From:  Don Chiasson <[email protected]>
Subject: Re: Comet and Electra
To: [email protected]

> From: [email protected] (Jim Horning)

> - A numerical analyst once explained to me why all modern airliner windows
> have rounded corners: Anyone concerned with solving partial differential
> equations knows that square corners lead to singularities.  He said that the
> Comet crashes were traced to metal fatigue at the (square) corners of its
> windows.  (He concluded that airplane designers should study Numerical
> Analysis.)  

Most engineers know that any sharp corner on a stressed member will cause
an increase of actual stress over the nominal calculated stress, and the
ratio of these is called the stress concentration factor, K.  The value of
K is sort of inversely proportional to the radius of curvature of the
discontinuity.  High K is the reason cracks propagate so well. The
temporary fix for a crack is to drill a hole at the end of the crack which
increases the radius of the "corner" and decreases K.  It is standard
design practice to avoid sharp corners.  Stress concentration is usually
discussed in design textbooks without going into the differential
equations: there are lots of tables.

This brings up a problem encountered in computer applications: the
difficulty of a programmer learning the standard practices of a field in
which he is working.  Engineers know about stress concentration, but
programmers and mathematicians may not.

> - I also heard that the structural defect in the Electra I wing design had
> not been caught [...].  Can anyone provide documentation for this? 

I can't give a direct answer to this, but I know that a mid 60's computer
which was heavily used in scientific and engineering applications had very
poor accuracy in its trig package.  Is this perhaps the same topic?  (Or was
the Electra designed in the 50's??)  Note: I can identify the manufacturer
and machine, but feel that if I did so, I would be potentially libelous.
                Don Chiasson

------------------------------

Date: Wed 23 Jul 86 11:44:00-EDT
From: Bard Bloom <[email protected]>
Subject: Re: Comet and Electra
To: [email protected]

  [Structural defect in the Electra I wing design, again.  See Jerry, above.]

I don't know about this, but I was trying to move some software in Fortran
from an IBM to VAX for McDonnell-Douglas one summer.  The program on the VAX
kept dying, with a message to the effect of "I can't take a sine of a number
this large".  The program was trying to take sines of large (order of 10^20)
numbers in 16-digit arithmetic.  The first thing that the sine routine does
is reduce its argument modulo pi, which loses *all* of the precision of the
20-digit number.  The VAX's software generated an error about this.  The IBM
did not; and the programmers hadn't realized that it might be a problem (I
guess).  They had been using that program, gleefully taking sines of random
numbers and using them to build planes, for a decade or two.

------------------------------

    I vaguely remember a quote from Householder, a famous numerical
    analyst, saying that he would be reluctant to fly in any airplane
    which was designed with floating point arithmetic.

	However, I'd have no qualms about sailing on a boat
	designed with floating point arithmetic.

    re .2
    Unless the water overflowed the gunwales!-)