From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1094ba,9f0bf354542633fd X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,d901a50a5adfec3c X-Google-Attributes: gid103376,public From: wclodius@lanl.gov (William B. Clodius) Subject: Re: Fortran or Ada? Date: 1998/09/29 Message-ID: #1/1 X-Deja-AN: 396158090 References: <36068E73.F0398C54@meca.polymtl.ca> <6u8r5o$aa4$1@nnrp1.dejanews.com> <360A3446.8AD84137@lmco.com> <6udre0$ha1$1@nnrp1.dejanews.com> <19980925.185359.250@yktvmv.watson.ibm.com> <6uifdr$dog$1@nnrp1.dejanews.com> <19980928.184428.604@yktvmv.watson.ibm.com> Organization: Los Alamos National Laboratory Newsgroups: comp.lang.fortran,comp.lang.ada Date: 1998-09-29T00:00:00+00:00 List-Id: In article <19980928.184428.604@yktvmv.watson.ibm.com>, jbs@yktvmv.watson.ibm.com wrote: jbs@yktvmv.watson.ibm.com wrote: > > 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. On a safety critical system an overflow in a useful component of the system indicates the loss of critical information. Any such loss is dangerous and must be recognized and dealt with. Of course a non-useful computation should not be performed so that all resources are put to their best use. > > Ada did catch the exception and started dumping diagnostic > information which was interpreted as navigational data causing the > crash. The programmers deliberately chose that method of dealing with the error (or rather they deliberately chose to shut down a computer system assuming the only fixable source of the problem was a computer hardware problem where reliance on the backup was available.) Unfortunately the problem occured in both computer subsystems. > > > 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. Nonsence. On what do you base your judgement on Ada's inefficiency? It is often more efficient than C, and usually comparable to Fortran. For reasons of reliability computer systems on rockets and satellites are implemented using processors that are several generations behind commercial processors in performance. Also, there is always a tendency to add features so that system utilization closely matches maximum allowed utilization. > 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. > While the default is to check errors, it is easy to identify postential sources and turn them off. Note the programmers did that in several cases, and deliberately chose not to do that in this case. See http://www.rvs.uni-bielefeld.de/~ladkin/Reports/ariane.html