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

From: Stachour, Paul D BIS < >
Date: Mon, 4 May 2015 21:37:33 +0000


I'll chime in with my 2-cents worth about numbers and their correct or incorrect use.

Steve asks if static analysis could catch the mentioned defect, which is (my summary):

    Use of a binary fraction to represent a decimal fraction, and the resulting inexactness which happens on repeated operations.

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. 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. And then the compiler does whatever multiple-adds or subtracts or … is needed, preferably using the best form of arithmetic that the target-hardware provides. Let's see, that would be decimal fractions with decimal instructions, such as what exists on the IBM7070 (1970's) or IBM 360 or Honeywell 6000 or Univac 1108 or … [many others]. And means that the "problem" never happens.

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.

However, when one "chooses" (or has chosen for them):

   hardware that does not handle decimals.    programming language that does not handle decimals    design that (I suspect) does not perform numerical analysis for the size of number to be used    uses mixed-mode arithmetic in the manner indicated then such mistakes are very likely to happen. And not be caught.

In the past, when I was teaching an "Introduction to Software Engineering" class, I gave a problem which can be summarized as:

   Add 1 million pennies (expressed as 1/100 of a dollar) one-by-one, using your favorite programming language or numerical-application (e.g. excel).    Print out the resulting sum.
   Find a classmate who got a different answer than you did.    Describe why each of you got the answer you did, and if either of you got the right answer. Not too surprisingly, the vast majority of the students got "the wrong answer" on the first run of their program.

I found it interesting that most those students, who supposedly had a bachelor's degree in computer science, software engineering, computer engineering, information technology, or similar degree plus 3+ years of experience (that was the requirement to enter the program, which was a M.S. in Software Engineering) didn't understand the basics of computing with binary numbers versus computing with decimal numbers.

Regards, ..Paul S.

Paul D. Stachour
Software Quality Assurance
[cid:image001.png_at_xxxxxx
Det-tronics|6901 West 110th Street, Bloomington, MN 55438 USA 952-941-5665, x8409
Paul.Stachour_at_xxxxxx www.det-tronics.com<http://www.det-tronics.com/>

Learning from accidents is de rigueur but learning through accidents is an unacceptable development method for critical systems. Les Chambers. We may throw the dice, but the Lord determines how they fall. Proverbs 16:33 NLT.

   --The ideas and opinions expressed in this message
--are solely those of the message originator(s).

  --The opinions of the author(s) expressed

--herein do not necessarily state or reflect those
--of Detector Electronics, or of United Technologies
--Corporation. They may not be further disseminated
--without permission. They may not be used
  --for advertising or product endorsement purposes.

From: systemsafety-bounces_at_xxxxxx Sent: Monday, May 04, 2015 3:58 PM
To: jean-louis Boulanger; Roderick Chapman Cc: systemsafety_at_xxxxxx Subject: [External] Re: [SystemSafety] systemsafety Digest, Vol 34, Issue 5

Can static analysis catch this kind of defect:

https://www.ima.umn.edu/~arnold/disasters/patriot.html

Cheers,


The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon May 04 2015 - 23:38:35 CEST

This archive was generated by hypermail 2.3.0 : Mon Feb 18 2019 - 10:17:07 CET