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

Tue May 5 08:54:05 CEST 2015

-----BEGIN PGP SIGNED MESSAGE-----
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
http://archive.computerhistory.org/resources/access/text/2013/12/102746785-05-01-acc.pdf ).

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  www.rvs.uni-bielefeld.de