* Re: Fortran or Ada? [not found] <36068E73.F0398C54@meca.polymtl.ca> @ 1998-09-22 0:00 ` Gisle S{lensminde 1998-09-22 0:00 ` Jeff Templon 1998-09-23 0:00 ` bglbv 0 siblings, 2 replies; 83+ messages in thread From: Gisle S{lensminde @ 1998-09-22 0:00 UTC (permalink / raw) > Dear Fortran experts: > > A friend of mine (a computer engineer who uses C++) insists that Ada95 > is the best programming language for scientists and non-computer > engineers . His reasons: > > (from: http://www.adahome.com/Tutorials/Lovelace/s1s1.htm) I have tried to make answers to some of the question. My experiences is from Ada95, C, C++, Fortran77 and Java, and not so much f90. the answer is also sent comp.lang.ada. > 1. Packages (modules) of related types, objects, and operations can be > defined. Modules exists in Fortran 90 also, and is even inspired from Ada. > 2. Packages and types can be made generic (parameterized through a > template) to help create reusable components. That is also in Fortran 90/95 AFAIK. > 3. Errors can be signaled as exceptions and handled explicitly. Many > serious errors (such as computational overflow and invalid array > indexes) are automatically caught and handled through this exception > mechanism, improving program reliability. Yes, and this detects many errors, but I think some Fortran 90 compilers also checks indexes, if you ask them to do so. Maybe not as good as Ada. > 4. Tasks (multiple parallel threads of control) can be created and > communicate. This is a major capability not supported in a standard way > by many other languages. Yes > 5. Data representation can be precisely controlled to support systems > programming. Yes. > 6.A predefined library is included; it provides input/output (I/O), > string manipulation, numeric functions, a command line interface, and a > random number generator (the last two were available in Ada 83, but are > standardized in Ada 95). > 7. Object-oriented programming is supported (this is a new feature of > Ada 95). In fact, Ada 95 is the first internationally standardized > object oriented programming language. Yes, but the model for OO is a litle bit unusual, compared to other languages. > 8. Interfaces to other languages (such as C, Fortran, and COBOL) are > included in the language (these have been significantly enhanced in Ada > 95). At least one Ada compiler (from Intermetrics) can generate Java > Virtual Machine (J-code) from Ada, so people can use Ada to develop Java > applets and applications. Interfaces to other languages is often important, and yes Ada 95 does this in a portable way, and I often miss that in C++, but I have no experience with the Appletmagic compiler. > After reading these reasons, following questions came to my mind: (mind > on an engineer who has to use F77/90, sometimes C) > > 1) I know some of these capabilities is already supported by the Fortran > standard and some of them will be added to the next release...is Fortran > late? How can I convince the new generation of engineers to wait for the > next Fortran standard to have all of these capabilities? Some of the most important features it in f90/95 already, like modules, dynamic memory allocation, generics, data structure constructions and other modern features, but you will probably wait long for some features in Ada, like strong static typing all trough the language. To sit down waiting for the next standard is not the best way of using your time. > 2) Is there any comparison between performance of Fortran90/95 and Ada95 > compilers? It is difficult to compare two different languages in a fair way. For example Ada has index checking and exception handling wich Fortran doesn't. You can of cause turn off these, but it's often valuable to use them, becase they trap bugs on an early stage, and makes the code more reliable Such features has a performance penalty. But if we write comparable code in both languages, I would think that Fortran would win in a raw speed test, because some of the Fortran compilers optimize extremly well. > 3) It seems that Ada is the most popular language for safety-critical > systems. Why Ada? Why not Fortran or C++? What makes Ada suitable for > this kind of programming? Strong and static typing, extremly well defined syntax and semantics and very reliable compilers made for the purpose, well defined and reliable interface to lowlevel features, multitreading built in to the language, and a language designed for the task. C++ disqualifies from critical code for several reasons. Things like pointers and pointer aritmetrics and the possibility to cast everything to everything, makes the language unsafe. Many such systems must have total control of memory usage, and no dynamic memory usage is allowed in many cases, and makes C and C++ is impossible to use in the highest safity levels. (But C is used in some safity critical stuff anyway, and C is widely used for embedded targets.) Fortran do not have all the weakneses of C this respect, but is still not design for such tasks. The weak typing, is the bigest problem here. Historically, implicit variables have caused problems in safety critical code, but with IMPLICIT NONE that should not be an issue. > 4) What can Fortran offer to the engineers that Ada can't? (except > backward and legacy code compatibility) Engineers are familar with Fortran, and knows what it stands for. In an organization, it is often difficult to change. Its easier to go for Fortran90/95 (Often even that is very difficult). Anyway, many of the most important features that helps increasing the software design and quality, can be found in modern Fortran. The danger is that everything still looks like Fortran66 :-(, and not like the, say the F subset of Fortran 90, and the spaghetti remains. A conversion to f90 from f77 must be followed by training in the new principles. Ada still have a better static and dynamic type checking, and have syntax and sematics designed for good software engineering, early detection of errors, exception handling and OO, so Ada is my choice, if no compromises should be taken. > I know the answers to these questions could be long and/or they are > already discussed. I appreciate if you point me to the related > references. I have not seen any direct comparision between f95 and Ada95, so general info about both languages is probably the best source of information. I have used Ada more than Fortran, so it's most Ada in my references. http://www.adahome.com - Ada information, this site contains pointers to http://www.gnat.com - A free professional quality Ada 95 compiler http://www.adahome.com/Ammo/cpp2ada.html Ada for C and C++ programmers. http://www.fortranlib.com - Fortran info http://www.hpctec.mcc.ac.uk/hpctec/courses/Fortran90/F90course.html f77 to f90 conversion course. http://www.ifs.hr/ifs/razno/calc/HTMLF90Course/HTMLNotes.html f90 notes ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-22 0:00 ` Fortran or Ada? Gisle S{lensminde @ 1998-09-22 0:00 ` Jeff Templon 1998-09-22 0:00 ` Corey Minyard ` (4 more replies) 1998-09-23 0:00 ` bglbv 1 sibling, 5 replies; 83+ messages in thread From: Jeff Templon @ 1998-09-22 0:00 UTC (permalink / raw) Hi, one other word on Ada ... it is a very complex language. Take a look at Cohen's "Ada as a Second Language" book and compare it Metcalf and Reid's F95 book! Cohen is not spending time on elementary concepts either. So Ada loses in this respect : there is a lot of language to know. This makes it more difficult to write programs, unless one invests the time to learn the language well. This amount of time would be less for Fortran. I agree with the previous posters that otherwise, Ada has very many advantages. Apparently Wirth once said that if he had to do mission-critical software development, he would use Ada, no question. (for people who may not know, Wirth invented the languages Pascal, Modula, and Oberon.) JAT ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-22 0:00 ` Jeff Templon @ 1998-09-22 0:00 ` Corey Minyard 1998-09-22 0:00 ` Larry Kilgallen ` (3 subsequent siblings) 4 siblings, 0 replies; 83+ messages in thread From: Corey Minyard @ 1998-09-22 0:00 UTC (permalink / raw) Jeff Templon <templon@visar.physast.uga.edu> writes: > Hi, > > one other word on Ada ... it is a very complex language. Take a look > at Cohen's "Ada as a Second Language" book and compare it Metcalf > and Reid's F95 book! Cohen is not spending time on elementary concepts > either. > > So Ada loses in this respect : there is a lot of language to know. > This makes it more difficult to write programs, unless one invests > the time to learn the language well. This amount of time would > be less for Fortran. There is a lot of language to know if you use all of it. That's like saying the Unix library is very large and you have to know it all, even if you only want to do file I/O. Cohen's book (which I am quite fond of, BTW) is VERY detailed. If you remove generic programming, tasking, specialized I/O, systems programming, and all the other things most other languages don't supply, then that book would easily be half the size, if not more. To me, the base syntax of Ada is much simpler than Fortran (but the last Fortran I used was Fortran 77), but I have to look up the special things in a book or the RM. Another large part of the book is standard package stuff. I don't know how much of that F95 supplies, so I can't speak to that. -- Corey Minyard Internet: minyard@acm.org Work: minyard@nortel.ca UUCP: minyard@wf-rch.cirr.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-22 0:00 ` Jeff Templon 1998-09-22 0:00 ` Corey Minyard @ 1998-09-22 0:00 ` Larry Kilgallen 1998-09-22 0:00 ` dewarr ` (2 subsequent siblings) 4 siblings, 0 replies; 83+ messages in thread From: Larry Kilgallen @ 1998-09-22 0:00 UTC (permalink / raw) In article <m3n27sqhms.fsf@visar.physast.uga.edu>, Jeff Templon <templon@visar.physast.uga.edu> writes: > So Ada loses in this respect : there is a lot of language to know. > This makes it more difficult to write programs, unless one invests > the time to learn the language well. This amount of time would > be less for Fortran. Certainly Ada is harder than many language if the goal is to "learn the whole language". However in many cases the goal instead is to "learn what is needed for a particular set of programs". I programmed many years in Ada without using any of the Tasking stuff, because I just did not need it for the set of programs I was working on. In fact, since Fortran does not provide built-in Tasking (so far as I know), most programs that would reasonably be written in Fortran would not make use of Tasking either if they instead were written in Ada. Larry Kilgallen ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-22 0:00 ` Jeff Templon 1998-09-22 0:00 ` Corey Minyard 1998-09-22 0:00 ` Larry Kilgallen @ 1998-09-22 0:00 ` dewarr 1998-09-23 0:00 ` Jeff Templon 1998-09-22 0:00 ` Rakesh Malhotra 1998-09-23 0:00 ` Frank Ecke 4 siblings, 1 reply; 83+ messages in thread From: dewarr @ 1998-09-22 0:00 UTC (permalink / raw) In article <m3n27sqhms.fsf@visar.physast.uga.edu>, Jeff Templon <templon@visar.physast.uga.edu> wrote: > Hi, > > one other word on Ada ... it is a very complex language. Take a look > at Cohen's "Ada as a Second Language" book and compare it Metcalf > and Reid's F95 book! Cohen is not spending time on elementary concepts > either. This is obviously written by someone who does not know both languages well. The two books are definitely NOT comparable in semantic detail. But if you *do* know both languages well, you will note that both modern Fortran and Ada are large languages. Neither is complex by my definition of complex, people usually mean large when they say complex (just look at the data in the above paragraph used to support the allegation) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-22 0:00 ` dewarr @ 1998-09-23 0:00 ` Jeff Templon 1998-09-23 0:00 ` Corey Minyard 1998-09-24 0:00 ` Marc A. Criley 0 siblings, 2 replies; 83+ messages in thread From: Jeff Templon @ 1998-09-23 0:00 UTC (permalink / raw) dewarr@my-dejanews.com writes: > This is obviously written by someone who does not know both languages well. > The two books are definitely NOT comparable in semantic detail. But if you I don't know Ada well, although I have waded thru a substantial fraction of both books I mentioned. It is true that Cohen's book goes into more details and has many more examples than does Metcalf/Reid. But I still think what I said is true. > *do* know both languages well, you will note that both modern Fortran and > Ada are large languages. Neither is complex by my definition of complex, > people usually mean large when they say complex (just look at the data > in the above paragraph used to support the allegation) There are two additional factors which affect one when using a complex or large language: 1) how well can you trust the compiler? Compilers are tougher to write for big languages than for smaller ones. It took nearly ten years for reliable Ada compilers to appear once the original Ada definition was released. This is what I've read in software-engineering literature, so don't flame me if it's wrong, write the IEEE. 2) you have to be more careful since with a big language, it is easier to make a mistake in writing the program which turns out to be valid syntax for some feature you didn't know about. I would write some examples, but no time. Sorry. JAT ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-23 0:00 ` Jeff Templon @ 1998-09-23 0:00 ` Corey Minyard 1998-09-24 0:00 ` Joel Seidman 1998-09-24 0:00 ` Craig Burley 1998-09-24 0:00 ` Marc A. Criley 1 sibling, 2 replies; 83+ messages in thread From: Corey Minyard @ 1998-09-23 0:00 UTC (permalink / raw) Jeff Templon <templon@visar.physast.uga.edu> writes: > > 2) you have to be more careful since with a big language, it is > easier to make a mistake in writing the program which turns out > to be valid syntax for some feature you didn't know about. This is not my experience with Ada, but it is with C, a much smaller language. I've only done this once in Ada (Putting a * instead of a ** in a type declaration). Only God knows how many times I've done it in C; I probably can't count that high. It also seemed easy in old Fortran to write code with unintended consequences. I think this has much more to do with the good human engineering design of the language and less to do with the language size. -- Corey Minyard Internet: minyard@acm.org Work: minyard@nortel.ca UUCP: minyard@wf-rch.cirr.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-23 0:00 ` Corey Minyard @ 1998-09-24 0:00 ` Joel Seidman 1998-09-24 0:00 ` Craig Burley 1 sibling, 0 replies; 83+ messages in thread From: Joel Seidman @ 1998-09-24 0:00 UTC (permalink / raw) Corey Minyard wrote: > > Jeff Templon <templon@visar.physast.uga.edu> writes: > > > > 2) you have to be more careful since with a big language, it is > > easier to make a mistake in writing the program which turns out > > to be valid syntax for some feature you didn't know about. > > This is not my experience with Ada, but it is with C, a much smaller > language. I've only done this once in Ada (Putting a * instead of a > ** in a type declaration). Only God knows how many times I've done it > in C; I probably can't count that high. It also seemed easy in old > Fortran to write code with unintended consequences. I think this has > much more to do with the good human engineering design of the language > and less to do with the language size. One of my favorite Fortran "mistakes" is: DO 10 J=1.10 (where comma is intended) This is perfectly good, but probably not intended, Fortran 66, a "small" (?) language. Error-prone is NOT related to language size. It IS related to good human engineering! ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-23 0:00 ` Corey Minyard 1998-09-24 0:00 ` Joel Seidman @ 1998-09-24 0:00 ` Craig Burley 1998-09-25 0:00 ` dewarr 1 sibling, 1 reply; 83+ messages in thread From: Craig Burley @ 1998-09-24 0:00 UTC (permalink / raw) Corey Minyard <minyard@acm.org> writes: > Jeff Templon <templon@visar.physast.uga.edu> writes: > > > > 2) you have to be more careful since with a big language, it is > > easier to make a mistake in writing the program which turns out > > to be valid syntax for some feature you didn't know about. > > This is not my experience with Ada, but it is with C, a much smaller > language. I've only done this once in Ada (Putting a * instead of a > ** in a type declaration). Only God knows how many times I've done it > in C; I probably can't count that high. It also seemed easy in old > Fortran to write code with unintended consequences. I think this has > much more to do with the good human engineering design of the language > and less to do with the language size. IMO, you're absolutely right. And, yes, a typo such as "**" for "*" should produce a diagnostic, but I suspect both Fortran and C suffer from this sort of thing much more than does Ada, simply because Ada is a more recent language and was, I gather, more thoughtfully designed than some other recent languages. -- "Practice random senselessness and act kind of beautiful." James Craig Burley, Software Craftsperson burley@gnu.org ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` Craig Burley @ 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Jonathan Guthrie 1998-09-26 0:00 ` Craig Burley 0 siblings, 2 replies; 83+ messages in thread From: dewarr @ 1998-09-25 0:00 UTC (permalink / raw) In article <y6sohhr11s.fsf@tweedledumb.cygnus.com>, Craig Burley <burley@tweedledumb.cygnus.com> wrote: > IMO, you're absolutely right. And, yes, a typo such as "**" for "*" > should produce a diagnostic, but I suspect both Fortran and C suffer > from this sort of thing much more than does Ada, simply because Ada > is a more recent language and was, I gather, more thoughtfully designed > than some other recent languages. Craig, surely you do not know Ada in writing the above! The character * never has syntactic significance other than as a multiplication operator, and ** is exponentiation. If you mean to write A : constant integer := B * 2; and you write A : constant integer := B ** 2; it sure is difficult to see why you would expect a diagnostic!!!! One could argue that it is unwise to use ** as exponentiation precisely because of this one character differentiation, but that seems a bit extreme to me! -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-25 0:00 ` dewarr @ 1998-09-25 0:00 ` Jonathan Guthrie 1998-09-26 0:00 ` Craig Burley 1 sibling, 0 replies; 83+ messages in thread From: Jonathan Guthrie @ 1998-09-25 0:00 UTC (permalink / raw) In comp.lang.ada dewarr@my-dejanews.com wrote: (snippage in re confusing * and **) > Craig, surely you do not know Ada in writing the above! > The character * never has syntactic significance other > than as a multiplication operator, and ** is exponentiation. > If you mean to write > A : constant integer := B * 2; > and you write > A : constant integer := B ** 2; > it sure is difficult to see why you would expect a > diagnostic!!!! > One could argue that it is unwise to use ** as exponentiation > precisely because of this one character differentiation, but > that seems a bit extreme to me! You know, I am sometimes amazed at the sheer range of computer program languages that seemed to be designed specifically to avoid common errors. A while back, I was involved in a discussion on comp.lang.functional and one of the proponents of Erlang indicated that a primary feature of Erlang was that it eliminated the possibility of many common programmers' errors. This is similar to the point being made here about Ada. However, I made the point that (C style) pointers and (again C-style) assignments in conditionals and such don't seem to cause that much difficulty with my programs. I've spent much more time tracking down reversed branches (doing a section of code when a condition of true when I REALLY want to do it only when the condition is false) and putting '+' when I REALLY want '-' (or similar) than any of what people (who all seem to be promoting other languages) seem to consider the troublesome aspects of C or FORTRAN. I've spent FAR more time tracking down a single hardware problem masquerading as a software problem than I have all of the potential problems fixed by the aspects of Ada's design. If you can invent a computer program language that finds those sorts of errors, I will switch to it immediately and never switch to anything else. Until then, I doubt that switching languages would do very much to my defect rate. So, I don't think it's at all far-fetched to consider replacing '**' with some other character sequence that means exponentiation. One opinion, worth what you paid for it. -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Jonathan Guthrie @ 1998-09-26 0:00 ` Craig Burley 1998-09-26 0:00 ` dewarr 1 sibling, 1 reply; 83+ messages in thread From: Craig Burley @ 1998-09-26 0:00 UTC (permalink / raw) dewarr@my-dejanews.com writes: > In article <y6sohhr11s.fsf@tweedledumb.cygnus.com>, > > Craig Burley <burley@tweedledumb.cygnus.com> wrote: > > > IMO, you're absolutely right. And, yes, a typo such as "**" for "*" > > should produce a diagnostic, but I suspect both Fortran and C suffer > > from this sort of thing much more than does Ada, simply because Ada > > is a more recent language and was, I gather, more thoughtfully designed > > than some other recent languages. > > Craig, surely you do not know Ada in writing the above! I didn't say I *did* know Ada -- in fact, I don't! > The character * never has syntactic significance other > than as a multiplication operator, and ** is exponentiation. Oh, in that case, then, you're right, it's impossible to expect a diagnostic for typos involving "normal math" expressions in a language designed to support such things "natively". > One could argue that it is unwise to use ** as exponentiation > precisely because of this one character differentiation, but > that seems a bit extreme to me! Especially since an alternative, like BASIC's `^', still suffers from a one-character mistake (a two-key-distance difference on my keyboard, anyway). Same for `+' vs. `-', etc. What I thought might be the case was that `**' was substituted in place of `*' in something non-mathematical, e.g. like C's `char *foo;'. In that example, such a typo can lead to really hard-to-track-down behavior, and only programmers highly experienced with that particular area of the language (C declarations) are likely to spot it. (These programmers will have tended to "trade off" expertise in the application area. While working at Cadence, I once spotted exactly this sort of bug while looking over a co-workers' shoulder as he and one or two others had been debugging this bug, involving portability and reproducability problems, for hours. The reason I was able to spot it wasn't due to any genius on my part -- in fact, I had little understanding of what the code was trying to do in the larger sense, so I had no choice but to concentrate on the minutiae.) It's in the notations outside of the typical programmer's "life expertise" that language designers must be extra-careful to avoid constructs in which common typographical mistakes lead to bizarre bugs, IMO. And priority should be given to avoid the most hard-to-see typos in general anyway: `.' vs. `,', `:' vs. `;', `0' vs. `O', `1' vs. `l' vs. `I' vs. `!', and so on. E.g. it is much worse that FORTRAN 77 allows the `.' typo for `,' creating DO 10 I=1.6 than that it allows the `+' typo for `*' creating CIRC=PI+RADIUS because the "expected" audience will spot the latter, "math" error much more easily than the error in the imperative construct (DO). Similarly, C's `=' vs. `==' is a pretty bad problem -- though long- sinced worked around using "clever" software, which helps not one whit when reading printouts -- compared to its `+' vs. `-' in ordinary expressions, because only readers highly experienced with C itself have become accustomed to spotting the former error as easily as most readers of C code would spot the latter (assuming they know the algorithm). It's tempting to avoid the "math" error by further requiring more verbosity in the language design. I believe that, in a language designed for use by Western scientists -- e.g. any language one expects to replace Fortran within 50 years -- that would be a mistake, or at least should be carefully balanced against the flip side of the problem, e.g., an experienced mathematician might be more able to spot the bug in `PI+RADIUS' than in `(plus (pi radius))', having already become accustomed to lexical-infix notation before ever encountering the new language. In summary: language designers should try and restrict their use of narrow lexical distinctions to those areas with which the expected audience is already very familiar, and, in other areas, ensure that common typographical errors are most likely to cause expressions that are immediately discoverable as invalid expressions in the language. -- "Practice random senselessness and act kind of beautiful." James Craig Burley, Software Craftsperson burley@gnu.org ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-26 0:00 ` Craig Burley @ 1998-09-26 0:00 ` dewarr 1998-09-26 0:00 ` Craig Burley 1998-09-26 0:00 ` Robert B. Love 0 siblings, 2 replies; 83+ messages in thread From: dewarr @ 1998-09-26 0:00 UTC (permalink / raw) In article <y63e9fjt7l.fsf@tweedledumb.cygnus.com>, Craig Burley <burley@tweedledumb.cygnus.com> wrote: > I didn't say I *did* know Ada -- in fact, I don't! Perhaps you should learn it :-) > In summary: language designers should try and restrict their use > of narrow lexical distinctions to those areas with which the > expected audience is already very familiar, and, in other areas, > ensure that common typographical errors are most likely to cause > expressions that are immediately discoverable as invalid expressions > in the language. The above paragraph (and the discussion that preceded it) might well be used as a summary of one important part of the Ada design criteria! -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-26 0:00 ` dewarr @ 1998-09-26 0:00 ` Craig Burley 1998-09-26 0:00 ` Robert B. Love 1 sibling, 0 replies; 83+ messages in thread From: Craig Burley @ 1998-09-26 0:00 UTC (permalink / raw) dewarr@my-dejanews.com writes: > In article <y63e9fjt7l.fsf@tweedledumb.cygnus.com>, > Craig Burley <burley@tweedledumb.cygnus.com> wrote: > > > I didn't say I *did* know Ada -- in fact, I don't! > > Perhaps you should learn it :-) Oh, nooooooo kidding! There's *lots* I should go and learn, and I intend to start, sometime soon. Ada's right up there with functional languages, for example. > > In summary: language designers should try and restrict their use > > of narrow lexical distinctions to those areas with which the > > expected audience is already very familiar, and, in other areas, > > ensure that common typographical errors are most likely to cause > > expressions that are immediately discoverable as invalid expressions > > in the language. > > The above paragraph (and the discussion that preceded it) might well be > used as a summary of one important part of the Ada design criteria! I figured as much. And, re-reading the earlier post, indeed someone had indicated `**' was a typo in place of `*' in some kind of type-declaration statement, which led me to believe (perhaps incorrectly) it wasn't in a math expression. FWIW. -- "Practice random senselessness and act kind of beautiful." James Craig Burley, Software Craftsperson burley@gnu.org ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-26 0:00 ` dewarr 1998-09-26 0:00 ` Craig Burley @ 1998-09-26 0:00 ` Robert B. Love 1 sibling, 0 replies; 83+ messages in thread From: Robert B. Love @ 1998-09-26 0:00 UTC (permalink / raw) In <6uigs3$evu$1@nnrp1.dejanews.com> dewarr@my-dejanews.com wrote: > In article <y63e9fjt7l.fsf@tweedledumb.cygnus.com>, > Craig Burley <burley@tweedledumb.cygnus.com> wrote: > > > I didn't say I *did* know Ada -- in fact, I don't! > > Perhaps you should learn it :-) Leave Craig alone. :-) He's doing just fine producin' the g77 compiler. Say, if we could get a GNAT distribution that had g77 built in then it'd be the best of both worlds. You two should work together. And I can have a Gnu Ada t-shirt to go with my Gnu Fortran shirt. ---------------------------------------------------------------- Bob Love MIME & NeXT Mail OK rlove@neosoft.com ---------------------------------------------------------------- ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-23 0:00 ` Jeff Templon 1998-09-23 0:00 ` Corey Minyard @ 1998-09-24 0:00 ` Marc A. Criley 1998-09-24 0:00 ` dewarr ` (2 more replies) 1 sibling, 3 replies; 83+ messages in thread From: Marc A. Criley @ 1998-09-24 0:00 UTC (permalink / raw) Jeff Templon wrote: > > 2) you have to be more careful since with a big language, it is > easier to make a mistake in writing the program which turns out > to be valid syntax for some feature you didn't know about. In 15 years of Ada programming I cannot recall a single instance of activating an unintended language feature through a syntax error. Certainly I have typoed "=" instead of "/=" or misarranged "end"s, but these are exactly mappable to errors in other procedural programming languages. I'm afrad this assertion betrays a lack of familiarity with the syntactic and semantic structure of Ada. > I would write some examples, but no time. Sorry. > > JAT [Robert Dewar mode on :-] It is unreasonable to expect anyone to accept your highly-contested assertions at face value, and cite "no time" as justification for not providing examples for peer review in defense of your point. [RD off] -- Marc A. Criley Chief Software Architect Lockheed Martin ATWCS marc.a.criley@lmco.com Phone: (610) 354-7861 Fax : (610) 354-7308 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` Marc A. Criley @ 1998-09-24 0:00 ` dewarr 1998-09-24 0:00 ` Robert I. Eachus 1998-09-25 0:00 ` jbs 1998-09-24 0:00 ` Jeff Templon [not found] ` <6udre0$ha1$1@nnrp1.dejane <6utg60$h6l$1@nnrp1.dejanews.com> 2 siblings, 2 replies; 83+ messages in thread From: dewarr @ 1998-09-24 0:00 UTC (permalink / raw) Jeff Templon wrote: > > 2) you have to be more careful since with a big language, it is > easier to make a mistake in writing the program which turns out > to be valid syntax for some feature you didn't know about. Well it is certainly a design point of Ada to avoid situations in which small lexical errors cause major differences in the meaning of a program, and I think it achieves this goal pretty well. Certainly better than C for (i = 1; i < 10; i ++); a[i] = i; or Fortran: Do 10 i = 1.6 the latter being the (in)famous bug at the heart of the urban legend that the Venus probe died because of this bug :-) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` dewarr @ 1998-09-24 0:00 ` Robert I. Eachus 1998-09-24 0:00 ` William Clodius 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` jbs 1 sibling, 2 replies; 83+ messages in thread From: Robert I. Eachus @ 1998-09-24 0:00 UTC (permalink / raw) In article <6udre0$ha1$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes: > or Fortran: > Do 10 i = 1.6 > the latter being the (in)famous bug at the heart of the urban > legend that the Venus probe died because of this bug :-) For the record, the launch did fail do to a single character error. But the error was in transcribing the control equations for the booster, not in the actual code derived from them. The error didn't manifest itself on earlier launches, because the instability was second-order. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` Robert I. Eachus @ 1998-09-24 0:00 ` William Clodius 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` dewarr 1 sibling, 1 reply; 83+ messages in thread From: William Clodius @ 1998-09-24 0:00 UTC (permalink / raw) Robert I. Eachus wrote: > <snip> > For the record, the launch did fail do to a single character error. > But the error was in transcribing the control equations for the > booster, not in the actual code derived from them. The error didn't > manifest itself on earlier launches, because the instability was > second-order. > <snip> As near as I can tell the best record of the launch available on the net that is readilly available is the alt.folklore.computers FAQ http://www.nutec.com/employees/wilson/faq/ the launch was lost due a combination of a hardware failure and the software error. The guidance system was designed to process data from two radar sources, one of which (the rate system) failed, revealing the instability of the software error in the processing of the other (track) system. I strongly suspect that the error was first order in its effects, (i.e, the rate data was the most direct measure of motional stability and the system relied exclusively on that data for this part of its analysis while the rate system was operating), but the desciption isn't detailed enough to be certain -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` William Clodius @ 1998-09-25 0:00 ` dewarr 0 siblings, 0 replies; 83+ messages in thread From: dewarr @ 1998-09-25 0:00 UTC (permalink / raw) In article <360AB57E.794B@lanl.gov>, William Clodius <wclodius@lanl.gov> wrote: > Robert I. Eachus wrote: > > <snip> > > For the record, the launch did fail do to a single character error. > > But the error was in transcribing the control equations for the > > booster, not in the actual code derived from them. The error didn't > > manifest itself on earlier launches, because the instability was > > second-order. > > <snip> > > As near as I can tell the best record of the launch available on the net > that is readilly available is the alt.folklore.computers FAQ > > http://www.nutec.com/employees/wilson/faq/ > > the launch was lost due a combination of a hardware failure and the > software error. The guidance system was designed to process data from > two radar sources, one of which (the rate system) failed, revealing the > instability of the software error in the processing of the other (track) > system. I strongly suspect that the error was first order in its > effects, (i.e, the rate data was the most direct measure of motional > stability and the system relied exclusively on that data for this part > of its analysis while the rate system was operating), but the desciption > isn't detailed enough to be certain > > -- > > William B. Clodius Phone: (505)-665-9370 > Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 > PO Box 1663, MS-C323 Group office: (505)-667-5776 > Los Alamos, NM 87545 Email: wclodius@lanl.gov I wish to apologize for starting this completely off-topic thread. My original post was on-topic, but mentioning something like this was unwisely provocative I guess :-) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` Robert I. Eachus 1998-09-24 0:00 ` William Clodius @ 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 83+ messages in thread From: dewarr @ 1998-09-25 0:00 UTC (permalink / raw) In article <EACHUS.98Sep24162806@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) wrote: > In article <6udre0$ha1$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes: > > > or Fortran: > > > Do 10 i = 1.6 > > > the latter being the (in)famous bug at the heart of the urban > > legend that the Venus probe died because of this bug :-) > > For the record, the launch did fail do to a single character error. > But the error was in transcribing the control equations for the > booster, not in the actual code derived from them. The error didn't > manifest itself on earlier launches, because the instability was > second-order. My best understanding is that the DO I = 1.6 type bug was actually in the code at one time, but discovered during simulation. Incidentally there is a remarkable APAR for IBSYS Fortran IV dated around 1967 which read something like "The Fortran compiler miscompiles [the above type of DO] and treats it as an assignment statement. This will be corrected in a future release." TO my knowledge this APAR was never closed :-) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-25 0:00 ` dewarr @ 1998-09-25 0:00 ` Robert I. Eachus 1998-09-25 0:00 ` dewarr 0 siblings, 1 reply; 83+ messages in thread From: Robert I. Eachus @ 1998-09-25 0:00 UTC (permalink / raw) In article <6uenmo$fov$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes: > My best understanding is that the DO I = 1.6 type bug was > actually in the code at one time, but discovered during > simulation. > Incidentally there is a remarkable APAR for IBSYS Fortran > IV dated around 1967 which read something like > "The Fortran compiler miscompiles [the above type of DO] > and treats it as an assignment statement. This will be > corrected in a future release." > TO my knowledge this APAR was never closed :-) I thought it was. Several compilers I used in that time frame would produce warning messages if a reserved word was combined into an identifier, or if any spaces occured in suspicious places. (Unfortunately, I know this because I had to check all warnings on some code which had been written with variable names containing spaces. Fortunately, six, and later eight, character names didn't have much room for mischief like this, but I do remember variables named NO GO and LAST X.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-25 0:00 ` Robert I. Eachus @ 1998-09-25 0:00 ` dewarr 0 siblings, 0 replies; 83+ messages in thread From: dewarr @ 1998-09-25 0:00 UTC (permalink / raw) In article <EACHUS.98Sep25154925@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) wrote: > In article <6uenmo$fov$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes: > > > My best understanding is that the DO I = 1.6 type bug was > > actually in the code at one time, but discovered during > > simulation. > > > Incidentally there is a remarkable APAR for IBSYS Fortran > > IV dated around 1967 which read something like > > > "The Fortran compiler miscompiles [the above type of DO] > > and treats it as an assignment statement. This will be > > corrected in a future release." > > > TO my knowledge this APAR was never closed :-) > > I thought it was. Several compilers I used in that time frame would > produce warning messages if a reserved word was combined into an > identifier, or if any spaces occured in suspicious places. > (Unfortunately, I know this because I had to check all warnings on > some code which had been written with variable names containing > spaces. Fortunately, six, and later eight, character names didn't > have much room for mischief like this, but I do remember variables > named NO GO and LAST X.) Robert, I am not sure you know the terminology I am using here. IBM could hardly close that APAR, since the defect it refers to is not a defect. That's the point, there is no way that a compiler could be stopped from "misclassifying" this statement. The IBM compilers for the 7000 series (both under FMS and IBSYS) did not have warnings of the type you recall, and in any case a warning is not enough to "close" this APAR! By the way, Fortran II had a genuine language ambiguity READ TAPE2, X, Y, Z to read from variable format variable TAPE2 READ TAPE 2, X, Y, Z to read from tape unit number 2. Remember that blanks were insignificant in Fortran II. An undocumented feature was that the Fortran II compiler always chose the second possibility! -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` dewarr 1998-09-24 0:00 ` Robert I. Eachus @ 1998-09-25 0:00 ` jbs 1998-09-26 0:00 ` dewarr 1 sibling, 1 reply; 83+ messages in thread From: jbs @ 1998-09-25 0:00 UTC (permalink / raw) In article <6udre0$ha1$1@nnrp1.dejanews.com>, on Thu, 24 Sep 1998 16:19:12 GMT, dewarr@my-dejanews.com writes: >Jeff Templon wrote: >> >> 2) you have to be more careful since with a big language, it is >> easier to make a mistake in writing the program which turns out >> to be valid syntax for some feature you didn't know about. > >Well it is certainly a design point of Ada to avoid situations >in which small lexical errors cause major differences in the >meaning of a program, and I think it achieves this goal pretty >well. Certainly better than C > > for (i = 1; i < 10; i ++); > a[i] = i; > >or Fortran: > > Do 10 i = 1.6 > >the latter being the (in)famous bug at the heart of the urban >legend that the Venus probe died because of this bug :-) > >-----== Posted via Deja News, The Leader in Internet Discussion ==----- >http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-25 0:00 ` jbs @ 1998-09-26 0:00 ` dewarr 1998-09-28 0:00 ` jbs 0 siblings, 1 reply; 83+ messages in thread From: dewarr @ 1998-09-26 0:00 UTC (permalink / raw) 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 Well as I made perfectly clear in my post, that this Fortran bug *caused* the mission failure is urban legend, but it did indeed cause a serious simulator failure at a late stage as I understand, and I think the point is clear that the language design is seriously defective in this respect, surely no one would contest that. The reason that Ada is not blamed for Ariane is that it is not at fault! The program performed according to its specifications, but it was the specifications that were faulty. Reusing a program without proper testing and examination of changing specifications is a bad thing regardless of language. I don't think you can make any very convincing argument that one language is more resiliant to this kind of incompetence than another! On the other hand, there is a useful lesson to be learned, not about any design weakness in Ada, but about how to use any language with runtime error checking carefully. Runtime error checking is a very powerful tool, but like any tool it can be misused. Enabling any kind of runtime checking, whether it is built into the language or into the program explicitly does not necessarily improve the reliability of the program, and indeed, as in the Ariane case, if you don't properly consider what to do if an error check fails, can even have negative effects. 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. Arguing that Fortran is better than Ada wrt Ariane is a bit like arguing that CD ROM drives that swallow your disk are better than ones that have a tray that pops out, in view of the famous (but perhaps apocryphal) tail of the Gateway user complaining to Gateway support that his built in beer can holder on his computer had broken off! Just because someone can misuse a tool is not a good argument for a language that completely lacks the corresponding capability. Actually this still isn't quite fair, there really was no *misuse* of the runtime checking in the Ariane case. The original design had indeed considered and addressed the issue of overflow in this case, and proved that, given the specification, it was not a problem (this is generally the approach that one must take with such issues in a critical program). The fact that this issue was not revisited when the code was reused was a serious procedural error. Consider for example the following alternative scenario. Let's suppose that the check had been carefully turned off in the original code, after proving that the overflow could not occur anyway. Now when the code is moved to a situation where the overflow did occur because of unexamined changing specifications, then instead of signalling a trap, computation continues with garbage values. It is VERY easy to imagine a situation where this would be disastrous, and it would be *better* to signal an overflow, if the signal was caught correctly. When you make a very serious logic mistake in a program, the behavior of the program is often highly unpredictable, and it is difficult to argue about the language consequences, unless you could argue that the language could have prevented or discouraged the error, which is clearly not the case for Ariane. 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. 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. Now I agree that Fortran gets a bad rap for the Venus probe. Urban legends definitely grow over time. Who knows what people will say about Ada and Ariane twenty years from now :-) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-26 0:00 ` dewarr @ 1998-09-28 0:00 ` jbs 1998-09-29 0:00 ` William B. Clodius ` (6 more replies) 0 siblings, 7 replies; 83+ messages in thread From: jbs @ 1998-09-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-28 0:00 ` jbs @ 1998-09-29 0:00 ` William B. Clodius 1998-09-30 0:00 ` jbs 1998-09-29 0:00 ` Dean F. Sutherland ` (5 subsequent siblings) 6 siblings, 1 reply; 83+ messages in thread From: William B. Clodius @ 1998-09-29 0:00 UTC (permalink / raw) In article <19980928.184428.604@yktvmv.watson.ibm.com>, jbs@yktvmv.watson.ibm.com wrote: jbs@yktvmv.watson.ibm.com wrote: > <snip> > 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. > <snip> > 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. > <snip> > > 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. > <snip> 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-29 0:00 ` William B. Clodius @ 1998-09-30 0:00 ` jbs 1998-09-30 0:00 ` William Clodius ` (2 more replies) 0 siblings, 3 replies; 83+ messages in thread From: jbs @ 1998-09-30 0:00 UTC (permalink / raw) In article <wclodius-2909981741110001@clodius.lanl.gov>, on Tue, 29 Sep 1998 17:41:11 -0600, wclodius@lanl.gov (William B. Clodius) writes (in part): >In article <19980928.184428.604@yktvmv.watson.ibm.com>, >jbs@yktvmv.watson.ibm.com wrote: >> 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. >> <snip> > >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 The accident report indicates that they deliberately chose not to do it in this case because they were worried about performance. This would seem to indicate that turning off the error check is not cheap (in terms of performance). James B. Shearer ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-30 0:00 ` jbs @ 1998-09-30 0:00 ` William Clodius 1998-09-30 0:00 ` dewarr 1998-10-03 0:00 ` Niklas Holsti 2 siblings, 0 replies; 83+ messages in thread From: William Clodius @ 1998-09-30 0:00 UTC (permalink / raw) jbs@yktvmv.watson.ibm.com wrote: > <snip> > The accident report indicates that they deliberately > chose not to do it in this case because they were worried about > performance. This would seem to indicate that turning off the > error check is not cheap (in terms of performance). > James B. Shearer I repeat: "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. As a result every potential and unnecessary increase in processor load is avoided however small. However, this was only one of several reasons given for not protecting this value. Protecting this value (for the Ariane 4) was viewed as unnecessary and dangerous. Quoting the report. "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." -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-30 0:00 ` jbs 1998-09-30 0:00 ` William Clodius @ 1998-09-30 0:00 ` dewarr 1998-09-30 0:00 ` jbs 1998-10-03 0:00 ` Niklas Holsti 2 siblings, 1 reply; 83+ messages in thread From: dewarr @ 1998-09-30 0:00 UTC (permalink / raw) In article <19980929.214309.386@yktvmv.watson.ibm.com>, jbs@yktvmv.watson.ibm.com wrote: > The accident report indicates that they deliberately > chose not to do it in this case because they were worried about > performance. This would seem to indicate that turning off the > error check is not cheap (in terms of performance). > James B. Shearer This is incomprehensible. Turning off a check eliminates the code for the check and eliminates the performance penalty of the check. What are you trying to say here? -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-30 0:00 ` dewarr @ 1998-09-30 0:00 ` jbs 1998-09-30 0:00 ` William Clodius 0 siblings, 1 reply; 83+ messages in thread From: jbs @ 1998-09-30 0:00 UTC (permalink / raw) In article <6utg60$h6l$1@nnrp1.dejanews.com>, on Wed, 30 Sep 1998 14:45:20 GMT, dewarr@my-dejanews.com writes: >In article <19980929.214309.386@yktvmv.watson.ibm.com>, > jbs@yktvmv.watson.ibm.com wrote: >> The accident report indicates that they deliberately >> chose not to do it in this case because they were worried about >> performance. This would seem to indicate that turning off the >> error check is not cheap (in terms of performance). >> James B. Shearer > > >This is incomprehensible. Turning off a check eliminates the code for the >check and eliminates the performance penalty of the check. What are you >trying to say here? Let me quote the accident report again: !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. It appears you do not turn off the check, instead you "protect" the check which is expensive. James B. Shearer ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-30 0:00 ` jbs @ 1998-09-30 0:00 ` William Clodius 0 siblings, 0 replies; 83+ messages in thread From: William Clodius @ 1998-09-30 0:00 UTC (permalink / raw) jbs@yktvmv.watson.ibm.com wrote: > <snip> > It appears you do not turn off the check, instead you "protect" > the check which is expensive. > <snip> No. You can turn off the check, but this implies that you are accepting garbage as an output. Accepting garbage is rarely desirable, although it might have been less harmful for the Ariane 5 than what actually happened. In order to preserve information, you protect the variables being checked, which may in turn depend on the results of the check. In the simplest case this would result in the variable being set to an extrema, i.e., too large a value being set to the largest integer value, but this too results in a loss of information. You know you overflowed but not by how much. More sophisticated would be to replace the normal linear function with a non linear function so that precision is lost as you approach and surpass the overflow value for the original linear transformation. -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-30 0:00 ` jbs 1998-09-30 0:00 ` William Clodius 1998-09-30 0:00 ` dewarr @ 1998-10-03 0:00 ` Niklas Holsti 1998-10-03 0:00 ` Toon Moene 2 siblings, 1 reply; 83+ messages in thread From: Niklas Holsti @ 1998-10-03 0:00 UTC (permalink / raw) jbs@yktvmv.watson.ibm.com wrote: > > In article <wclodius-2909981741110001@clodius.lanl.gov>, > on Tue, 29 Sep 1998 17:41:11 -0600, > wclodius@lanl.gov (William B. Clodius) writes (in part): > >In article <19980928.184428.604@yktvmv.watson.ibm.com>, > >jbs@yktvmv.watson.ibm.com wrote: > >> 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. > >> <snip> > > > >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 > > The accident report indicates that they deliberately > chose not to do it in this case because they were worried about > performance. This would seem to indicate that turning off the > error check is not cheap (in terms of performance). > James B. Shearer This discussion of "turning off error checks" seems to assume that the culprit in the Ariane-501 accident was the run-time checking and exception handling required by Ada. This is probably not the case. As I understand it (without having seen the Ada code, though), what occurred was that the Ada code called for a type conversion from float to integer, I := integer(F); the Ada compiler translated this into a machine instruction; the machine instruction caused a machine trap since the floating operand was too large; the trap handler (in this application) assumed a hardware error and shut down the computer. The trap would as well have occurred in a Fortran program, assuming that the Fortran compiler used the same machine instruction, as seems likely. I suspect that the Ada-defined run-time checks were turned off by pragma or compiler option, since this is common in space-related software. The trap could probably have been masked (in hardware), or a no-operation trap handler used, at no performance overhead. This was not done because the designers wanted to detect overflow traps as symptoms of errors, causing a switch to the redundant system. The "protection" spoken of probably means nesting the conversion in an explicit range check, to prevent the trap from occurring: if (F is in the acceptable range) then I := integer(F); else (do some recovery, eg. set I to a boundary value, or trigger a switch to the redundant system) end if; Such "protection" obviously adds some processing load. The designers analysed the range of F and found that (for Ariane 4) there was no risk of exceeding the acceptable range, and therefore no need for this "protection". If Ada checks were enabled, the same "protection" could have been coded as begin I := integer(F); exception when Constraint_Error => (do some recovery) end; The processing cost of this solution depends on the Ada implementation. Present-day implementations seem to favour a zero cost for the "no exception" case, with perhaps a larger cost when the exception is raised. There may be some cost in translating the machine trap into the Ada Constraint_Error exception. If this interpretation of the A-501 report is correct, the Ada-defined run-time checks and exception handling are definitely not to blame for the accident, since they played no role in it. If the interpretation is wrong, and Ada exceptions were used, in my view the fault was in the poor specification and careless reuse rather than in the Ada exception mechanism, which did what it was asked to do. The above comment, in part speculative, is based only on the public A-501 report and on my experience with space software; I don't have access to the A-501 Ada code. Niklas Holsti Space Systems Finland Ltd (This message reflects personal opinion, not Space Systems Finland policy) ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-03 0:00 ` Niklas Holsti @ 1998-10-03 0:00 ` Toon Moene 1998-10-03 0:00 ` Niklas Holsti 0 siblings, 1 reply; 83+ messages in thread From: Toon Moene @ 1998-10-03 0:00 UTC (permalink / raw) Niklas Holsti <nholsti@icon.fi> wrote: > As I understand it (without having seen the Ada code, though), what > occurred was that the Ada code called for a type conversion from float > to integer, I := integer(F); the Ada compiler translated this into a > machine instruction; the machine instruction caused a machine trap since > the floating operand was too large; the trap handler (in this > application) > assumed a hardware error and shut down the computer. The trap would > as well have occurred in a Fortran program, assuming that the Fortran > compiler used the same machine instruction, as seems likely. The trap would have occurred; however, because Fortran doesn't define a trap handling mechanism (and certainly not one specifiable by the programmer), it would just have result in a software error. > If the interpretation is wrong, and Ada exceptions were used, in my view > the fault was in the poor specification and careless reuse rather than > in the Ada exception mechanism, which did what it was asked to do. No. The problem is in the expectation of Ada programmers that software errors should be handled the same as hardware errors, by trapping them via a software trap handler specified by the programmer. Software errors should be handled by careful, defensive programming, not CYA. I believe I even recall that a remark like this is in the report. -- Toon Moene (mailto:toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 g77 Support: mailto:fortran@gnu.org; egcs: mailto:egcs-bugs@cygnus.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-03 0:00 ` Toon Moene @ 1998-10-03 0:00 ` Niklas Holsti 1998-10-03 0:00 ` Toon Moene 0 siblings, 1 reply; 83+ messages in thread From: Niklas Holsti @ 1998-10-03 0:00 UTC (permalink / raw) Toon Moene wrote: > > Niklas Holsti <nholsti@icon.fi> wrote: [ snip ] > > If the interpretation is wrong, and Ada exceptions were used, in my view > > the fault was in the poor specification and careless reuse rather than > > in the Ada exception mechanism, which did what it was asked to do. > > No. The problem is in the expectation of Ada programmers that software > errors should be handled the same as hardware errors, by trapping them via a > software trap handler specified by the programmer. Software errors should be > handled by careful, defensive programming, not CYA. I think this "expectation" is reasonable, when recovery is possible by the software itself. In the Ariane-501, the attempted recovery was to switch to a backup system with identical software, which of course is unlikely to work for a software design error of this type. This error-handling policy was imposed on the programmers, as the report makes clear. It is not clear what the programmers would have chosen to do. Of course I agree that defensive programming is useful, but when resources are limited, so must the defenses be; in the Ariane 4, the decision to leave the problematic conversion "undefended" was safe and contributed to meeting the resource constraints. In fact, I would class exception handling as one type of defensive programming, and a very good one, too. (Note that in Ada, it is easy to define local exception handling, for a single statement if need be, instead of relying on a global trap handler which has little knowledge of the context of the problem.) > I believe I even recall that a remark like this is in the report. Perhaps it was somewhere in the following quotes: "It was the decision to cease the processor operation which finally proved fatal. [ ... ] The reason behind this drastic action lies in the culture within the Ariane programme of only addressing random hardware failures. From this point of view exception - or error - handling mechanisms are designed for a random hardware failure which can quite rationally be handled by a backup system. [ ... ] There is reason for concern that a software exception should be allowed, or even required, to cause a processor to halt while handling mission-critical equipment. [ ... ] The exception was detected, but inappropriately handled because the view had been taken that software should be considered correct until it is shown to be at fault. The Board has reason to believe that this view is also accepted in other areas of Ariane 5 software design. The Board is in favour of the opposite view, that software should be assumed to be faulty until applying the currently accepted best practice methods can demonstrate that it is correct." I think the report criticises the assumption that a trap ("exception") indicated hardware failure rather than software failure. I don't see any criticism of software exception-handling as such, just a suggestion that the most likely cause of a software exception is a software fault, with which I agree. > > -- > Toon Moene (mailto:toon@moene.indiv.nluug.nl) > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > Phone: +31 346 214290; Fax: +31 346 214286 > g77 Support: mailto:fortran@gnu.org; egcs: mailto:egcs-bugs@cygnus.com Niklas Holsti Space Systems Finland Ltd. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-03 0:00 ` Niklas Holsti @ 1998-10-03 0:00 ` Toon Moene 1998-10-04 0:00 ` Niklas Holsti 0 siblings, 1 reply; 83+ messages in thread From: Toon Moene @ 1998-10-03 0:00 UTC (permalink / raw) Niklas Holsti <nholsti@icon.fi> wrote: > I wrote: > > No. The problem is in the expectation of Ada programmers that software > > errors should be handled the same as hardware errors, by trapping them via a > > software trap handler specified by the programmer. Software errors should be > > handled by careful, defensive programming, not CYA. and you quoted from the report: <quote> > [ ... ] The exception was detected, but inappropriately handled because > the view had been taken that software should be considered correct > until it is shown to be at fault. The Board has reason to believe > that this view is also accepted in other areas of Ariane 5 software > design. The Board is in favour of the opposite view, that software > should be assumed to be faulty until applying the currently accepted > best practice methods can demonstrate that it is correct." </quote> > I think the report criticises the assumption that a trap ("exception") > indicated hardware failure rather than software failure. I don't > see any criticism of software exception-handling as such, just a > suggestion that the most likely cause of a software exception is > a software fault, with which I agree. OK, good point - I was probably reading it in a different way because I am not used to thinking of "exceptions" as anything a "user routine" should take care of. In my mind, an exception is a sign that the assumptions behind the (physics/mathematics) of your model is wrong, and - even though that pertains to a large extent also to rocket ascent - this would not lead to a reasonably safe procedure here. -- Toon Moene (mailto:toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 g77 Support: mailto:fortran@gnu.org; egcs: mailto:egcs-bugs@cygnus.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-03 0:00 ` Toon Moene @ 1998-10-04 0:00 ` Niklas Holsti 1998-10-05 0:00 ` Michel OLAGNON 0 siblings, 1 reply; 83+ messages in thread From: Niklas Holsti @ 1998-10-04 0:00 UTC (permalink / raw) Toon Moene wrote: > > In my mind, an exception is a sign that the assumptions behind the > (physics/mathematics) of your model is wrong, and - even though that pertains > to a large extent also to rocket ascent - this would not lead to a reasonably > safe procedure here. Yes, this is one category of exceptions (the other category is where exception handling is used to catch rare but foreseeable situations, such as errors in input data files -- END= and ERR= labels, for example). It seems that the designers of the Ariane 4 guidance system had this view, except that their "model" included the processing hardware in addition to the models encoded in the software. To decide how to handle the overflow exception, they had to guess which part of their model was at fault -- whether the hardware or the software was wrong. They guessed "hardware error". In the context of Ariane 4, it hasn't been shown that this was the wrong thing to do. The odds in this guess must depend on how well the software models were verified and validated. I haven't seen any claims that the software models were not correct for Ariane 4. Niklas Holsti Space Systems Finland Ltd (This comment expresses personal opinion and not Space Systems Finland policy.) ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-04 0:00 ` Niklas Holsti @ 1998-10-05 0:00 ` Michel OLAGNON 1998-10-05 0:00 ` Ian St. John 0 siblings, 1 reply; 83+ messages in thread From: Michel OLAGNON @ 1998-10-05 0:00 UTC (permalink / raw) In article <3617AA49.340A5899@icon.fi>, Niklas Holsti <nholsti@icon.fi> writes: >Toon Moene wrote: >> >> In my mind, an exception is a sign that the assumptions behind the >> (physics/mathematics) of your model is wrong, and - even though that pertains >> to a large extent also to rocket ascent - this would not lead to a reasonably >> safe procedure here. > >Yes, this is one category of exceptions (the other category is where >exception handling is used to catch rare but foreseeable situations, >such >as errors in input data files -- END= and ERR= labels, for example). > >It seems that the designers of the Ariane 4 guidance system had this >view, except that their "model" included the processing hardware in >addition to the models encoded in the software. To decide how to handle >the overflow exception, they had to guess which part of their model was >at fault -- whether the hardware or the software was wrong. They guessed >"hardware error". In the context of Ariane 4, it hasn't been shown that >this was the wrong thing to do. > At the time of writing the software, it might not have been wrong. But later on, the launch procedure was changed for Ariane 4, and the computation no longer needed. IMHO, not removing unnecessary computations that may have side effects IS a "software error". The designers failed, IMHO, to note that even if hardware might be more likely to be wrong than software at time T0, over the whole expected service life of the system, it was software that had the highest probability to end up wrong. >The odds in this guess must depend on how well the software models were >verified and validated. I haven't seen any claims that the software >models were not correct for Ariane 4. > >Niklas Holsti >Space Systems Finland Ltd >(This comment expresses personal opinion and not Space Systems Finland >policy.) Michel -- | Michel OLAGNON email : Michel.Olagnon@ifremer.fr| | IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer| | Centre de Brest - B.P. 70 phone : +33-2-9822 4144| | F-29280 PLOUZANE - FRANCE fax : +33-2-9822 4650| | http://www.ifremer.fr/ditigo/molagnon/molagnon.html | ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-05 0:00 ` Michel OLAGNON @ 1998-10-05 0:00 ` Ian St. John 1998-10-05 0:00 ` dewarr ` (2 more replies) 0 siblings, 3 replies; 83+ messages in thread From: Ian St. John @ 1998-10-05 0:00 UTC (permalink / raw) Michel OLAGNON wrote in message <6v9s4t$egn$1@ys.ifremer.fr>... >In article <3617AA49.340A5899@icon.fi>, Niklas Holsti <nholsti@icon.fi> writes: <snip> >> >At the time of writing the software, it might not have been wrong. >But later on, the launch procedure was changed for Ariane 4, and >the computation no longer needed. IMHO, not removing unnecessary >computations that may have side effects IS a "software error". > >The designers failed, IMHO, to note that even if hardware might >be more likely to be wrong than software at time T0, over the whole >expected service life of the system, it was software that had the highest >probability to end up wrong. > IMHO, well tested software doesn't fail. Hardware does. At least, in the sense of random errors. Software can have systematic errors, or design limitations. Random errors and unexpected data indicate hardware problems. The problem in the Arianne 5 case, were that there was no proper review of whether the software testing was *valid* for arianne 5. This was a *management* issue, not a technology issue. If the Arianne 4 had reported such values ( causing overflow ) it *would* have been a hardware error. This was taken into the design, and is correct as such. The software was *correct* for the mission it was designed for ( Arianne 4 ). You cannot expect software re-use without evaluation of the interface/inputs. Nor can you design software with the viewpoint that it *might* be used in the first warp drive spaceship. KISS, and stick to reality. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-05 0:00 ` Ian St. John @ 1998-10-05 0:00 ` dewarr 1998-10-05 0:00 ` Ian St. John 1998-10-05 0:00 ` Richard D Riehle 1998-10-06 0:00 ` Michel OLAGNON 2 siblings, 1 reply; 83+ messages in thread From: dewarr @ 1998-10-05 0:00 UTC (permalink / raw) In article <3618dc33.0@news.passport.ca>, "Ian St. John" <istjohn@high-sense.com> wrote: > IMHO, well tested software doesn't fail. Hardware does. At least, in the > sense of random errors. Software can have systematic errors, or design > limitations. Random errors and unexpected data indicate hardware problems. Well you can of course make your "HO" valid by simply defining any testing that results in software with bugs as not meeting your criteria for testing "well". But in practice it would surprise me if anyone these days would propose that testing alone is sufficient for guaranteeing freedom from failure in software. This is hardly controversial, indeed what would be controversial at this stage is precisely this view (that testing *could* be sufficient). -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-05 0:00 ` dewarr @ 1998-10-05 0:00 ` Ian St. John 1998-10-06 0:00 ` dewarr 0 siblings, 1 reply; 83+ messages in thread From: Ian St. John @ 1998-10-05 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote in message <6vbhhc$5kj$1@nnrp1.dejanews.com>... > >Well you can of course make your "HO" valid by simply defining any testing >that results in software with bugs as not meeting your criteria for testing >"well". But in practice it would surprise me if anyone these days would >propose that testing alone is sufficient for guaranteeing freedom from >failure in software. This is hardly controversial, indeed what would be >controversial at this stage is precisely this view (that testing *could* >be sufficient). Testing by itself can never guarantee correct code. The testing is just to determine syntax errors, oversights, etc. The real software engineering comes in designing the software, and evaluating what limits you put on the possible model. If you have designed the code correctly, and tested well, first on the component level, up to the full integration level, there are very few ways for software to fail that do not come to light. The gain in reliability continues with each launch or test. On the other hand, the hardware is new, on each launch. Reliablility for each part times, accumulated over the number of critical parts, results in hardware being a better assumption in failure handling. Nothing I have heard says that the design team failed in correctly coding for the *job it was intended for*. An overflow in the value, would have had to be a hardware error, on the *system it was designed for*. The failure ( I repeat ) was in management for not doing a full re-evaluation of the software limits, and assumptions. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-05 0:00 ` Ian St. John @ 1998-10-06 0:00 ` dewarr 1998-10-06 0:00 ` Ian St. John ` (2 more replies) 0 siblings, 3 replies; 83+ messages in thread From: dewarr @ 1998-10-06 0:00 UTC (permalink / raw) In article <YGdS1.73461$hx3.8968466@HME2.newscontent-01.sprint.ca>, "Ian St. John" <istjohn@sprint.ca> wrote: > > Testing by itself can never guarantee correct code. The testing is just to > determine syntax errors, oversights, etc. That's a bit strong, there are definitely cases where testing can be exhaustive, e.g. in checking out a sqrt routine for IEEE short form arithmetic. Indeed it is almost practical to do exhaustive testing on long format division (which would have saved Intel many millions of dollars :-) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` dewarr @ 1998-10-06 0:00 ` Ian St. John 1998-10-08 0:00 ` Gary L. Scott 1998-10-08 0:00 ` Offtopic Airport Diversion (Was: Fortran or Ada?) Harold Stevens ** PLEASE SEE SIG ** 1998-10-06 0:00 ` Fortran or Ada? Toon Moene 1998-10-06 0:00 ` James Giles 2 siblings, 2 replies; 83+ messages in thread From: Ian St. John @ 1998-10-06 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote in message <6vdfq4$p1$1@nnrp1.dejanews.com>... >In article <YGdS1.73461$hx3.8968466@HME2.newscontent-01.sprint.ca>, > "Ian St. John" <istjohn@sprint.ca> wrote: >> >> Testing by itself can never guarantee correct code. The testing is just to >> determine syntax errors, oversights, etc. > >That's a bit strong, there are definitely cases where testing can be >exhaustive, e.g. in checking out a sqrt routine for IEEE short form >arithmetic. Indeed it is almost practical to do exhaustive testing on >long format division (which would have saved Intel many millions of >dollars :-) Exhaustive testing would have taken way too long. And if you test exhaustively for real*4, does that mean that real*8 or real*10 values are correct? Much faster to verify the lookup table as having been copied over correctly. That had already been 'exhaustively tested'. Nobody looked. That is when problems creep in. Management oversights, decisions, and plain lack of common sense. 'Check that it's plugged in *first*'. Like the Dallas airport. A two hour session with LISP would have told them that the queuing for the luggage carts wouldn't work. ( Test reported in IEEE spectrum or computer mag analyzing failure ). The multi-million dollar fullblown simulator that was to verify the design of the program was still being 'debugged' long after the airport went into operation. It was scheduled to be finished a year after it became totally irrelevant. Can you tell me why they built a multi-million dollar simulator that wouldn't give them the answer in time to be of any use? Duuuuhhhhhh. Guess someone wanted a big budget project. Another example of why testing will never guarantee correct coding might be the Win95 midnight bug. It bumps the date by two days if you happen to shut down on a particular second before midnight. It took Microsoft days to confirm the bug, even having good evidence it was there, because it had to be one specific second, and that changed with the cpu speed, etc. Complicated systems just can't be 'exhaustively' tested. Each new subsystem in Win95, or Vxd, or DLL makes for that many more combinations of interactions. You get a "combinatorial explosion". Brute force doesn't work. It has to be a combination of design, mathematics, testing, and management. How does this module affect others? Will any new timing delays affect latency in this realtime module. Etc. And you may never get that 'last bug'. People coded it, and some programmers are better than others. So you design it with robust operation in mind. Then keep squashing them, as they come out, until you just can't find any more. You have Bill analyze Fred's code, Harry analyze Bill's code, and Fred analyze Harry's code. Change the assignments, etc. to keep everyone aware of the big picture, and how implementation details may affect the likelyhood of specific failures. Have group discussions, where details can be brought to light. Someone may have experience ( like LISP programming ) that can simplify the testing, or point to possible failure modes not currently in discussion. **** NOTE: These opinions are my own. I am old enough to make up my own mind, so there.. **** ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` Ian St. John @ 1998-10-08 0:00 ` Gary L. Scott 1998-10-08 0:00 ` Offtopic Airport Diversion (Was: Fortran or Ada?) Harold Stevens ** PLEASE SEE SIG ** 1 sibling, 0 replies; 83+ messages in thread From: Gary L. Scott @ 1998-10-08 0:00 UTC (permalink / raw) Ian St. John wrote: > dewarr@my-dejanews.com wrote in message > <6vdfq4$p1$1@nnrp1.dejanews.com>... > >In article <YGdS1.73461$hx3.8968466@HME2.newscontent-01.sprint.ca>, > > "Ian St. John" <istjohn@sprint.ca> wrote: > >> > >> Testing by itself can never guarantee correct code. The testing is > just > to > >> determine syntax errors, oversights, etc. > > > >That's a bit strong, there are definitely cases where testing can be > >exhaustive, e.g. in checking out a sqrt routine for IEEE short form > >arithmetic. Indeed it is almost practical to do exhaustive testing on > > >long format division (which would have saved Intel many millions of > >dollars :-) > > Exhaustive testing would have taken way too long. And if you test > exhaustively for real*4, does that mean that real*8 or real*10 values > are > correct? Much faster to verify the lookup table as having been copied > over > correctly. That had already been 'exhaustively tested'. Nobody looked. > That > is when problems creep in. > > Management oversights, decisions, and plain lack of common sense. > 'Check > that it's plugged in *first*'. > Wasn't that the Denver airport? > Like the Dallas airport. A two hour session with LISP would have told > them > that the queuing for the luggage carts wouldn't work. ( Test reported > in > IEEE spectrum or computer mag analyzing failure ). The multi-million > dollar > fullblown simulator that was to verify the design of the program was > still > being 'debugged' long after the airport went into operation. It was > scheduled to be finished a year after it became totally irrelevant. > > Can you tell me why they built a multi-million dollar simulator that > wouldn't give them the answer in time to be of any use? Duuuuhhhhhh. > Guess > someone wanted a big budget project. > > Another example of why testing will never guarantee correct coding > might be > the Win95 midnight bug. It bumps the date by two days if you happen to > shut > down on a particular second before midnight. It took Microsoft days to > > confirm the bug, even having good evidence it was there, because it > had to > be one specific second, and that changed with the cpu speed, etc. > > Complicated systems just can't be 'exhaustively' tested. Each new > subsystem > in Win95, or Vxd, or DLL makes for that many more combinations of > interactions. You get a "combinatorial explosion". Brute force doesn't > work. > > It has to be a combination of design, mathematics, testing, and > management. > How does this module affect others? Will any new timing delays affect > latency in this realtime module. Etc. And you may never get that 'last > bug'. > > People coded it, and some programmers are better than others. So you > design > it with robust operation in mind. Then keep squashing them, as they > come > out, until you just can't find any more. You have Bill analyze Fred's > code, > Harry analyze Bill's code, and Fred analyze Harry's code. Change the > assignments, etc. to keep everyone aware of the big picture, and how > implementation details may affect the likelyhood of specific failures. > Have > group discussions, where details can be brought to light. Someone may > have > experience ( like LISP programming ) that can simplify the testing, or > point > to possible failure modes not currently in discussion. > > **** NOTE: These opinions are my own. I am old enough to make up my > own > mind, so there.. **** -- Gary L. Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Offtopic Airport Diversion (Was: Fortran or Ada?) 1998-10-06 0:00 ` Ian St. John 1998-10-08 0:00 ` Gary L. Scott @ 1998-10-08 0:00 ` Harold Stevens ** PLEASE SEE SIG ** 1998-10-08 0:00 ` Ian St. John 1 sibling, 1 reply; 83+ messages in thread From: Harold Stevens ** PLEASE SEE SIG ** @ 1998-10-08 0:00 UTC (permalink / raw) In <361a94ca.0@news.passport.ca>, Ian St. John: [Snip...] |> Management oversights, decisions, and plain lack of common sense. 'Check |> that it's plugged in *first*'. |> |> Like the Dallas airport. A two hour session with LISP would have told them |> that the queuing for the luggage carts wouldn't work. ( Test reported in |> IEEE spectrum or computer mag analyzing failure ). The multi-million dollar [Snip...] JFTR, ITYM the new Denver International Airport. IIRC, the company doing that installation in Denver was based in the DFW area. DFW Airport has its own set of fiascos, but most luggage handling is not usually noted among them. :) Besides, why give them any more reasons to pelt obnoxious Texans as they do a good enough job offending the Colorado population during ski season anyway. Ever hear of the Tomato Wars? :) Regards, Weird (Harold Stevens) ** IMPORTANT EMAIL INFO ** 1. As antispam, I have completely disabled my "adam" email account. 2. Please vent inconvenience at Cyberpromo and their Satanic spawn. 3. You might try finding (wyrd) at ti, dotted with com. NO UCE/UBE. 4. I detest UCE/UBE. I support CAUCE; http://www.cauce.org HR 1748. Standard Disclaimer: My opinions alone and not Raytheon TI Systems. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Offtopic Airport Diversion (Was: Fortran or Ada?) 1998-10-08 0:00 ` Offtopic Airport Diversion (Was: Fortran or Ada?) Harold Stevens ** PLEASE SEE SIG ** @ 1998-10-08 0:00 ` Ian St. John 0 siblings, 0 replies; 83+ messages in thread From: Ian St. John @ 1998-10-08 0:00 UTC (permalink / raw) Harold Stevens ** PLEASE SEE SIG ** wrote in message <6vi0vl$o1g@sf18.dseg.ti.com>... >In <361a94ca.0@news.passport.ca>, Ian St. John: > >JFTR, ITYM the new Denver International Airport. IIRC, the company doing >that installation in Denver was based in the DFW area. > >DFW Airport has its own set of fiascos, but most luggage handling is not >usually noted among them. :) Ooops. MEA CULPA. Good thing we have peer review, eh? I hope my coding isn't affected, affected, affected .. ;-) ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` dewarr 1998-10-06 0:00 ` Ian St. John @ 1998-10-06 0:00 ` Toon Moene 1998-10-06 0:00 ` Jonathan Guthrie 1998-10-06 0:00 ` James Giles 2 siblings, 1 reply; 83+ messages in thread From: Toon Moene @ 1998-10-06 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote: > In article <YGdS1.73461$hx3.8968466@HME2.newscontent-01.sprint.ca>, > "Ian St. John" <istjohn@sprint.ca> wrote: > > Testing by itself can never guarantee correct code. The testing is just to > > determine syntax errors, oversights, etc. > That's a bit strong, there are definitely cases where testing can be > exhaustive, e.g. in checking out a sqrt routine for IEEE short form > arithmetic. Indeed it is almost practical to do exhaustive testing on > long format division (which would have saved Intel many millions of > dollars :-) On what platform would that be true ? (granted, the error also showed up on 32-bit FDIV, but was originally found using 64-bit arithmetic). There are about 2**(23*2) single precision floating division pairs because only the mantissa was relevant (give or take a factor of two). Given that the Pentium could natively do an FDIV in 39 cycles, that means that at 78 Mhz (for ease of reference), you'd need 2**45/10**6 seconds, or about (2**20 ~ 10**6) 32 million seconds ~ 1 year. Note that this is just the time for the FDIVs, not the comparisons. I would be interested in a testing strategy that would do an exhaustive search on the double precision space. -- Toon Moene (mailto:toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 g77 Support: mailto:fortran@gnu.org; egcs: mailto:egcs-bugs@cygnus.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` Fortran or Ada? Toon Moene @ 1998-10-06 0:00 ` Jonathan Guthrie 0 siblings, 0 replies; 83+ messages in thread From: Jonathan Guthrie @ 1998-10-06 0:00 UTC (permalink / raw) In comp.lang.ada Toon Moene <toon@moene.indiv.nluug.nl> wrote: > There are about 2**(23*2) single precision floating division pairs because > only the mantissa was relevant (give or take a factor of two). Given that > the Pentium could natively do an FDIV in 39 cycles, that means that at 78 Mhz > (for ease of reference), you'd need 2**45/10**6 seconds, or about (2**20 ~ > 10**6) 32 million seconds ~ 1 year. Note that this is just the time for the > FDIVs, not the comparisons. > I would be interested in a testing strategy that would do an exhaustive > search on the double precision space. You mean OTHER than building 10,000 demo boards and running the tests in parallel? (Realize that they sold the pentium processors for at least twice what the demo boards would likely cost and the fact that the exhaustive test would mean nothing to the marketability of the processors actually running the test so they could be sold at full price.) 10,000 too many to justify getting the results in less than an hour? (Not surprising: It would take far longer than that to set up such a test.) Well, 300 gets the test done in about a day and is a lot easier to set up. If you're willing to wait a week for results, then about 50 will do the job. I would expect them to actually do 10-12 and get the results in about a month. After all, the testing process usually takes longer than a month to complete and involves building a number of those simple SBC's. -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` dewarr 1998-10-06 0:00 ` Ian St. John 1998-10-06 0:00 ` Fortran or Ada? Toon Moene @ 1998-10-06 0:00 ` James Giles 1998-10-06 0:00 ` Mark A Biggar 1998-10-07 0:00 ` dewarr 2 siblings, 2 replies; 83+ messages in thread From: James Giles @ 1998-10-06 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote in message <6vdfq4$p1$1@nnrp1.dejanews.com>... >In article <YGdS1.73461$hx3.8968466@HME2.newscontent-01.sprint.ca>, > "Ian St. John" <istjohn@sprint.ca> wrote: >> >> Testing by itself can never guarantee correct code. The testing is just to >> determine syntax errors, oversights, etc. > >That's a bit strong, there are definitely cases where testing can be >exhaustive, e.g. in checking out a sqrt routine for IEEE short form >arithmetic. Indeed it is almost practical to do exhaustive testing on >long format division (which would have saved Intel many millions of >dollars :-) There are 2^128 different possible divide operations (each operand having 2^64 different possible values) - and that's assuming that you don't have to test each pair of operands for each possible value of the exponent and sign (in which case there are nearly 2^160 different operand pairs - each operand having 2^80 different values). Now, assuming that a Pentium class machine can test 100 million operations per second (an overestimate to say the least), it would take over 10^30 seconds to test all 2^128 divides. This still assumes you have an independent source of the correct answer for each divide to test against! Running, say, 1000 machines in parallel, each testing different divides, would reduce the time needed to "just" 10^27 seconds. A year has on the order of 3*10^7 seconds. Now, there are other kinds of tests. A "correctness proof" is a test which does not work by actual execution of the code or hardware, but by logical examination of the components of them. This is still only a test, since the "proof" has the same complexity as the thing being tested - and the same likelyhood of error. However, to a certain extent, such errors are independent of the errors in the actual code or hardware (not always: especially in cases where the "proof" is generated with automated tools, an error in one can be completely transcribed into the other). This makes it a useful exercise, especially for mission-critical code or hardware. -- J. Giles ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` James Giles @ 1998-10-06 0:00 ` Mark A Biggar 1998-10-06 0:00 ` James Giles 1998-10-07 0:00 ` dewarr 1 sibling, 1 reply; 83+ messages in thread From: Mark A Biggar @ 1998-10-06 0:00 UTC (permalink / raw) James Giles wrote: > dewarr@my-dejanews.com wrote in message <6vdfq4$p1$1@nnrp1.dejanews.com>... > >In article <YGdS1.73461$hx3.8968466@HME2.newscontent-01.sprint.ca>, > > "Ian St. John" <istjohn@sprint.ca> wrote: > >> Testing by itself can never guarantee correct code. The testing is just to > >> determine syntax errors, oversights, etc. > >That's a bit strong, there are definitely cases where testing can be > >exhaustive, e.g. in checking out a sqrt routine for IEEE short form > >arithmetic. Indeed it is almost practical to do exhaustive testing on > >long format division (which would have saved Intel many millions of > >dollars :-) > There are 2^128 different possible divide operations (each operand > having 2^64 different possible values) - and that's assuming that you > don't have to test each pair of operands for each possible value of > the exponent and sign (in which case there are nearly 2^160 different > operand pairs - each operand having 2^80 different values). Now, > assuming that a Pentium class machine can test 100 million operations > per second (an overestimate to say the least), it would take over 10^30 > seconds to test all 2^128 divides. This still assumes you have an > independent source of the correct answer for each divide to test > against! Running, say, 1000 machines in parallel, each testing different > divides, would reduce the time needed to "just" 10^27 seconds. A > year has on the order of 3*10^7 seconds. You don't actuall actually have to test all 2^128 cases to be "exhaustive". First off you can factor the handling of exponents from that of mantissa's. In addition, the pentium algorithm is a base 4 division method, it works two bits at a time and uses some ROM table look-ups for partial results. The errors were in those tables, not the algorithm. A set of test cases that ran through all possible exponents combinations, and a sufficient set of mantissa's such that every table entry was use at least once would have found the pentium bug. Someone later said that such a test set could have been run in less than 10 minutes. -- Mark Biggar mark.a.biggar@lmco.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` Mark A Biggar @ 1998-10-06 0:00 ` James Giles 1998-10-07 0:00 ` dewarr 0 siblings, 1 reply; 83+ messages in thread From: James Giles @ 1998-10-06 0:00 UTC (permalink / raw) Mark A Biggar wrote in message <361A98CB.444AD094@lmco.com>... >James Giles wrote:>> There are 2^128 different possible divide operations (each operand >> having 2^64 different possible values) - and that's assuming that you >> don't have to test each pair of operands for each possible value of >> the exponent and sign (in which case there are nearly 2^160 different >> operand pairs - each operand having 2^80 different values). Now, >> assuming that a Pentium class machine can test 100 million operations >> per second (an overestimate to say the least), it would take over 10^30 >> seconds to test all 2^128 divides. This still assumes you have an >> independent source of the correct answer for each divide to test >> against! Running, say, 1000 machines in parallel, each testing different >> divides, would reduce the time needed to "just" 10^27 seconds. A >> year has on the order of 3*10^7 seconds. > >You don't actuall actually have to test all 2^128 cases to be "exhaustive". >First off you can factor the handling of exponents from that of mantissa's. Yes, I assumed that (as I explicitly pointed out). If you couldn't separate the significands from the exponent parts the number would be 2^158 cases (minus a few - since there are NAN's that needn't be tested). If, further, you couldn't separate out the sign bit, you'd have 2^160 cases. Remember, the Intel chip uses extended-double internally - each operand is 80-bits wide. >In addition, the pentium algorithm is a base 4 division method, it works >two bits at a time and uses some ROM table look-ups for partial results. >The errors were in those tables, not the algorithm. A set of test cases that >ran through all possible exponents combinations, and a sufficient set >of mantissa's such that every table entry was use at least once would have >found the pentium bug. Someone later said that such a test set could >have been run in less than 10 minutes. Yes, it's always possible, *after* you've found the bug, to think of a test which would have detected it in short order. I was addressing the claim that a genuinely exhaustive test was possible. It clearly wasn't. -- J. Giles ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` James Giles @ 1998-10-07 0:00 ` dewarr 0 siblings, 0 replies; 83+ messages in thread From: dewarr @ 1998-10-07 0:00 UTC (permalink / raw) In article <6veadj$rqj@bgtnsc02.worldnet.att.net>, "James Giles" <jamesgiles@worldnet.att.net> wrote: > > Mark A Biggar wrote in message <361A98CB.444AD094@lmco.com>... > >James Giles wrote:>> There are 2^128 different possible divide operations (each operand > >> having 2^64 different possible values) - and that's assuming that you > >> don't have to test each pair of operands for each possible value of > >> the exponent and sign (in which case there are nearly 2^160 different > >> operand pairs - each operand having 2^80 different values). Now, > >> assuming that a Pentium class machine can test 100 million operations > >> per second (an overestimate to say the least), it would take over 10^30 > >> seconds to test all 2^128 divides. This still assumes you have an > >> independent source of the correct answer for each divide to test > >> against! Running, say, 1000 machines in parallel, each testing different > >> divides, would reduce the time needed to "just" 10^27 seconds. A > >> year has on the order of 3*10^7 seconds. > > > >You don't actuall actually have to test all 2^128 cases to be "exhaustive". > >First off you can factor the handling of exponents from that of mantissa's. > > Yes, I assumed that (as I explicitly pointed out). If you couldn't separate > the significands from the exponent parts the number would be 2^158 cases > (minus a few - since there are NAN's that needn't be tested). If, further, > you couldn't separate out the sign bit, you'd have 2^160 cases. Remember, > the Intel chip uses extended-double internally - each operand is 80-bits > wide. > > >In addition, the pentium algorithm is a base 4 division method, it works > >two bits at a time and uses some ROM table look-ups for partial results. > >The errors were in those tables, not the algorithm. A set of test cases that > >ran through all possible exponents combinations, and a sufficient set > >of mantissa's such that every table entry was use at least once would have > >found the pentium bug. Someone later said that such a test set could > >have been run in less than 10 minutes. > > Yes, it's always possible, *after* you've found the bug, to think of a test > which would have detected it in short order. I was addressing the claim that > a genuinely exhaustive test was possible. It clearly wasn't. Reread my original post, no one ever claimed that a genuinely exhaustive test was possible in this case. I said it was "almost possible", by which I meant precisely that the critical component, namely the table lookup part of the algorithm, could indeed have been tested exhuastively, and should have been, no hindsight required! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` James Giles 1998-10-06 0:00 ` Mark A Biggar @ 1998-10-07 0:00 ` dewarr 1 sibling, 0 replies; 83+ messages in thread From: dewarr @ 1998-10-07 0:00 UTC (permalink / raw) In article <6vdnqe$3nu@bgtnsc02.worldnet.att.net>, "James Giles" <jamesgiles@worldnet.att.net> wrote: > > dewarr@my-dejanews.com wrote in message <6vdfq4$p1$1@nnrp1.dejanews.com>... > >In article <YGdS1.73461$hx3.8968466@HME2.newscontent-01.sprint.ca>, > > "Ian St. John" <istjohn@sprint.ca> wrote: > >> > >> Testing by itself can never guarantee correct code. The testing is just to > >> determine syntax errors, oversights, etc. > > > >That's a bit strong, there are definitely cases where testing can be > >exhaustive, e.g. in checking out a sqrt routine for IEEE short form > >arithmetic. Indeed it is almost practical to do exhaustive testing on > >long format division (which would have saved Intel many millions of > >dollars :-) > > There are 2^128 different possible divide operations (each operand > having 2^64 different possible values) - and that's assuming that you > don't have to test each pair of operands for each possible value of > the exponent and sign (in which case there are nearly 2^160 different > operand pairs - each operand having 2^80 different values). Now, > assuming that a Pentium class machine can test 100 million operations > per second (an overestimate to say the least), it would take over 10^30 > seconds to test all 2^128 divides. This still assumes you have an > independent source of the correct answer for each divide to test > against! Running, say, 1000 machines in parallel, each testing different > divides, would reduce the time needed to "just" 10^27 seconds. A > year has on the order of 3*10^7 seconds. > > Now, there are other kinds of tests. A "correctness proof" is a test > which does not work by actual execution of the code or hardware, > but by logical examination of the components of them. This is still > only a test, since the "proof" has the same complexity as the thing > being tested - and the same likelyhood of error. However, to a > certain extent, such errors are independent of the errors in the actual > code or hardware (not always: especially in cases where the "proof" > is generated with automated tools, an error in one can be completely > transcribed into the other). This makes it a useful exercise, especially > for mission-critical code or hardware. > > -- > J. Giles Note that I said "almost" in my post (having given an example for which exhaustive testing most certainly is possible). The point in the divide case is that, given a knowledge of the underlying algorithm and table look up approach, it is not necessary to test all bit combinations to get at least full path coverage of the underlying algorithm. This is not exhaustive testing, but in this case, it is something close, hence my almost. And please note I am not saying that path testing in general is the same as exhaustive testing, just that it is close *in this specific hardware case* -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-05 0:00 ` Ian St. John 1998-10-05 0:00 ` dewarr @ 1998-10-05 0:00 ` Richard D Riehle 1998-10-05 0:00 ` dewarr 1998-10-06 0:00 ` Michel OLAGNON 2 siblings, 1 reply; 83+ messages in thread From: Richard D Riehle @ 1998-10-05 0:00 UTC (permalink / raw) In article <3618dc33.0@news.passport.ca>, "Ian St. John" <istjohn@high-sense.com> wrote: >The software was *correct* for the mission it was designed for ( Arianne >4 ). You cannot expect software re-use without evaluation of the >interface/inputs. Software reuse, particularly application-specific software reuse, is full of risks. It is much like giving a pill prescribed by a physician for one person to some other person whose body chemistry is intolerant of that same medication. The pill may be benign for one set of circumstances and deadly for another. When a physician is guilty of an error in phamacological "reuse" we call it malpractice. Arianne V was a clear case of software malpractice. The engineers used an otherwise benign software module for a system that was intolerant of it. The doctor is required to ask, "Are you allergic to any medications?" No one seems to have asked an analogous question when designing Arianne V. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-05 0:00 ` Richard D Riehle @ 1998-10-05 0:00 ` dewarr 0 siblings, 0 replies; 83+ messages in thread From: dewarr @ 1998-10-05 0:00 UTC (permalink / raw) In article <6vavn6$gra@sjx-ixn4.ix.netcom.com>, Richard D Riehle <laoxhai@ix.netcom.com> wrote: > In article <3618dc33.0@news.passport.ca>, > "Ian St. John" <istjohn@high-sense.com> wrote: > > >The software was *correct* for the mission it was designed for ( Arianne > >4 ). You cannot expect software re-use without evaluation of the > >interface/inputs. > > Software reuse, particularly application-specific software reuse, is full of > risks. It is much like giving a pill prescribed by a physician for one > person to some other person whose body chemistry is intolerant of that same > medication. The pill may be benign for one set of circumstances and deadly > for another. > > When a physician is guilty of an error in phamacological "reuse" we call > it malpractice. Arianne V was a clear case of software malpractice. The > engineers used an otherwise benign software module for a system that was > intolerant of it. The doctor is required to ask, "Are you allergic to > any medications?" No one seems to have asked an analogous question when > designing Arianne V. Actually I don't think that's the right analogy, the reuse here was more like a doctor looking at a patient and saying: "well this guy looks like Mr. Smith in room 4, so give him the same medicine" :-) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-05 0:00 ` Ian St. John 1998-10-05 0:00 ` dewarr 1998-10-05 0:00 ` Richard D Riehle @ 1998-10-06 0:00 ` Michel OLAGNON 1998-10-07 0:00 ` Ian St. John 2 siblings, 1 reply; 83+ messages in thread From: Michel OLAGNON @ 1998-10-06 0:00 UTC (permalink / raw) In article <3618dc33.0@news.passport.ca>, "Ian St. John" <istjohn@high-sense.com> writes: > >Michel OLAGNON wrote in message <6v9s4t$egn$1@ys.ifremer.fr>... >>In article <3617AA49.340A5899@icon.fi>, Niklas Holsti <nholsti@icon.fi> >writes: ><snip> >>> >>At the time of writing the software, it might not have been wrong. >>But later on, the launch procedure was changed for Ariane 4, and >>the computation no longer needed. IMHO, not removing unnecessary >>computations that may have side effects IS a "software error". >> >>The designers failed, IMHO, to note that even if hardware might >>be more likely to be wrong than software at time T0, over the whole >>expected service life of the system, it was software that had the highest >>probability to end up wrong. >> > > >IMHO, well tested software doesn't fail. But, IMHO, such well tested software doesn't exist. > Hardware does. At least, in the >sense of random errors. Software can have systematic errors, or design >limitations. Random errors and unexpected data indicate hardware problems. > >The problem in the Ariane 5 case, were that there was no proper review of >whether the software testing was *valid* for Ariane 5. The point, IMHO, is that the software was *useless* for Ariane 5, recognized so by the reviewers, and yet kept because of ``commonality reasons'', which, IMHO again, is a polite way to say ``lack of thought''. Although I could not make it out again clearly from the report, I remember that the launch procedure was changed at some time for Ariane 4, and that the software was also *useless* for it, but was kept for a similar reason: If it ain't broken, why change it ? > This was a >*management* issue, not a technology issue. If the Ariane 4 had reported >such values ( causing overflow ) it *would* have been a hardware error. This is pure speculation. It might have been a software error or a hardware error, no one can tell. But even if it had been a hardware error, my experience is that it would be very likely to have happenned *after* T-5 seconds rather than before (hardware errors happen with vibrations, heat, ...), i.e. at a time when the computations were no longer needed, that is, IMHO, when the software error of making useless computations had already happenned. > This >was taken into the design, and is correct as such. > >The software was *correct* for the mission it was designed for ( Arianne >4 ). You cannot expect software re-use without evaluation of the >interface/inputs. > >Nor can you design software with the viewpoint that it *might* be used in >the first warp drive spaceship. KISS, and stick to reality. > > Michel -- | Michel OLAGNON email : Michel.Olagnon@ifremer.fr| | IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer| | Centre de Brest - B.P. 70 phone : +33-2-9822 4144| | F-29280 PLOUZANE - FRANCE fax : +33-2-9822 4650| | http://www.ifremer.fr/ditigo/molagnon/molagnon.html | ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` Michel OLAGNON @ 1998-10-07 0:00 ` Ian St. John 0 siblings, 0 replies; 83+ messages in thread From: Ian St. John @ 1998-10-07 0:00 UTC (permalink / raw) Michel OLAGNON wrote in message <6vcj6f$ak7$1@ys.ifremer.fr>... >>> >>>The designers failed, IMHO, to note that even if hardware might >>>be more likely to be wrong than software at time T0, over the whole >>>expected service life of the system, it was software that had the highest >>>probability to end up wrong. >>> >> >> >>IMHO, well tested software doesn't fail. > >But, IMHO, such well tested software doesn't exist. By that light, 'well tested hardware' doesn't either. Maybe you aren't paying enough attention to paying for good software engineers. You seem rather 'biased'. Modern systems require attention to both hardware and software engineering. Each piece of hardware has the potential for 'infant mortality', or tolerance sloppiness. This is exacerbated in complex systems by the reliablity factor being the resulting combination of many individual MTBF values. On the other hand, software, in a system that has not changed, gains reliability over time, as bugs are shaken out. This is 'well tested' software. *Planning* for errors should assume hardware problems in general, for this reason. However, for good software engineering practice, generating software for a different system requires all software to go back to the 'untested' level for re-evaluation. The software for Arianne 5 was 'untested'. > >The point, IMHO, is that the software was *useless* for Ariane 5, recognized >so by the reviewers, and yet kept because of ``commonality reasons'', which, >IMHO again, is a polite way to say ``lack of thought''. Although I could not >make it out again clearly from the report, I remember that the launch >procedure was changed at some time for Ariane 4, and that the software >was also *useless* for it, but was kept for a similar reason: If it >ain't broken, why change it ? Actually, it would think it is just a 'cover' for the 'software re-use' theory. Like CASE tools, and dozens of others schemes before it, the point is to allow for quick software development with no intelligent thought. Like putting a Delta III upper stage on a Saturn 1B stage, with a couple of SRB's on the side. After all, each component is 'well tested'. Right? I would diffidently point out the mass of scrap metal over there as a good reason to change it. You are correct in that a change in the systems *has* to be cause for re-evaluation of the software. But you are wrong in ascribing this to 'poorly tested software'. It would be like crying because the F15 flight simulator software doesn't work very well running your car. I would no more expect Arianne 4 software to be 'well tested' in an Arianne 5, than in a Saturn V, or even in a modified Arianne 4. Any more than I would expect a hardware engineer to increase tankage size by ten percent without evaluating the effect on stuctural integrity, resizing of the engines, fuel flow limits, etc. >This is pure speculation. It might have been a software error or a hardware >error, no one can tell. There are few software errors that can put the wrong data into a variable. They generally end up being weeded out in early testing because they tend to be 'catastrophic failures'. I call this a hardware error, because as I understand it, the sensor/converter on the Arianne 4 could not generate a valid value large enough to overflow the variable, in it's flight regime. Arianne 5, OTOH, was guaranteed to do so. Hardware failure *are* more likely under heat and stress. And, it was a gamble to leave the software running, rather than have it disabled after launch. A valid decision, for the most part. Running the same software with Arianne 5 and no re-evaluation was just plain stupid. There is little defence against real idiocy. > But even if it had been a hardware error, my experience >is that it would be very likely to have happenned *after* T-5 seconds rather >than before (hardware errors happen with vibrations, heat, ...), i.e. at a >time when the computations were no longer needed, that is, IMHO, when the >software error of making useless computations had already happenned. I will give you this. The software was not needed once liftoff had been achieved. It was retained because it was felt that it could do no harm, and it would be cheaper to leave it in, and running. This was bad software engineering. Primarily driven by costs, so it was a judgement call. Point is, it was a good call for Arianne 4. Maybe that wreckage will make the bean counters rethink their priorities. They violated my rule. Never cut corners on the prototype. Once you have all of the factors in a working system, then you can start reducing costs, with good data on *what* you can trim. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-28 0:00 ` jbs 1998-09-29 0:00 ` William B. Clodius @ 1998-09-29 0:00 ` Dean F. Sutherland 1998-09-29 0:00 ` Dean F. Sutherland ` (4 subsequent siblings) 6 siblings, 0 replies; 83+ messages in thread From: Dean F. Sutherland @ 1998-09-29 0:00 UTC (permalink / raw) To: jbs jbs@yktvmv.watson.ibm.com wrote: > <snip snip snip> > > 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 Wrong on both counts. For number one, check out http://www.adahome.com/Ammo/Stories/Tartan-Realtime.html This (admittedly old) writeup describes compiled Ada beating both custom hand-written assembly and also C. In my time at Tartan I saw a number of commercial customers (no Gov't mandate!) switch to Tartan Ada for the C3x/C4x DSPs because we were able to produce substantially faster code than TI's C compiler. Speaking as a compiler optimizer writer, Ada's semantics give much more scope for optimization than C (or C++) -- without requiring the level of hairy pointer aliasing analysis that C/C++ compilers must perform to get good results. Ada may be "notoriously inefficient," but there is ABSOLUTELY NOTHING inherent in the language that makes it so. There certainly have been, and will continue to be, Ada compilers with quite impressive and state-of-the-art optimization. Those compilers produce code that is most assuredly competitive with any other language. That "notoriously inefficient" impression is just plain dead wrong. For #2: There's pragma suppress -- thoroughly standard (just look in the reference manual: section 11.5). There are compile time switches. Perhaps it would be wise to consider a more careful fact-check before posting on this subject again. Sincerely, Dean F. Sutherland dsutherland@acm.org dfsuther@cs.cmu.edu ex-Tartan/TI optimization and code generation ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-28 0:00 ` jbs 1998-09-29 0:00 ` William B. Clodius 1998-09-29 0:00 ` Dean F. Sutherland @ 1998-09-29 0:00 ` Dean F. Sutherland 1998-09-29 0:00 ` Gautier.DeMontmollin ` (3 subsequent siblings) 6 siblings, 0 replies; 83+ messages in thread From: Dean F. Sutherland @ 1998-09-29 0:00 UTC (permalink / raw) To: jbs@ jbs@yktvmv.watson.ibm.com wrote: > <snip snip snip> > > 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 Wrong on both counts. For number one, check out http://www.adahome.com/Ammo/Stories/Tartan-Realtime.html This (admittedly old) writeup describes compiled Ada beating both custom hand-written assembly and also C. In my time at Tartan I saw a number of commercial customers (no Gov't mandate!) switch to Tartan Ada for the C3x/C4x DSPs because we were able to produce substantially faster code than TI's C compiler. Speaking as a compiler optimizer writer, Ada's semantics give much more scope for optimization than C (or C++) -- without requiring the level of hairy pointer aliasing analysis that C/C++ compilers must perform to get good results. Ada may be "notoriously inefficient," but there is ABSOLUTELY NOTHING inherent in the language that makes it so. There certainly have been, and will continue to be, Ada compilers with quite impressive and state-of-the-art optimization. Those compilers produce code that is most assuredly competitive with any other language. That "notoriously inefficient" impression is just plain dead wrong. For #2: There's pragma suppress -- thoroughly standard (just look in the reference manual: section 11.5). There are compile time switches. Perhaps it would be wise to consider a more careful fact-check before posting on this subject again. Sincerely, Dean F. Sutherland dsutherland@acm.org dfsuther@cs.cmu.edu ex-Tartan/TI optimization and code generation ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-28 0:00 ` jbs ` (2 preceding siblings ...) 1998-09-29 0:00 ` Dean F. Sutherland @ 1998-09-29 0:00 ` Gautier.DeMontmollin 1998-09-29 0:00 ` Dean F. Sutherland ` (2 subsequent siblings) 6 siblings, 0 replies; 83+ messages in thread From: Gautier.DeMontmollin @ 1998-09-29 0:00 UTC (permalink / raw) > 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. Some Ada compilers may be inefficient; there is at least one which is very efficient: GNAT. Among advanced optimisations, it includes cross-package inlining, which is just impossible with non modular languages like F77 or C++... > 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. "gnatmake -gnatp xyz" compiles the whole xyz program (with depending packages) without any check (like pragma supress_all). Try to find simpler or cheaper... -- Gautier -------- Homepage: http://www.unine.ch/math/Personnel/Assistants/Gautier/Montmollin.html Software: http://www.unine.ch/math/Personnel/Assistants/Gautier/Gaut_FTP.htm ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-28 0:00 ` jbs ` (3 preceding siblings ...) 1998-09-29 0:00 ` Gautier.DeMontmollin @ 1998-09-29 0:00 ` Dean F. Sutherland 1998-10-02 0:00 ` Geoff Bull 1998-10-02 0:00 ` Robert I. Eachus 6 siblings, 0 replies; 83+ messages in thread From: Dean F. Sutherland @ 1998-09-29 0:00 UTC (permalink / raw) To: jbs jbs@yktvmv.watson.ibm.com wrote: > <snip snip snip> > > 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 Wrong on both counts. For number one, check out http://www.adahome.com/Ammo/Stories/Tartan-Realtime.html This (admittedly old) writeup describes compiled Ada beating both custom hand-written assembly and also C. In my time at Tartan I saw a number of commercial customers (no Gov't mandate!) switch to Tartan Ada for the C3x/C4x DSPs because we were able to produce substantially faster code than TI's C compiler. Speaking as a compiler optimizer writer, Ada's semantics give much more scope for optimization than C (or C++) -- without requiring the level of hairy pointer aliasing analysis that C/C++ compilers must perform to get good results. Ada may be "notoriously inefficient," but there is ABSOLUTELY NOTHING inherent in the language that makes it so. There certainly have been, and will continue to be, Ada compilers with quite impressive and state-of-the-art optimization. Those compilers produce code that is most assuredly competitive with any other language. That "notoriously inefficient" impression is just plain dead wrong. For #2: There's pragma suppress -- thoroughly standard (just look in the reference manual: section 11.5). There are compile time switches. Perhaps it would be wise to consider a more careful fact-check before posting on this subject again. Sincerely, Dean F. Sutherland dsutherland@acm.org dfsuther@cs.cmu.edu ex-Tartan/TI optimization and code generation ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-28 0:00 ` jbs ` (4 preceding siblings ...) 1998-09-29 0:00 ` Dean F. Sutherland @ 1998-10-02 0:00 ` Geoff Bull 1998-10-02 0:00 ` Robert I. Eachus 6 siblings, 0 replies; 83+ messages in thread From: Geoff Bull @ 1998-10-02 0:00 UTC (permalink / raw) jbs@yktvmv.watson.ibm.com wrote: > Ada is of course > notoriously inefficient. I was recently subject to a claim that Java optimistation was so good, it was now half as fast as Fortran at numerics, and many times faster than C, C++. I was provoked when I heard a number of people discussing how great it was that "Java's performance problem has now been solved" Unfortunately I didn't have access to a Fortran compiler, but decided to test this claim against Ada & C (using gnat3.10p with gcc2.7.2) on matrix multiplication. For equivalent C and Ada, I found NO difference in performance, (with Ada constraint checking ON) and looking at the generated code it was difficult to understand how Fortran could be faster. For real arithmetic, Java achieved half the speed of C / Ada (which is pretty good, really). With the complex arithmetic the sory was different: Ada was same speed as C if written the same way (and presumably I could have written Java that was half as fast). but if complex types from the Ada library were used, 30% performance hit occured due to creation of intermediate objects Java execution time was an order of magnitude slower due to it use of the heap for Complex objects. I am willing to believe Fortran would have been faster than Ada (when using abstractio) for complex arithmetic because of the compiler's in built support for that type. However I still don't see why it would have been faster than the C, or the C-style Ada. I didn't test Fortran - so what is my point? Comments like the above, while probably intended to inflame the likes of me, are often just accepted without question. Everybody seems to just accept Fortran is such a fantastic numerics language , especially when it comes to performance. Is it really? ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-28 0:00 ` jbs ` (5 preceding siblings ...) 1998-10-02 0:00 ` Geoff Bull @ 1998-10-02 0:00 ` Robert I. Eachus 1998-10-02 0:00 ` jbs 6 siblings, 1 reply; 83+ messages in thread From: Robert I. Eachus @ 1998-10-02 0:00 UTC (permalink / raw) In article <19980928.184428.604@yktvmv.watson.ibm.com> jbs@yktvmv.watson.ibm.com writes: > It appears to me that this implicates Ada in at least two respects... If you read a little more, you will find that it doesn't implicate Ada or any other programming language. They followed this particular fault tree all the way down because it occurred, not because the rocket would have survived if it hadn't. Note later in the report where it says that the stack was destroyed when the engine deflection exceeded the physical stress limits of the stack (booster and payload). Because the software was used WITHOUT CHANGE from the Arianne 4, it contained the wrong physical parameters for the dynamic deflection limits. This launch was a disaster waiting to happen, and no programming language is going to save you from putting in the wrong numbers. The particular error that occurred was just the first case where differences between the Arianne 4 and Arianne 5 became significant. One last note which bears repeating. There were no programmers or other non-management personnel at fault, because management ELIMINATED all such positions. The inertial management unit was being reused without change on the Arianne 5, so no developers were ever hired. Given a choice of test methods, they chose to demonstrate that the IMU worked. But the "full-up" simulation testing was cancelled--as a cost saving--before the development work on the non-flight parts was complete. No non-manager ever had both the Ariane 5 technical specs and the flight guidance software in hand, with or without authority to evaluate or test one against the other. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-02 0:00 ` Robert I. Eachus @ 1998-10-02 0:00 ` jbs 1998-10-02 0:00 ` William Clodius 0 siblings, 1 reply; 83+ messages in thread From: jbs @ 1998-10-02 0:00 UTC (permalink / raw) In article <EACHUS.98Oct2160023@spectre.mitre.org>, on 02 Oct 1998 20:00:23 GMT, eachus@spectre.mitre.org (Robert I. Eachus) writes: >In article <19980928.184428.604@yktvmv.watson.ibm.com> jbs@yktvmv.watson.ibm.com writes: > > > It appears to me that this implicates Ada in at least two respects... > > If you read a little more, you will find that it doesn't implicate >Ada or any other programming language. They followed this particular >fault tree all the way down because it occurred, not because the >rocket would have survived if it hadn't. Note later in the report >where it says that the stack was destroyed when the engine deflection >exceeded the physical stress limits of the stack (booster and >payload). Because the software was used WITHOUT CHANGE from the >Arianne 4, it contained the wrong physical parameters for the dynamic >deflection limits. This launch was a disaster waiting to happen, and >no programming language is going to save you from putting in the wrong >numbers. The particular error that occurred was just the first case >where differences between the Arianne 4 and Arianne 5 became >significant. The report I have says nothing like this. What report are you referring to? James B. Shearer ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-02 0:00 ` jbs @ 1998-10-02 0:00 ` William Clodius 1998-10-03 0:00 ` jbs 0 siblings, 1 reply; 83+ messages in thread From: William Clodius @ 1998-10-02 0:00 UTC (permalink / raw) jbs@yktvmv.watson.ibm.com wrote: > <snip> > The report I have says nothing like this. What report are > you referring to? > James B. Shearer Robert Eachus's comments are "mostly" inferable from the report. He is correct that the report says (in equivalent words) that "the stack was destroyed when the engine deflection exceeded the physical stress limits of the stack (booster and payload)." He is also correct that this implies that the software did not properly check that such an engine deflection was safe at that thrust. I suspect that he infers from presummed best practices that the software would make such a check, and that it failed because the physical parameters were wrong, and that the most likely reason that they were wrong was because the Ariane 4 parameters were used. However, the number of steps used in that inference are long and while the individual steps are plausible collectively they are less plausible. Further, whether any other system malfunction could have caused the software to command that that deflection is unknown. But he is correct that reusing software, without examining the differences in the systems where the software is reused, and how those differences might change the software's requirements, is a recipe for disaster in any language. -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-02 0:00 ` William Clodius @ 1998-10-03 0:00 ` jbs 1998-10-03 0:00 ` Larry Elmore 1998-10-06 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 83+ messages in thread From: jbs @ 1998-10-03 0:00 UTC (permalink / raw) In article <36156677.7566@lanl.gov>, on Fri, 02 Oct 1998 17:49:11 -0600, William Clodius <wclodius@lanl.gov> writes: >jbs@yktvmv.watson.ibm.com wrote: >> <snip> >> The report I have says nothing like this. What report are >> you referring to? >> James B. Shearer > >Robert Eachus's comments are "mostly" inferable from the report. He is >correct that the report says (in equivalent words) that "the stack was >destroyed when the engine deflection exceeded the physical stress limits >of the stack (booster and payload)." He is also correct that this >implies that the software did not properly check that such an engine >deflection was safe at that thrust. I suspect that he infers from >presummed best practices that the software would make such a check, and >that it failed because the physical parameters were wrong, and that the >most likely reason that they were wrong was because the Ariane 4 >parameters were used. However, the number of steps used in that >inference are long and while the individual steps are plausible >collectively they are less plausible. Further, whether any other system >malfunction could have caused the software to command that that >deflection is unknown. Actually what the report says is: ! f) Approx. 0.05 seconds later the active inertial reference system, ! identical to the back-up system in hardware and software, failed for the ! same reason. Since the back-up inertial system was already inoperative, ! correct guidance and attitude information could no longer be obtained and ! loss of the mission was inevitable. ! ! g) As a result of its failure, the active inertial reference system ! transmitted essentially diagnostic information to the launcher's main ! computer, where it was interpreted as flight data and used for flight ! control calculations. ! ! h) On the basis of those calculations the main computer commanded the ! booster nozzles, and somewhat later the main engine nozzle also, to make a ! large correction for an attitude deviation that had not occurred. ! ! i) A rapid change of attitude occurred which caused the launcher to ! disintegrate at 39 seconds after H0 due to aerodynamic forces. ! ! j) Destruction was automatically initiated upon disintegration, as ! designed, at an altitude of 4 km and a distance of 1 km from the launch ! pad. I don't see anything in there about the engine deflection being unsafe in itself, it just pointed the rocket in the wrong direction. Presumedly a less extreme deflection (error) would just have delayed the accident a few seconds. James B. Shearer ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-03 0:00 ` jbs @ 1998-10-03 0:00 ` Larry Elmore 1998-10-06 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 83+ messages in thread From: Larry Elmore @ 1998-10-03 0:00 UTC (permalink / raw) jbs@yktvmv.watson.ibm.com wrote in message <19981002.222045.439@yktvmv.watson.ibm.com>... >In article <36156677.7566@lanl.gov>, > on Fri, 02 Oct 1998 17:49:11 -0600, > William Clodius <wclodius@lanl.gov> writes: >>jbs@yktvmv.watson.ibm.com wrote: >>> <snip> >>> The report I have says nothing like this. What report are >>> you referring to? >>> James B. Shearer >> >>Robert Eachus's comments are "mostly" inferable from the report. He is >>correct that the report says (in equivalent words) that "the stack was >>destroyed when the engine deflection exceeded the physical stress limits >>of the stack (booster and payload)." He is also correct that this >>implies that the software did not properly check that such an engine >>deflection was safe at that thrust. I suspect that he infers from >>presummed best practices that the software would make such a check, and >>that it failed because the physical parameters were wrong, and that the >>most likely reason that they were wrong was because the Ariane 4 >>parameters were used. However, the number of steps used in that >>inference are long and while the individual steps are plausible >>collectively they are less plausible. Further, whether any other system >>malfunction could have caused the software to command that that >>deflection is unknown. > > Actually what the report says is: > >! f) Approx. 0.05 seconds later the active inertial reference system, >! identical to the back-up system in hardware and software, failed for the >! same reason. Since the back-up inertial system was already inoperative, >! correct guidance and attitude information could no longer be obtained and >! loss of the mission was inevitable. >! >! g) As a result of its failure, the active inertial reference system >! transmitted essentially diagnostic information to the launcher's main >! computer, where it was interpreted as flight data and used for flight >! control calculations. >! >! h) On the basis of those calculations the main computer commanded the >! booster nozzles, and somewhat later the main engine nozzle also, to make a >! large correction for an attitude deviation that had not occurred. >! >! i) A rapid change of attitude occurred which caused the launcher to >! disintegrate at 39 seconds after H0 due to aerodynamic forces. >! >! j) Destruction was automatically initiated upon disintegration, as >! designed, at an altitude of 4 km and a distance of 1 km from the launch >! pad. > > I don't see anything in there about the engine deflection >being unsafe in itself, it just pointed the rocket in the wrong >direction. Presumedly a less extreme deflection (error) would just >have delayed the accident a few seconds. Well, _of course_ you didn't see anything in there about the engine deflection being unsafe in itself! That's because no one has suggested anything so foolish. Mr. Eachus wrote: "Note later in the report where it says that the stack was destroyed when the engine deflection exceeded the physical stress limits of the stack (booster and payload). " The failure was due to a management decision to use unchanged the Ariane 4 sub-system without any testing, or even adequate review. LArry ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-03 0:00 ` jbs 1998-10-03 0:00 ` Larry Elmore @ 1998-10-06 0:00 ` Robert I. Eachus 1998-10-06 0:00 ` Pat Rogers 1 sibling, 1 reply; 83+ messages in thread From: Robert I. Eachus @ 1998-10-06 0:00 UTC (permalink / raw) In article <19981002.222045.439@yktvmv.watson.ibm.com> jbs@yktvmv.watson.ibm.com writes: ! h) On the basis of those calculations the main computer commanded the ! booster nozzles, and somewhat later the main engine nozzle also, to make a ! large correction for an attitude deviation that had not occurred. ! i) A rapid change of attitude occurred which caused the launcher to ! disintegrate at 39 seconds after H0 due to aerodynamic forces. ... > I don't see anything in there about the engine deflection > being unsafe in itself, it just pointed the rocket in the wrong > direction. Presumedly a less extreme deflection (error) would just > have delayed the accident a few seconds. No a less extreme deflection would have resulted in the stack being off course, but still in one piece. If the course deviation had been real, due to say heavy wind shear, the stack could have later returned to a correct course. But once you go beyond the (hopefully known) stress limits, you don't have a launcher, you have a large number of parts in loose formation. Note that the main computer, not the inertial guidance system ordered the deflection, and my understanding is that it was using Arianne 4 deflection limits. (Arianne 4 had a lower thrust to weight ratio, and was not as tall.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-10-06 0:00 ` Robert I. Eachus @ 1998-10-06 0:00 ` Pat Rogers 0 siblings, 0 replies; 83+ messages in thread From: Pat Rogers @ 1998-10-06 0:00 UTC (permalink / raw) Robert I. Eachus wrote in message ... <snip> > But once you go beyond the (hopefully >known) stress limits, you don't have a launcher, you have a large >number of parts in loose formation. I believe that is what is called a "helicopter". :-) -- pat Patrick Rogers progers@acm.org http://www.neosoft.com/~progers ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` Marc A. Criley 1998-09-24 0:00 ` dewarr @ 1998-09-24 0:00 ` Jeff Templon 1998-09-25 0:00 ` Dale Stanbrough 1998-09-25 0:00 ` dewarr [not found] ` <6udre0$ha1$1@nnrp1.dejane <6utg60$h6l$1@nnrp1.dejanews.com> 2 siblings, 2 replies; 83+ messages in thread From: Jeff Templon @ 1998-09-24 0:00 UTC (permalink / raw) "Marc A. Criley" <marc.a.criley@lmco.com> writes: > Jeff Templon wrote: > > I would write some examples, but no time. Sorry. > [Robert Dewar mode on :-] > It is unreasonable to expect anyone to accept your highly-contested > assertions at face value, and cite "no time" as justification for > not providing examples for peer review in defense of your point. > [RD off] Since when did I say that I expected anyone to accept my assertions? ;-) And are they that highly contested? I only got three posts back telling me what an idiot I was. Look at poor DaveGemini. Now *that's* contested. Jeff ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` Jeff Templon @ 1998-09-25 0:00 ` Dale Stanbrough 1998-09-30 0:00 ` Daniel Barker 1998-09-25 0:00 ` dewarr 1 sibling, 1 reply; 83+ messages in thread From: Dale Stanbrough @ 1998-09-25 0:00 UTC (permalink / raw) Jeff Templon wrote: " I would write some examples, but no time. Sorry." " And are they that highly contested? I only got three posts back telling me what an idiot I was." Ok, you are an idiot :-) BTW i have conclusive proof that all of your examples are completely bogus, but i'm afraid i don't have time to post the reasons why. Needless to say, you can keep using Ada safe in the knowledge that there are no such problems*. Dale * Actually there are 2 such examples that i know of. They are... /=, = item : boolean := true; procedure a (item : boolean); a (item <= false); a (item => false); Anyone know of any others? ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-25 0:00 ` Dale Stanbrough @ 1998-09-30 0:00 ` Daniel Barker 1998-09-30 0:00 ` Lawrence Kirby ` (2 more replies) 0 siblings, 3 replies; 83+ messages in thread From: Daniel Barker @ 1998-09-30 0:00 UTC (permalink / raw) `In the language of everyday life it very often happens that the same word signifies in two different ways - and therefore belongs to two different symbols - or that two words, which signify in different ways, are apparently applied in the same way in the proposition. `Thus the word "is" appears as the copula, as the sign of equality, and as the expression of existence; "to exist" as an intransitive verb like "to go"; "identical" as an adjective; we speak of SOMETHING but also of the fact of SOMETHING happening. `(In the proposition "Green is green" - where the first word is a proper name and the last an adjective - these words have not merely different meanings but they are DIFFERENT SYMBOLS.) `Thus there easily arise the most fundamental confusions (of which the whole of philosophy is full). `In order to avoid these errors, we must employ a symbolism which excludes them, by not applying the same sign in different symbols and by not applying signs in the same way which signify in different ways. A symbolism, that is to say, which obeys the rules of LOGICAL grammar - of logical syntax. `(The logical symbolism of Frege and Russell is such a language, which, however, does still not exclude all errors.) `In order to recognize the symbol in the sign we must consider the significant use. `The sign determines a logical form only together with its logical syntactic application. `If a sign is NOT NECESSARY then it is meaningless. That is the meaning of Occam's razor.' - Wittgenstein, Tractatus Logico-Philosophicus, propositions 3.323-3.328. (Capitals used in place of italics. Translation is the original 1922 version, by Ogden, which had Wittgenstein's approval. Published in London & New York by by Routledge; reprinted 1996.) If I may veer into another language, C - and thus justify adding another news group to the `to' line - #include <stdio.h> main() { int a[100]; /* `a' means array */ printf("%p\n", a); /* `a' means pointer */ a = a + 1; /* ILLEGAL, since `a' means array again */ } `a' here means two different things: (1) an array of 100 normal-width integers; (2) a pointer to a normal-width integer (in fact, to the first integer in an array of 100 such). To say that, in the call to printf(), the first thing is implicitly converted to the second thing is to linguistically `work around' the basic problem, that `a' has two meanings. Meaning (2) can also be expressed as &a[0] So, the example reveals two faults in the C language. Namely, that `a', as a local variable in one function, can have two meanings; and also that one of these meanings is may be expressed by either of two symbols. This is a crying shame! Why does `a' have two meanings, when, given the possibility of `&a[0]', one would have sufficed without reducing the functionality of the language? The answer is historical, as revealed by an interesting paper, "The Development of the C Language" by Dennis Ritchie, available from Dennis Ritchie's home page, http://plan9.bell-labs.com/cm/cs/who/dmr/index.html. Daniel Barker, Institute of Cell and Molecular Biology, Swann Building, King's Buildings, Mayfield Road, Edinburgh EH9 3JR UK ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-30 0:00 ` Daniel Barker @ 1998-09-30 0:00 ` Lawrence Kirby 1998-10-01 0:00 ` Aaron Crane 1998-10-02 0:00 ` Fortran or Ada or gobbledygook? Wes Groleau 1998-10-05 0:00 ` Fortran or Ada? Terry Devine 2 siblings, 1 reply; 83+ messages in thread From: Lawrence Kirby @ 1998-09-30 0:00 UTC (permalink / raw) In article <Pine.GSO.3.95.980930004116.19512A-100000@holyrood.ed.ac.uk> sokal@holyrood.ed.ac.uk "Daniel Barker" writes: >`In the language of everyday life it very often happens that the same word >signifies in two different ways - and therefore belongs to two different >symbols - or that two words, which signify in different ways, are >apparently applied in the same way in the proposition. OK. ... >`If a sign is NOT NECESSARY then it is meaningless. That is the meaning of >Occam's razor.' ... >If I may veer into another language, C - and thus justify adding another >news group to the `to' line - > >#include <stdio.h> >main() >{ > int a[100]; /* `a' means array */ > printf("%p\n", a); /* `a' means pointer */ %p requires an argument of type void *. Make this printf("%p\n", (void *)a); > a = a + 1; /* ILLEGAL, since `a' means array again */ According to the wording of the standard the leftmost a here is converted to a pointer value that is the address of the first element of a. The reason this is an error is because this left hand operand is not a modifiable lvalue (in fact it isn't an lvalue at all, even though a initially is). >} > >`a' here means two different things: That is an unnecessarily complex interpretation (you mention Occam's razor above). In all cases here ``a'' refers to the array object defined at the top of the function. >(1) an array of 100 normal-width integers; >(2) a pointer to a normal-width integer (in fact, to the first integer in >an array of 100 such). Well, no. a always refers initially to the array. It is just that in some circumstances it is converted to a pointer to the first element of the array. The language works in a similar way in other circumstances e.g. short i=1, j = 2, k; k = i+j; In this case i and j are both converted to values of type int before the + operator is applied to theose values. However I hope you won't deny that i and j refer to variables of type short. >To say that, in the call to printf(), the first thing is implicitly >converted to the second thing is to linguistically `work around' the basic >problem, that `a' has two meanings. No, it how the standard describes the behaviour of the abstract machine that it defines. It is certainly possible to describe it in different terms with the same overall results but this is no more a `work around' than the alternatives. It is if anything the alternatives that are a workaround since they take a different approach to the actual definition. >Meaning (2) can also be expressed as &a[0] If you analyse this fully you get the following steps 1. a refers to the defined array object and is an lvalue 2. The expression causes this lvalue to be converted to a pointer to the first element of the array. 3. x[y] is equivalent to *(x + y) so a[0] is the same as *(a+0) which reduces to *a. Since this operand points to the first element of the array then the result of this is an lvalue which designates the first element of a. 4. Unary & takes the address of the object designated by its operand. Since the operand is the first element of the array the result is a pointer to the first element of the array. >So, the example reveals two faults in the C language. Namely, that `a', as >a local variable in one function, can have two meanings; No, a in main here always refers to the array object declared at the top of the function. It is an inherent property of C that context can cause the original value/lvalue to be converted to a value of a different type. This is best considered as a separate step. Not all contexts do this, The main ones that don't are &a and sizeof a. What this shows is that in different contexts different values can be derived from a. But that is true of any variable. The only difference here is that there is an implicit conversion from an array to a pointer which is more radical than most other implicit conversions. C supports another conversion which is IMO equally radical, if not more so: int *ptr = 0; converts the constant integral expression 0 to a null pointer of type int *. >and also that one >of these meanings is may be expressed by either of two symbols. This is a >crying shame! Why does `a' have two meanings, when, given the possibility >of `&a[0]', one would have sufficed without reducing the functionality of >the language? In many cases it is simpler and more natural to write a instead of &a[0], e.g. int *ptr; ptr = a; There is also ptr = a+1; where pointer arithmetic is performed on the pointer value derived from a. This sort of thing has been natural in C since the earliest days. If you say that it is the assignment or the addition operators that caused the conversion then you are back to a similar idea of context causing the conversion that the standard describes. >The answer is historical, as revealed by an interesting paper, "The >Development of the C Language" by Dennis Ritchie, available from Dennis >Ritchie's home page, http://plan9.bell-labs.com/cm/cs/who/dmr/index.html. Sure it does it because it allows you to express the construct more simply. One of C's defining features is pointer arithmetic (many other languages have pointers to allow linked datastructures and dynamic allocation but lack the ability to perform arithmetic directly on them). Pointer arithmetic is inherently performed over array objects so it is natural for C to have as simple a syntax as possible for converting from arrays to pointers. Consider puts("Hello, world"); In C string literals are arrays of char. If the language were changed as you suggest then this would have to be written as puts(&"Hello, world"[0]); (which incidentally is valid in C). Or how about char str[10]; strcpy(&str[0], &"A string"[0]); printf(&"The string is '%s'\n"[0], &str[0]); It would turn C into a much less readable language (even for people who thought it was unreadable to start with). -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-30 0:00 ` Lawrence Kirby @ 1998-10-01 0:00 ` Aaron Crane 0 siblings, 0 replies; 83+ messages in thread From: Aaron Crane @ 1998-10-01 0:00 UTC (permalink / raw) In article <907198459snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes: > strcpy(&str[0], &"A string"[0]); > printf(&"The string is '%s'\n"[0], &str[0]); > > It would turn C into a much less readable language (even for people who > thought it was unreadable to start with). Seconded whole-heartedly. I am in the unfortunate position of having some familiarity with a fifteen-year-old project- and platform-specific (but allegedly general-purpose) scripting language called Sop[1]. Sop's principal influence (and implementation language, unsurprisingly) is K&R C. Sop has precisely this misfeature that arrays do not decay into pointers; this in itself is enough to make the code eminently unreadable -- even ignoring the language's other infelicities. -- Aaron Crane <aaron.crane@pobox.com> <URL:http://pobox.com/~aaronc/> [1] Name changed to protect the guilty. I won't rant about Sop here, because AFAIK only about ten people worldwide have ever encountered it; suffice it to say that not only was it designed by someone with no understanding of language design, it wasn't actually designed as a whole in the first place. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada or gobbledygook? 1998-09-30 0:00 ` Daniel Barker 1998-09-30 0:00 ` Lawrence Kirby @ 1998-10-02 0:00 ` Wes Groleau 1998-10-05 0:00 ` Fortran or Ada? Terry Devine 2 siblings, 0 replies; 83+ messages in thread From: Wes Groleau @ 1998-10-02 0:00 UTC (permalink / raw) > `Thus the word "is" appears as the copula, as the sign of equality, and as > the expression of existence; "to exist" as an intransitive verb like "to > go"; "identical" as an adjective; we speak of SOMETHING but also of the > fact of SOMETHING happening. "That depends on what the meaning of 'is' is." -- William Jefferson Clinton -- ------------------------------------------------------------------- Wes Groleau, Raytheon Systems Company, Fort Wayne, IN USA Member of Technical Staff - AFATDS Toolsmith wwgrol - pseserv3 . fw . hac . com Don't send advertisements to this domain ! All disk space on fw.hac.com hosts belongs to either Raytheon Systems Company or the United States Government. Using email to store YOUR advertising on them is trespassing! ------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-30 0:00 ` Daniel Barker 1998-09-30 0:00 ` Lawrence Kirby 1998-10-02 0:00 ` Fortran or Ada or gobbledygook? Wes Groleau @ 1998-10-05 0:00 ` Terry Devine 2 siblings, 0 replies; 83+ messages in thread From: Terry Devine @ 1998-10-05 0:00 UTC (permalink / raw) Daniel Barker wrote: > > `In the language of everyday life it very often happens that the same word > signifies in two different ways - and therefore belongs to two different > symbols - or that two words, which signify in different ways, are > apparently applied in the same way in the proposition. > > `Thus the word "is" appears as the copula, as the sign of equality, and as > the expression of existence; "to exist" as an intransitive verb like "to > go"; "identical" as an adjective; we speak of SOMETHING but also of the > fact of SOMETHING happening. "That depends on what the definition of "is" is." -- William Jefferson Clinton > > `(In the proposition "Green is green" - where the first word is a proper > name and the last an adjective - these words have not merely different > meanings but they are DIFFERENT SYMBOLS.) > > `Thus there easily arise the most fundamental confusions (of which the > whole of philosophy is full). > > `In order to avoid these errors, we must employ a symbolism which excludes > them, by not applying the same sign in different symbols and by not > applying signs in the same way which signify in different ways. A > symbolism, that is to say, which obeys the rules of LOGICAL grammar - of > logical syntax. > > `(The logical symbolism of Frege and Russell is such a language, which, > however, does still not exclude all errors.) > > `In order to recognize the symbol in the sign we must consider the > significant use. > > `The sign determines a logical form only together with its logical > syntactic application. > > `If a sign is NOT NECESSARY then it is meaningless. That is the meaning of > Occam's razor.' > > - Wittgenstein, Tractatus Logico-Philosophicus, propositions 3.323-3.328. > > (Capitals used in place of italics. Translation is the original 1922 > version, by Ogden, which had Wittgenstein's approval. Published in London > & New York by by Routledge; reprinted 1996.) > > If I may veer into another language, C - and thus justify adding another > news group to the `to' line - > > #include <stdio.h> > main() > { > int a[100]; /* `a' means array */ > printf("%p\n", a); /* `a' means pointer */ > a = a + 1; /* ILLEGAL, since `a' means array again */ > } > > `a' here means two different things: > > (1) an array of 100 normal-width integers; > (2) a pointer to a normal-width integer (in fact, to the first integer in > an array of 100 such). > > To say that, in the call to printf(), the first thing is implicitly > converted to the second thing is to linguistically `work around' the basic > problem, that `a' has two meanings. Meaning (2) can also be expressed as > > &a[0] > > So, the example reveals two faults in the C language. Namely, that `a', as > a local variable in one function, can have two meanings; and also that one > of these meanings is may be expressed by either of two symbols. This is a > crying shame! Why does `a' have two meanings, when, given the possibility > of `&a[0]', one would have sufficed without reducing the functionality of > the language? > > The answer is historical, as revealed by an interesting paper, "The > Development of the C Language" by Dennis Ritchie, available from Dennis > Ritchie's home page, http://plan9.bell-labs.com/cm/cs/who/dmr/index.html. > > Daniel Barker, > Institute of Cell and Molecular Biology, > Swann Building, > King's Buildings, > Mayfield Road, > Edinburgh > EH9 3JR > UK ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-24 0:00 ` Jeff Templon 1998-09-25 0:00 ` Dale Stanbrough @ 1998-09-25 0:00 ` dewarr 1 sibling, 0 replies; 83+ messages in thread From: dewarr @ 1998-09-25 0:00 UTC (permalink / raw) In article <m3vhmdfqpa.fsf@visar.physast.uga.edu>, Jeff Templon <templon@visar.physast.uga.edu> wrote: > "Marc A. Criley" <marc.a.criley@lmco.com> writes: > > > Jeff Templon wrote: > > > > I would write some examples, but no time. Sorry. > > > [Robert Dewar mode on :-] > > It is unreasonable to expect anyone to accept your highly-contested > > assertions at face value, and cite "no time" as justification for > > not providing examples for peer review in defense of your point. > > [RD off] Seeing as my name is being bandied about here, I would remark that this is awfully similar to what Fermat did to the world of mathematicians :-) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
[parent not found: <6udre0$ha1$1@nnrp1.dejane <6utg60$h6l$1@nnrp1.dejanews.com>]
* Re: Fortran or Ada? [not found] ` <6udre0$ha1$1@nnrp1.dejane <6utg60$h6l$1@nnrp1.dejanews.com> @ 1998-10-01 0:00 ` robin_v 0 siblings, 0 replies; 83+ messages in thread From: robin_v @ 1998-10-01 0:00 UTC (permalink / raw) In <6utg60$h6l$1@nnrp1.dejanews.com>, dewarr@my-dejanews.com writes: > >In article <19980929.214309.386@yktvmv.watson.ibm.com>, > jbs@yktvmv.watson.ibm.com wrote: >> The accident report indicates that they deliberately >> chose not to do it in this case because they were worried about >> performance. This would seem to indicate that turning off the >> error check is not cheap (in terms of performance). >> James B. Shearer >This is incomprehensible. Turning off a check eliminates the code for the >check and eliminates the performance penalty of the check. What are you >trying to say here? I think he's cracking a joke in the form of master of the understatement. By saying that ther error check is not cheap (in terms of performance), he's saying that it was a very expensive error. Posted from OS/2 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-22 0:00 ` Jeff Templon ` (2 preceding siblings ...) 1998-09-22 0:00 ` dewarr @ 1998-09-22 0:00 ` Rakesh Malhotra 1998-09-23 0:00 ` Frank Ecke 4 siblings, 0 replies; 83+ messages in thread From: Rakesh Malhotra @ 1998-09-22 0:00 UTC (permalink / raw) Jeff Templon wrote: > Hi, > one other word on Ada ... it is a very complex language. Take a look > at Cohen's "Ada as a Second Language" book and compare it Metcalf [snip] Hi Jeff, Yes, you are correct in saying that if someone needs to know the _full_ language then Ada is larger/more complex than, say, C is. However, as has been said many times before what kind of complexity are you talking about: - complex to read - complex to write compilers for - complex to program in - complex to learn etc Note: C is supposed to be simple but then it has these "complex" operator precedence rules which can bite you. Presumably you are refering to complex to learn, complex to write/read in. Here I would have to disagree. I learnt Ada about 8 years ago through a 5 day class. At this time I did not have much sw development experience (I knew some Pascal and C). Ada was very easy to learn. Ofcourse, since I was doing a safety critical system we were not taught the full language; just an appropriate, necessary subset. Over the years I have used this subset very successfully on many commercial projects and have taught myself other features of Ada as and when I needed them. I am sure that the above is what most people do when they start working in other languages also. I doubt that anyone first learns the full language and then does useful work. e.g. presently I am doing work that needs use of C and C++; I certainly do not know all of C++. The good thing about Ada is that it has a number of very useful, well designed features that all hang together well because they have been designed to do so. If you do not need a feature you can avoid using them without severely impacting other features that you do want to use. e.g if you do not want to use tasking you never need to know about it. Similarly if you do not need to use generics you can get by with very little knowledge of it. If you do not do much floating point (which I doubt since this is posted to c.l.fortran :) ) then you do not need to know about the special stuff Ada has to support fixed/floating types. Similar things can be said about other syntactic constructs. So, yes, Ada is big (I would call Ada big rather than complex) if you need to learn all of it at one go but if you don't then it is not that difficult. -- Rakesh ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-22 0:00 ` Jeff Templon ` (3 preceding siblings ...) 1998-09-22 0:00 ` Rakesh Malhotra @ 1998-09-23 0:00 ` Frank Ecke 4 siblings, 0 replies; 83+ messages in thread From: Frank Ecke @ 1998-09-23 0:00 UTC (permalink / raw) On 22 Sep 1998 11:41:47, Jeff Templon <templon@visar.physast.uga.edu> wrote: >one other word on Ada ... it is a very complex language. The world we live in is highly complex. Ada is a language for a complex world. >So Ada loses in this respect : there is a lot of language to know. >This makes it more difficult to write programs, unless one invests >the time to learn the language well. This amount of time would >be less for Fortran. What about the time to read (and understand) or maintain a program? Software Engineering tells us that the time (and money) spent on maintenance outweighs the time for coding by a considerable amount. IMHO, Ada builds a bridge between expressive power and ease of use. Regards, Frank -- Frank Ecke <franke@minet.uni-jena.de> In a world without walls and fences, who needs windows and gates? ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-22 0:00 ` Fortran or Ada? Gisle S{lensminde 1998-09-22 0:00 ` Jeff Templon @ 1998-09-23 0:00 ` bglbv 1998-09-23 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 83+ messages in thread From: bglbv @ 1998-09-23 0:00 UTC (permalink / raw) gisle@krake.ii.uib.no (Gisle S{lensminde) wrote: [lots of good remarks, I'll only correct a few factual errors and add a few glosses of my own] [> > lines are by Siamak Kaveh] > > 2. Packages and types can be made generic (parameterized through a > > template) to help create reusable components. > > That is also in Fortran 90/95 AFAIK. No, unfortunately Fortran 90/95 does not even have parameterized derived types (Ada: record types with discriminants), much less generic subprograms and modules. The parameterized derived types are scheduled for Fortran 2000, I believe, but generics aren't (and this fact has been bemoaned recently in comp.lang.fortran; see postings by William Clodius on this subject, as well as his papers in the J3 archive repository). > > 3. Errors can be signaled as exceptions and handled explicitly. Many > > serious errors (such as computational overflow and invalid array > > indexes) are automatically caught and handled through this exception > > mechanism, improving program reliability. > > Yes, and this detects many errors, but I think some Fortran 90 compilers > also checks indexes, if you ask them to do so. Maybe not as good > as Ada. The main difference is that Fortran does not have a good exception handling mechanism. Some drafts of Fortran 8X did have one along the lines of Ada's facilities, but it was left out of the final standard. (Don't ask me why; the ultimate answer is political, in the form of "couldn't get enough votes in favour". There are also some objective technical difficulties, though Ada's example suggests that these can be overcome.) Among other things, an Ada-like exception mechanism in Fortran would provide the ability to recover from errors in allocating storage for automatic variables, compiler-generated temporaries, etc. Currently, one can recover from errors in explicitly coded ALLOCATE statements by using the STAT= keyword (and even then, only if the error is immediately apparent at the time of allocation; problems due to overcommitting swap space may still cause the program to crash unpredictably later on) but not from much else. > > 4. Tasks (multiple parallel threads of control) can be created and > > communicate. This is a major capability not supported in a standard way > > by many other languages. > > Yes ... although perhaps it is worth mentioning the Fortran binding to the Message Passing Interface (MPI) standard. > > 6.A predefined library is included; it provides input/output (I/O), > > string manipulation, numeric functions, a command line interface, and a > > random number generator (the last two were available in Ada 83, but are > > standardized in Ada 95). Note that Fortran 90/95 provides most of these facilities. There is a command line interface proposal in the current Fortran 2000 draft. What Fortran does not provide is direct language support for fixed-point types (you have to implement them yourself, usually but not necessarily with integers). > > 2) Is there any comparison between performance of Fortran90/95 and Ada95 > > compilers? > It is difficult to compare two different languages in a fair way. For > example > Ada has index checking and exception handling wich Fortran doesn't. > You can of cause turn off these, but it's often valuable to use them, > becase they trap bugs on an early stage, and makes the code more > reliable Such features has a performance penalty. I seem to recall there is some debate over whether exception handling need entail a performance penalty when no exceptions are actually raised. (Of course fragmenting the code into very small blocks may prevent the optimizer from changing the order of execution.) It goes without saying that a fair comparison would be between codes that use equivalent features of both languages. That is, one would either turn bounds checking on or off in both compilers. And the Ada code might use exceptions only where Fortran has alternate returns or ERR=/END=/EOR= branches. > But if we write comparable code in both languages, I would think that > Fortran would win in a raw speed test, because some of the Fortran > compilers optimize extremly well. In other words, Fortran wins because the Fortran compilers currently on the market are generally better at optimizing numerically intensive code than the available Ada compilers. It would still be nice to produce a few benchmarks (no, not TEST_FPU, please; though TEST_FPU might actually be more useful for this purpose than for comparing hardware platforms) to test this very plausible but I think unconfirmed statement. > C++ disqualifies from critical code for several reasons. Things like > pointers and pointer aritmetrics and the possibility to cast everything to > everything, makes the language unsafe. Many such systems must Well, Ada also has Unchecked_Conversion if you feel so inclined. It's use is just easier to review. > have total control of memory usage, and no dynamic memory usage is > allowed in many cases, and makes C and C++ is impossible to use in the > highest safity levels. (But C is used in some safity critical stuff > anyway, and C is widely used for embedded targets.) > > Fortran do not have all the weakneses of C this respect, but is still See my remarks above about recovering from memory allocation problems in Fortran. Also remember that the design and testing methodology often counts for more than the language itself. Ariane 501 was lost due to a bug in Ada code. (My understanding is that it was an error in the specification; that the code happened to be written in Ada was not particularly significant.) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-23 0:00 ` bglbv @ 1998-09-23 0:00 ` Robert I. Eachus 1998-09-24 0:00 ` Richard D Riehle 0 siblings, 1 reply; 83+ messages in thread From: Robert I. Eachus @ 1998-09-23 0:00 UTC (permalink / raw) In article <6uan3f$7qe$1@nnrp1.dejanews.com> bglbv@my-dejanews.com writes: > Also remember that the design and testing methodology often counts for more > than the language itself. Ariane 501 was lost due to a bug in Ada code. > (My understanding is that it was an error in the specification; that the > code happened to be written in Ada was not particularly significant.) Actually the fact that it was written in Ada did help find the potential problem. Unfortunately, when it was reviewed in a Ariane 4 context, the potential problem was found, but it was not fixed since it could "never happen." Physical constraints prevented the problem from ever occuring in an Ariane 4. The problem was in reusing the guidance software in the Ariane 5 without changes or review. This can be seen in the fact that once the bug occurred, the engines deflected enough to cause the stack to break apart, just like a falling chimney. So the real problem was that the Ariane 5 was flying with software whose built in safety limits were set for the Ariane 4. The particular case that caught them was just the first to materialize. Remember this the next time someone tells you how wonderful software reuse is. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Fortran or Ada? 1998-09-23 0:00 ` Robert I. Eachus @ 1998-09-24 0:00 ` Richard D Riehle 0 siblings, 0 replies; 83+ messages in thread From: Richard D Riehle @ 1998-09-24 0:00 UTC (permalink / raw) In article <EACHUS.98Sep23153612@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) wrote: in response the the Ariane V criticism, > Actually the fact that it was written in Ada did help find the >potential problem. [ ... snip, snip, snip ... ] > So the real problem was that the Ariane 5 was flying with software >whose built in safety limits were set for the Ariane 4. [ ... snip, snip, snip ... ] > Remember this the next time someone tells you how wonderful >software reuse is. Software reuse is like taking drugs. If your doctor prescribes a medication that will help make you well and if the pharmacist fills the prescription properly, and if you have been assessed as having no contraindicated conditions or conflicting medications, there is a low probability of failure. Any error in this process could cause a total system and potential run-time fault. Death might ensue. If one uses a contraindicated software component, whether because of specification error, diagnostic error, or programming error, the result can be the same. If I recall the discussion of this issue correctly, in the case of Ariane V, the wrong component was selected and used for the program. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 83+ messages in thread
end of thread, other threads:[~1998-10-08 0:00 UTC | newest] Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <36068E73.F0398C54@meca.polymtl.ca> 1998-09-22 0:00 ` Fortran or Ada? Gisle S{lensminde 1998-09-22 0:00 ` Jeff Templon 1998-09-22 0:00 ` Corey Minyard 1998-09-22 0:00 ` Larry Kilgallen 1998-09-22 0:00 ` dewarr 1998-09-23 0:00 ` Jeff Templon 1998-09-23 0:00 ` Corey Minyard 1998-09-24 0:00 ` Joel Seidman 1998-09-24 0:00 ` Craig Burley 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Jonathan Guthrie 1998-09-26 0:00 ` Craig Burley 1998-09-26 0:00 ` dewarr 1998-09-26 0:00 ` Craig Burley 1998-09-26 0:00 ` Robert B. Love 1998-09-24 0:00 ` Marc A. Criley 1998-09-24 0:00 ` dewarr 1998-09-24 0:00 ` Robert I. Eachus 1998-09-24 0:00 ` William Clodius 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Robert I. Eachus 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` jbs 1998-09-26 0:00 ` dewarr 1998-09-28 0:00 ` jbs 1998-09-29 0:00 ` William B. Clodius 1998-09-30 0:00 ` jbs 1998-09-30 0:00 ` William Clodius 1998-09-30 0:00 ` dewarr 1998-09-30 0:00 ` jbs 1998-09-30 0:00 ` William Clodius 1998-10-03 0:00 ` Niklas Holsti 1998-10-03 0:00 ` Toon Moene 1998-10-03 0:00 ` Niklas Holsti 1998-10-03 0:00 ` Toon Moene 1998-10-04 0:00 ` Niklas Holsti 1998-10-05 0:00 ` Michel OLAGNON 1998-10-05 0:00 ` Ian St. John 1998-10-05 0:00 ` dewarr 1998-10-05 0:00 ` Ian St. John 1998-10-06 0:00 ` dewarr 1998-10-06 0:00 ` Ian St. John 1998-10-08 0:00 ` Gary L. Scott 1998-10-08 0:00 ` Offtopic Airport Diversion (Was: Fortran or Ada?) Harold Stevens ** PLEASE SEE SIG ** 1998-10-08 0:00 ` Ian St. John 1998-10-06 0:00 ` Fortran or Ada? Toon Moene 1998-10-06 0:00 ` Jonathan Guthrie 1998-10-06 0:00 ` James Giles 1998-10-06 0:00 ` Mark A Biggar 1998-10-06 0:00 ` James Giles 1998-10-07 0:00 ` dewarr 1998-10-07 0:00 ` dewarr 1998-10-05 0:00 ` Richard D Riehle 1998-10-05 0:00 ` dewarr 1998-10-06 0:00 ` Michel OLAGNON 1998-10-07 0:00 ` Ian St. John 1998-09-29 0:00 ` Dean F. Sutherland 1998-09-29 0:00 ` Dean F. Sutherland 1998-09-29 0:00 ` Gautier.DeMontmollin 1998-09-29 0:00 ` Dean F. Sutherland 1998-10-02 0:00 ` Geoff Bull 1998-10-02 0:00 ` Robert I. Eachus 1998-10-02 0:00 ` jbs 1998-10-02 0:00 ` William Clodius 1998-10-03 0:00 ` jbs 1998-10-03 0:00 ` Larry Elmore 1998-10-06 0:00 ` Robert I. Eachus 1998-10-06 0:00 ` Pat Rogers 1998-09-24 0:00 ` Jeff Templon 1998-09-25 0:00 ` Dale Stanbrough 1998-09-30 0:00 ` Daniel Barker 1998-09-30 0:00 ` Lawrence Kirby 1998-10-01 0:00 ` Aaron Crane 1998-10-02 0:00 ` Fortran or Ada or gobbledygook? Wes Groleau 1998-10-05 0:00 ` Fortran or Ada? Terry Devine 1998-09-25 0:00 ` dewarr [not found] ` <6udre0$ha1$1@nnrp1.dejane <6utg60$h6l$1@nnrp1.dejanews.com> 1998-10-01 0:00 ` robin_v 1998-09-22 0:00 ` Rakesh Malhotra 1998-09-23 0:00 ` Frank Ecke 1998-09-23 0:00 ` bglbv 1998-09-23 0:00 ` Robert I. Eachus 1998-09-24 0:00 ` Richard D Riehle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox