Re: Fortran or Ada?

[jbs@yktvmv.watson.ibm.com]

In article <6uifdr$dog$1@nnrp1.dejanews.com>,
 on Sat, 26 Sep 1998 10:25:01 GMT,
 dewarr@my-dejanews.com writes:
>In article <19980925.185359.250@yktvmv.watson.ibm.com>,
>  jbs@yktvmv.watson.ibm.com wrote:
>>          How come Fortran keeps getting blamed for a rocket failure
>> it didn't cause while no one blames Ada for the Ariane 5 failure
>> which it arguably did cause (Ada detected and mishandled a harmless
>> integer overflow which most Fortrans would have ignored)?
>>                         James B. Shearer

> ...
>However, trying to argue that Fortran is superior *as a language* in this
>case because it would have zoomed on, computing with rubbish values, is
>not very convincing (not to mention that the particular code in question
>would not have translated directly into Fortran, because of the (to me
>rather surprising) lack of fixed-point support in Fortran.

         Suppose you are considering a safety system in which an alarm
sounds to alert a driver to a dangerous situation.  You must take into
account the cases where the alarm causes an accident by startling the
driver into taking some inappropriate action.  Not having an alarm is
superior in such cases, although having an alarm may remain superior
overall.
         Similarly Fortran is in fact superior as a language in cases
like this.  Ada might be safer overall but in this case it was more
dangerous.
         As for the lack of fixed point support in Fortran, I don't
know what you mean.  From the accident report:
!  * The internal SRI software exception was caused during execution of a data
!    conversion from 64-bit floating point to 16-bit signed integer value. The
!    floating point number which was converted had a value greater than what
!    could be represented by a 16-bit signed integer. This resulted in an
!    Operand Error. The data conversion instructions (in Ada code) were not
!    protected from causing an Operand Error, although other conversions of
!    comparable variables in the same place in the code were protected.

         Converting floating point numbers to signed integers is
certainly supported in Fortran.  Technically 16 bit integers are not
part of the language but they are an almost universal extension
(integer*2).  What happens on overflow will be implementation dependent.
Raising an exception would be atypical.

         dewarr@my-dejanews.com continued (in part):
>Note that if the program had been designed a bit better, so that the
>unexpected exception was caught and resulted in some appropriate fallback
>processing, Ada *could* legitimately be credited with providing facilities
>that saved the day, whereas a language like Fortran would have caused chaos
>by continuing to compute with wrong values.

         Ada did catch the exception and started dumping diagnostic
information which was interpreted as navigational data causing the
crash.
         Fortran is most unlikely to have caused chaos since the code
in question was serving no function after liftoff.  From the accident
report:
!  * The error occurred in a part of the software that only performs alignment
!    of the strap-down inertial platform. This software module computes
!    meaningful results only before lift-off. As soon as the launcher lifts
!    off, this function serves no purpose.

         dewarr@my-dejanews.com continued (in part):
>Despite the outcome, a proper analysis of the Ariane incident (isn't that
>a nice word :-) is actually favorable to the language design choices in
>Ada rather than unfavorable.
>
>So, that's why Ada doesn't get blamed for Ariane. It wasn't to blame.

         I would not be so quick to exonerate Ada.  From the accident
report:
!In the failure scenario, the primary technical causes are the Operand Error
!when converting the horizontal bias variable BH, and the lack of protection of
!this conversion which caused the SRI computer to stop.
!
!It has been stated to the Board that not all the conversions were protected
!because a maximum workload target of 80% had been set for the SRI computer. To
!determine the vulnerability of unprotected code, an analysis was performed on
!every operation which could give rise to an exception, including an Operand
!Error. In particular, the conversion of floating point values to integers was
!analysed and operations involving seven variables were at risk of leading to
!an Operand Error. This led to protection being added to four of the variables,
!evidence of which appears in the Ada code. However, three of the variables
!were left unprotected. No reference to justification of this decision was
!found directly in the source code. Given the large amount of documentation
!associated with any industrial application, the assumption, although agreed,
!was essentially obscured, though not deliberately, from any external review.
!
!The reason for the three remaining variables, including the one denoting
!horizontal bias, being unprotected was that further reasoning indicated that
!they were either physically limited or that there was a large margin of
!safety, a reasoning which in the case of the variable BH turned out to be
!faulty. It is important to note that the decision to protect certain variables
!but not others was taken jointly by project partners at several contractual
!levels.

         It appears to me that this implicates Ada in at least two
respects:
         1.  It appears the developers were having trouble meeting their
performance target tempting them to cut corners.  Ada is of course
notoriously inefficient.
         2.  It appears there is no cheap way of turning off conversion
error checking in Ada, tempting programmers to leave it active in
inappropriate places.
                        James B. Shearer