Re: Fortran or Ada?

Re: Fortran or Ada?

[Gisle S{lensminde]

> 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

Re: Fortran or Ada?

[Jeff Templon]

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

Re: Fortran or Ada?

[Larry Kilgallen]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[Rakesh Malhotra]

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

Re: Fortran or Ada?

[Corey Minyard]

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

Re: Fortran or Ada?

[Frank Ecke]

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?

Re: Fortran or Ada?

[bglbv]

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

Re: Fortran or Ada?

[Jeff Templon]

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

Re: Fortran or Ada?

[Corey Minyard]

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

Re: Fortran or Ada?

[Robert I. Eachus]

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...

Re: Fortran or Ada?

[Richard D Riehle]

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

Re: Fortran or Ada?

[Marc A. Criley]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[Jeff Templon]

"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

Re: Fortran or Ada?

[Craig Burley]

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

Re: Fortran or Ada?

[Robert I. Eachus]

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...

Re: Fortran or Ada?

[William Clodius]

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

Re: Fortran or Ada?

[Joel Seidman]

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!

Re: Fortran or Ada?

[Dale Stanbrough]

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?

Re: Fortran or Ada?

[Jonathan Guthrie]

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.

Re: Fortran or Ada?

[Robert I. Eachus]

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...

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[jbs]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[Robert B. Love]

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                            
----------------------------------------------------------------

Re: Fortran or Ada?

[Craig Burley]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[Craig Burley]

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

Re: Fortran or Ada?

[jbs]

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

Re: Fortran or Ada?

[Dean F. Sutherland]

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

Re: Fortran or Ada?

[Dean F. Sutherland]

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

Re: Fortran or Ada?

[Dean F. Sutherland]

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

Re: Fortran or Ada?

[Gautier.DeMontmollin]

>          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

Re: Fortran or Ada?

[William B. Clodius]

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

Re: Fortran or Ada?

[jbs]

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

Re: Fortran or Ada?

[dewarr]

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

Re: Fortran or Ada?

[William Clodius]

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

Re: Fortran or Ada?

[jbs]

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

Re: Fortran or Ada?

[William Clodius]

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

Re: Fortran or Ada?

[Lawrence Kirby]

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
-----------------------------------------

Re: Fortran or Ada?

[Daniel Barker]

`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

Re: Fortran or Ada?

[robin_v]

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

Re: Fortran or Ada?

[Aaron Crane]

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.

Re: Fortran or Ada?

[jbs]

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

Re: Fortran or Ada?

[William Clodius]

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

Re: Fortran or Ada?

[Geoff Bull]

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?

Re: Fortran or Ada or gobbledygook?

[Wes Groleau]

> `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!
-------------------------------------------------------------------

Re: Fortran or Ada?

[Robert I. Eachus]

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...

Re: Fortran or Ada?

[jbs]

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

Re: Fortran or Ada?

[Niklas Holsti]

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)

Re: Fortran or Ada?

[Toon Moene]

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

Re: Fortran or Ada?

[Larry Elmore]

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

Re: Fortran or Ada?

[Niklas Holsti]

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.

Re: Fortran or Ada?

[Toon Moene]

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

Re: Fortran or Ada?

[Niklas Holsti]

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.)

Re: Fortran or Ada?

[Michel OLAGNON]

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                   |

Re: Fortran or Ada?

[Ian St. John]

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.

Re: Fortran or Ada?

[dewarr]

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    

Re: Fortran or Ada?

[dewarr]

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    

Re: Fortran or Ada?

[Terry Devine]

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

Re: Fortran or Ada?

[Ian St. John]

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.

Re: Fortran or Ada?

[Richard D Riehle]

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
 

Re: Fortran or Ada?

[dewarr]

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    

Re: Fortran or Ada?

[Toon Moene]

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

Re: Fortran or Ada?

[James Giles]

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

Re: Fortran or Ada?

[Jonathan Guthrie]

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.

Re: Fortran or Ada?

[Mark A Biggar]

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

Re: Fortran or Ada?

[Robert I. Eachus]

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...

Re: Fortran or Ada?

[Michel OLAGNON]

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                   |

Re: Fortran or Ada?

[James Giles]

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

Re: Fortran or Ada?

[Pat Rogers]

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

Re: Fortran or Ada?

[Ian St. John]

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.. ****

Re: Fortran or Ada?

[dewarr]

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    

Re: Fortran or Ada?

[dewarr]

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    

Re: Fortran or Ada?

[Ian St. John]

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.

Offtopic Airport Diversion (Was: Fortran or Ada?)

[Harold Stevens ** PLEASE SEE SIG **]

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.

Re: Fortran or Ada?

[Gary L. Scott]

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

Re: Offtopic Airport Diversion (Was: Fortran or Ada?)

[Ian St. John]

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 ..  ;-)