Re: [SystemSafety] Stupid Software Errors [was: Overflow......]

From: Peter Bernard Ladkin < >
Date: Tue, 05 May 2015 08:54:05 +0200

Hash: SHA256

On 2015-05-04 23:37 , Stachour, Paul D BIS wrote:
> Steve asks if static analysis could catch the [well-known Patriot] defect, which is (my
> summary):
> Use of a binary fraction to represent a decimal fraction, and the resulting inexactness which
> happens on repeated operations.

Static analysis tools which assess program logic can assess it if and only if there is a rigorous strong-typing mechanism for various forms of arithmetic. However, such tools cannot usually assess the validity of numerical-analytical approximation techniques.

> Now, I'm not a professional numerical analyst, but I've known for a l…oooo…nnnnnnn…g time that
> mixing fractions in different bases is just asking for problems.

Neither am I but I dabbled at the grad-school level. I was TA for the UC Berkeley Math department numerical analysis classes, undergrad and grad, in the mid-1970's. I "taught" the guy responsible for IEEE 754 (it was rather the other way round :-) See p49 of the Computer History Museum interview with Bill Cody ).

I would agree that mixing fractions in different bases is asking for problems.

> That is why in PL/I (1960's) or in Ada (1980's) or other well-designed programming languages,
> one can express the precision needed (and the desired base) for the numbers one is to use.

Setting floating-point precision counts as rigorous strong typing. But this alone does not suffice for correctness. The numerical techniques used for calculation should be appropriate (some of those will be library functions; others might be in-line); and the microprocessor FP implementation should be appropriate also.

But as you point out, the Patriot arithmetic anomaly was cruder than that:

> I would think that any reasonably good static analyzer would indicate that there was use of
> mixed-mode arithmetic, and that would trigger the review necessary to resolve that the
> resulting computation was "good enough" or not.

Another point of view is that the arithmetic was correct for the system requirements. The difficulties only arose when the system was used beyond requirements. Most static analysis only checks system operation against requirements, so it is a moot point whether appropriate static analysis would/should have caught the anomaly. In this case, analysis could in fact have flagged the arithmetic-type coercion.

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany Je suis Charlie
Tel+msg +49 (0)521 880 7319

-----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVSGkNAAoJEIZIHiXiz9k+T0IH/1e4CEKI5E+cG3kNsZ2lJRwO 0GnD66ryPymSgBLDxLSubsAl28S86gGXvU9aW65CNdADE6bPitLUmhlSTN3E48bP bYtTJfF6w8npb6OcK5BuQzEb5rhBqdgwBrIX+JbsbJ9f+J/XY4iUPqNZewae4C4J BbuscB0Eq7oVcnI8oD89TOPJoOfwLI0cvivop/C1pUN6J+rVXYHOUJDHh9AA8f00 Th0R7EjEDEJDDA3QIFp5iOQyJ8DvO170m6TUz6v+BAqpCoo5CjOU++m4mOu4ME5E O91avxwmT+QzxdgcmsMjUobj5ERvKogHOiIIDXV/m9KsujuH6borGz6CLhnZZtc= =lo0O

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Tue May 05 2015 - 08:54:13 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST