From: "Tokoro, David" <tokoro@NOSC.MIL>
Subject: Re: INFO-ADA Digest - 19 Mar 1997 - Special issue
Date: 1997/03/19
Date: 1997-03-19T00:00:00+00:00 [thread overview]
Message-ID: <c=US%a=_%p=AQUARIUS%l=CYGNUS-970319220525Z-15129@cygnus.nosc.mil> (raw)
Please REMOVE me from this mailing list.
Thanks,
David M.Tokoro
***************************************
Business Systems Branch N318
Phone: (619) 553-2707
E-mail: tokoro@nosc.mil
***************************************
>----------
>From: Automatic digest processor[SMTP:LISTSERV@LISTSERV.NODAK.EDU]
>Sent: Wednesday, March 19, 1997 2:03 PM
>To: Recipients of INFO-ADA digests
>Subject: INFO-ADA Digest - 19 Mar 1997 - Special issue
>
>There are 3 messages totalling 1100 lines in this issue.
>
>Topics in this special issue:
>
> 1. Random Numbers
> 2. Papers on the Ariane-5 crash and Design by Contract
> 3. INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>
>----------------------------------------------------------------------
>
>Date: Wed, 12 Mar 1997 17:06:48 GMT
>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>Subject: Re: Random Numbers
>
>In article <5g56sj$tqq$1@krusty.irvine.com> adam@irvine.com (Adam Beneschan)
>writes:
>
> > Is this algorithm correct? I'm suspicious. The above code generates
> > a random number between 1 and 52 fifty-two times, meaning that number
> > of different possibile sequences of random numbers generated is
> > 52**52. However, the number of possible orderings of a deck is 52!.
> > This indicates to me that the above code does not generate the
> > possible deck orderings uniformly (although the discrepancy may be
> > slight).
>
> Actually, the number of different deck orderings generated will
>depend on the period of the underlying PRNG. In other words, the
>maximum number of different deck orders generated will depend on the
>possible different states at the start of the shuffle. Usually this
>will be the number of different possible PRNG states which will be
>much, much smaller than 52!.
>
> You can fix this by using more than one INDEPENDENTLY SEEDED
>random number generator. You can either choose successive values from
>different generators, or shuffle with one generator as above then
>shuffle again with the second, etc.
>
> In practice for any card games involving human players, the
>number of different possibilities from one generator is enough. If
>you are planning to write a program and run it unattended for weeks to
>compare two different playing strategies for say, blackjack, you
>probably should use multiple generators. (Incidently, there are
>computer games with junk generators where I find that the ability to
>predict the sequence gives me an enormous edge over the computer
>player.)
>
>--
>
> Robert I. Eachus
>
>with Standard_Disclaimer;
>use Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 19:56:21 GMT
>From: John McCabe <john@ASSEN.DEMON.CO.UK>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>Bertrand Meyer <bertrand@eiffel.com> wrote:
>
>>The real problem was that the assertion was not part of the software.
>
>No - the real problem was that the developers were _not_ provided with
>Ariane 5 trajectory information which should have been used in the
>analysis.
>
>
>Best Regards
>John McCabe <john@assen.demon.co.uk>
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 13:52:44 -0800
>From: "Tokoro, David" <tokoro@NOSC.MIL>
>Subject: Re: INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>
>Please REMOVE me from this mailing list.
>
>Thanks,
>
>David M.Tokoro
>***************************************
>Business Systems Branch N318
>Phone: (619) 553-2707
>E-mail: tokoro@nosc.mil
>***************************************
>
>>----------
>>From: Automatic digest processor[SMTP:LISTSERV@LISTSERV.NODAK.EDU]
>>Sent: Wednesday, March 19, 1997 1:47 PM
>>To: Recipients of INFO-ADA digests
>>Subject: INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>>
>>There are 26 messages totalling 1002 lines in this issue.
>>
>>Topics in this special issue:
>>
>> 1. Tasking In Ada 83 "Question"
>> 2. Do I Really Need A Supervisor? (2)
>> 3. Access to primitive operations of tagged types
>> 4. Papers on the Ariane-5 crash and Design by Contract (6)
>> 5. CRC in Ada? (5)
>> 6. Static variables?
>> 7. UNIX Texteditor for GNAT Ada95 3.07
>> 8. floating point problem (2)
>> 9. Ada Sockets
>> 10. Gnat 3.04a for 95 wierdness
>> 11. Random Numbers
>> 12. Please do not start a language war (was Re: Papers on the Ariane-5
>>crash
>> and Design by Contract
>> 13. Ariane-5: can you clarify? (Re: Please do not start a language war)
>> 14. need free compiler
>> 15. numerical libraries
>>
>>----------------------------------------------------------------------
>>
>>Date: Tue, 18 Mar 1997 19:50:19 -0600
>>From: "James A. Squire" <m193884@CSEHP1.MDC.COM>
>>Subject: Re: Tasking In Ada 83 "Question"
>>
>>In article <332F3050.74B8@mccabe.com>,
>>Michael Ibarra <ibarra@mccabe.com> wrote:
>>>I have a task, and I want to perform some action when I know that my
>>>task has terminated. I can't tell when it has terminated. My task
>>>looks something like:
>>>
>>>Task Body timer is
>>>begin
>>>loop
>>> select
>>> accept receive_call do
>>> null;
>>> end receive_call;
>>> or
>>> terminate;
>>> end select;
>>>end loop;
>>>end timer;
>>>
>>>My problem is that in order to check the terminated attribute of the
>>>task, I need to with the package that is parent/master to the task,
>>>therefore preventing it from becoming terminated.
>>
>>I don't quite understand this statement. If the task is pretty much
>>like you have it there, withing it's parent seems to have absolutely
>>nothing to do with preventing it from becoming terminated. Or else
>>I don't have enough information here.
>>
>>It seems to me that what prevents this task from terminating is the
>>mere fact that the program is still running, since the only way it
>>terminates (apart from some other task aborting it or an exception
>>being raised from within) is when all other tasks including the main
>>task are finished - hence when the program is finished. There is no
>>stop entry, and the loop is endless. The terminate statement only
>>ensures that the program won't be left hanging if every other task
>>is finished.
>>
>>>This is NEVER true. Is there any way that I can konw when this task
>>>has terminated. I wanted to perform some jobs ONLY after this task
>>>is terminated.
>>
>>If you want to do anything after such a task terminates, then you'll
>>have to pick some other way for the task to terminate, it seems to
>>me. The options I'm aware of are: (1) adding a Stop entry, (2) adding
>>some condition that exits the loop, (3) abort the task. It looks like
>>(2) is closest to what you are looking for since you are treating
>>termination of this task as if it is non-deterministic to the other tasks
>>in your program.
>>
>>Either that or you need to give us more info.
>>--
>>James Squire mailto:m193884 no junk mail allowed@csehp1.mdc.com
>>MDA Avionics Tools & Processes
>>McDonnell Douglas Aerospace http://www.mdc.com/
>>Opinions expressed here are my own and NOT my company's
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 14:22:59 -0500
>>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>>Subject: Re: Do I Really Need A Supervisor?
>>
>><<Obviously people have some complaints here. You've only
>>responded with a remark aimed (obviously) to intimidate.>>
>>
>>Well I understand that some people regard the idea of strong management
>>as intimidating, and that's fine, different people work in different ways.
>>All I am saying is that as far as I am concerned strong management is
>>essential to software quality. Even in such a minor aspect as coding
>>standards, if you have a bunch of "I don't need no stinkin' supervisor"
>>hackers, you will have trouble solving even this trivial problem (of
>>requiring consistent surface syntax).
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 23:34:25 GMT
>>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>>Subject: Re: Access to primitive operations of tagged types
>>
>>In article <hkbmg5.2h2.ln@localhost> njt@sv1pc161.cs.york.ac.uk (Nigel J.
>>Tracey) writes:
>>
>>> My problem is however that I cannot pass an access to the callback
>>> functions when installing the callback routine in X. The Ada RM
>>> states that a dereference of an access-to-subprogram value is never
>>> a dispatching call.
>>
>>Make the "access" registered functions non dispatching, make them
>>private (or better yet in a body), and have them _call_ their
>>appropriate dispatchable operation.
>>
>>/Jon
>>--
>>Jon Anthony
>>Organon Motives, Inc.
>>Belmont, MA 02178
>>617.484.3383
>>jsa@organon.com
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 20:57:14 GMT
>>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>In article <5gll90$2qu$1@news.irisa.fr> jezequel@irisa.fr (Jean-Marc
>>Jezequel)
>>writes:
>>
>>> To answer Jon S Anthony, yes, all that could have been done in Ada
>>>using:
>>> function Convert ( Horizontal_Bias: Integer ) return Integer is
>>> subtype Bias_Constraint is Integer range 0..Maximum_Bias;
>>> Require : Bias_Constraint := Horizontal_Bias;
>>>
>>> Ada's subtype declarations are a kind of contract, that could be
>>> documented as such. Design by contract is not specific to
>>> Eiffel. You can do it with any language, just because it is a way of
>>> designing! Eiffel is, however, one of the few languages that provide
>>> built-in support for it.
>>
>>You miss my point. Which is that this stuff is NOT sufficient to have
>>prevented this error. And further, the evidence supports this
>>position because the language used in fact _does_ have this capability
>>but it was _not_ used. While design by contract is a good first step,
>>it _too_ is simply insufficient as currently realized. It in no way
>>captures any of the semantic context that scopes the usage scenarios
>>that are assumed in the design and implementaion of "components".
>>
>>
>>> Let's finally sum up what I perceive as the most important claims in
>>> this paper:
>>> - reusing a component without checking its full
>>> specification is dangerous, which means that simple minded
>>> CORBA-like approaches at building components for mission-critical
>>> software are doomed.
>>
>>Agreed, but this too is simply way too simplistic. If "full
>>specification" simply means signatures and their pre and post
>>condition requirements, it does not capture the "full" scope of the
>>problem. If it does include the various semantic aspects associated
>>with "components", it is not and, what is more, _cannot_ be captured
>>in signatures and assertions.
>>
>>
>>> - using design by contract is an interesting
>>> way to specify the behavior of a component
>>
>>Yes, but _only_ a rather _limited_ aspect. It is clearly better than
>>nothing, but alone it could not prevent the sort of problem being
>>discussed.
>>
>>
>>> - at least in the case of
>>> Ariane 501, simple assertions (a la Eiffel and other languages)
>>> would have been expressive enough to specify the fatal hidden
>>> assumption.
>>
>>This I simply don't believe. And the evidence does not support it
>>either.
>>
>>
>>/Jon
>>--
>>Jon Anthony
>>Organon Motives, Inc.
>>Belmont, MA 02178
>>617.484.3383
>>jsa@organon.com
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 21:26:00 -0600
>>From: Michael & Amy Hartsough <Hartsough@WORLDNET.ATT.NET>
>>Subject: Re: CRC in Ada?
>>
>>Robert Dewar wrote:
>>> Michael said
>>> <<I instantiated Sequential I/O with an unsigned 8-bit type>>
>>>
>>> OUCH! Sequential_IO is intended to be used for logical record I/O.
>>> I can see that one might be tempted to write non-portable code that
>>> (mis)used Sequential_IO in this manner in Ada 83 if you felt compelled
>>> to use the Ada 83 IO packages, instead of the more obvious choice of
>>> using C packages for a case like this (Ada 83 really lacked stream io,
>>> and in a case like this, which is obviously a case for stream io, the
>>> proper response in my view is to interface to C, rather than misuse
>>> the Ada packages).
>>
>>I had been directed to implement CRC32 in Ada 83, and test its output
>>against
>>the output of a C++ version of the algorithm. As soon as testing was
>>completed
>>the CRC32 code (sans file I/O) was lifted out of the test program and
>>inserted
>>into an existing embedded application that reads data from a PCMCIA card.
>>
>>So yes, I DID feel compelled to use an Ada 83 I/O package. I don't think my
>>employer would have much appreciated my spending half a day chasing down
>>some C file I/O routines to improve the throughput of my test program.
>>
>>> It is not at all surprising
>>> that you would see the peformance difference, and it says nothing
>>> about Ada-vs-C performance.
>>
>>Certainly not Ada versus C, but definitely one compiler versus another
>>compiler.
>>Pick your I/O package and your language, and 18 minutes versus 27 seconds to
>>read
>>the same file certainly tells you something. HIS compiler (which happens to
>>be
>>C++) has buffered file I/O. MY compiler (which happens to be Ada 83) does
>>not
>>buffer file I/O.
>>
>> Michael
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 21:57:05 -0600
>>From: Ray McVay <bmcvay@ARLINGTON.NET>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>John McCabe wrote:
>>>
>>> Bertrand Meyer <bertrand@eiffel.com> wrote:
>>>
>>> >The real problem was that the assertion was not part of the software.
>>>
>>> No - the real problem was that the developers were _not_ provided with
>>> Ariane 5 trajectory information which should have been used in the
>>> analysis.
>>>
>>> Best Regards
>>> John McCabe <john@assen.demon.co.uk>
>>
>>Finally! Thank you, sir. It was obvious from reading the report that
>>was pointed out several months ago by a post in this newsgroup that this
>>was a wonderful example of a failure WAY early in the lifecycle. It had
>>nothing to do with design or construction and everything to do with a
>>bogus specification. They were in effect designing a control system for
>>a completely different rocket than the one in which the system was used!
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 19:49:37 -0800
>>From: nasser@APLDBIO.COM
>>Subject: Re: Do I Really Need A Supervisor?
>>
>>In article <332E163F.5EFD@earthlink.net>, antialias@earthlink.net says...
>>>
>>>Oh, heck, maybe it didn't belong on comp.lang.ada, but this
>>>IS the kind of software engineering environment that Ada
>>>software is developed in...
>>
>>it is unfortunate to the Ada language that it happened to be
>>mostly used in environments where zillion levels of managements
>>and entrenched beaucracy (sp?) is the norm, this environment is a
>>turn off for many programmers who would love otherwise to program
>>in Ada but are wary of the surrounding working climate where Ada
>>is used.
>>
>>Nasser
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 22:25:11 -0800
>>From: nasser@APLDBIO.COM
>>Subject: Re: Static variables?
>>
>>as Dr Dewar mentioned, package variables retain their values
>>from the time the package becomes avaliable to the time the
>>package life ends (usually the end of the program , but not
>>always the case, example, if the package is declared inside
>>a block or procedure), may be a picture will help:
>>
>>
>>
>> package A interface
>> +---------------------+
>> | i: integer; -----------> retain its value also
>>client <=======> | procedure foo; |
>> | ....... |
>> +---------------------+
>>
>> .............................................
>>
>> package A body
>> +---------------------+
>> |j: integer; --------------> these variables retain
>> | | their values
>> | procedure foo is |
>> | n: integer; ------------> variables here are auto
>> | begin | variables, new copies are
>> | .... | created each time foo is
>>called
>> | end foo; |
>> | |
>> | begin |
>> | .... ----------------> this code execute once when
>> | end A; | package is first elaborated.
>> | | use this code to init package
>> +---------------------+ variables.
>>
>>
>>you can think of variables declared in the package interface as static
>>puplic
>>in C++ class terminolgy, and variables declared in the body of the package
>>but outside the functions and procedure of the package body as static
>>private in C++.
>>
>>offcourse it is a good idea to try to avoid using variables in the interface
>>part of the package.
>>
>>nasser
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 10:49:11 +0100
>>From: Paul Chardon <paul.chardon@AVIONS.AEROSPATIALE.FR>
>>Subject: Re: UNIX Texteditor for GNAT Ada95 3.07
>>
>>Hello William,
>>
>> I have been using Emacs or Xemacs with Ada-mode for a few months
>>and
>>if ind it very good. You've got syntactycal coloring, you've got some
>>options to program faster, and then if you're good in lisp (because
>>Emacs uses lisp functions), you can increase the customization offered
>>by emacs, as I have done. You can also compile, execute and eventually
>>debug within Emacs. A lisp file for Emacs Ada-Mode Emacs is normally
>>available with the Gnat.
>>
>> Bye, Paul.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 00:00:30 -0500
>>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>>Subject: Re: floating point problem
>>
>>Larry asks
>>
>><<So can anyone give an example for the Intel-challenged regarding how
>>one would easily detect this float-challenged hardware at runtime in
>>order to issue a nastygram ?>>
>>
>>The proper code is a little delicate, but is documented in the relevant
>>Intel microprocessor manuals. Note that all DX chips, and of course all
>>Pentiums have built-in floating-point, so this is really only a concern
>>with ancient machines that you cannot purchase any longer.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 00:05:41 -0500
>>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>>Subject: Re: CRC in Ada?
>>
>>Graham says
>>
>><<>Sure you can read character by character, but you are paying a
>>considerable
>>>price, even in C, for doing so!
>>
>>Actually: virtually none.>>
>>
>>Well words like considerable and virtually are not very quantitative.
>>There definitely is a price in going character by character (even Balter
>>thinks this extra price might be dominant in something like "cat").
>>
>>Every system where I have measured the effect (e.g. the difference in
>>a compiler that reads large blocks, or does character by character reads,
>>I have seen enough difference to be worth the effort of doing IO in blocks.
>>This is especially true if you can put a sentinel at the end of the block
>>that will naturally be detected by your processing, e.g. an end-of-file
>>mark of some kind in the compiler case, so that you can then process
>>character by character with out a test for buffer exhaustion (once you
>>commit to using getchar, you do of course have a test on each character
>>read for buffer exhuastion, because at that level it is not under
>>your control).
>>
>>GNAT actually works exactly this way, it reads the entire source with
>>a single read, and then puts an end of file sentinel at the end of the
>>source. This provides noticable speed up over character by character
>>processing.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 12:26:09 +0000
>>From: NP GOODGAME <goodganp@ASTON.AC.UK>
>>Subject: Ada Sockets
>>
>>Is there a way to program a socket server completely in Ada 95. I'm
>>using gnat as my compiler on a Sun Solaris UNIX workstation.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 05:27:55 -0800
>>From: Jim Balter <jqb@NETCOM.COM>
>>Subject: Re: CRC in Ada?
>>
>>Robert Dewar wrote:
>>>
>>> Jim said
>>>
>>> <<> If you want something equivalent to the macroized get_char, that is
>>> > trivially easily programmed in C on top of stream_IO, perhaps it is
>>> > a good idea for a standard package
>>>
>>> Since that was the original point, this whole discussion has been
>>> much ado about nothing.
>>> >>
>>>
>>> Actually I mistyped here, what I meant to say was "easily programmed
>>> in Ada on top of [Ada] Stream_IO", and that is what would be a good idea
>>> for a standard package.
>>
>>That's what I took you to mean (i.e., I misread you and thereby
>>read you properly).
>>
>>--
>><J Q B>
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 05:32:54 GMT
>>From: Richard Kaiser <rkaiser@DIMENSIONAL.COM>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>In article <332E8D5D.400F@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk>
>>wrote:
>>>Richard Kaiser wrote:
>>>
>>>> The first mistake was to not put the time limit in some human readable
>>>> documentation, or if the time limit was documenting then it was not read.
>>>> Writing code so it documents itself reduces or eliminates the code
>>>> documentation, but this can be done in Ada, EIffel, C, C++ and even
>>>> assembly language and FORTRAN. These limits are part of the design
>>>> and belong in a Software Requirements/Requirements Verification document
>>>> and in the Version Description Document. And these documents must be
>>>> reviewed prior to reuse.
>>>
>>>The difference between writting comments that document code, and
>>>writting assertions is simple. The assertions will get tested, your
>>>comments will not. I prefer to trust the latter
>>
>>But this software was Never tested. No end-to-end test with the hardware,
>>nor
>>even a software only simulation. If the testing is not performed assertions
>>will not be executed to detect a problem. With proper testing the simulated
>>flight would have failed with or without the assertions.
>>
>>>> >2) Design. Writting assertions makes design easier. This is a personal
>>>> >observation and harder to justify. I find being clear about what
>>>> >something does helps clear up what I am doing. Having complex
>>>> >preconditions is not a good idea, again you probably don't have the
>>>> >right structure.
>>>>
>>>> The code is going to say "I am not in my original application and may or
>>>> will fail?" Assertions are only going to catch problems if there is:
>>>>
>>>
>>>No, the code does what it is contracted to do. If you break the
>>>contract, it raises an exception.
>>
>>But software testing "never re-read the contract".
>>
>>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>>using #include <assert.h> for years? Software engineers have been using
>>assert macros to verify program limits are not exceeded.
>>
>>Richard Kaiser
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 06:03:15 -0800
>>From: Jim Balter <jqb@NETCOM.COM>
>>Subject: Re: CRC in Ada?
>>
>>Robert Dewar wrote:
>>>
>>> Jim said
>>>
>>> <<It take an unusual degree of intellectual dishonesty to misrepresent
>>> one's own point. No more talk here of extra system calls,
>>> buffering not being mandated, or the need to go out and empirically
>>> check 6 implementations.>>
>>>
>>> No, sorry, you are confused, go back and check the thread, I never said
>>> that there were extra system calls, that was someone else with whom I
>>> disagreed!
>>
>>I have already quoted you as saying that a single I/O call per block
>>by the *C library* (not a comment about ADA) is not guaranteed.
>>
>>> As for buffering being mandated, I am not quite sure what you are talking
>>> about here.
>>
>>Sorry to here that you are having so much trouble following the thread.
>>
>>--
>><J Q B>
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 12:54:29 GMT
>>From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>>Subject: Re: Gnat 3.04a for 95 wierdness
>>
>>In article <33259a7a.22085949@news.demon.co.uk>, smoore@chowgar.demon.co.uk
>>(Simon Moore) writes:
>>
>>> p.s. Would it be worthwhile for me to download 3.09 or are the updates
>>> minimal?
>>
>>Ignoring Robert Dewar's specific technical response...
>>
>>...Any software developer will love you more if problem reports
>>are from their latest offering.
>>
>>Even in cases where a product (not just Ada compilers) has two
>>supported versions due to known glitches in the latest version,
>>it is that latest version which the developer will be moving on
>>to future levels, and for which they want the feedback.
>>
>>An exception, of course, should be made for cases where the
>>defect you find has already been acknowledged by the developer
>>and anything stronger than "this affects me too" might be noise.
>>
>>Again, this is a political rather than a technical tactic.
>>You make their life easier and they will have more time to
>>make your life easier. There are situations where you may
>>prefer to pay a developer large amounts of money to support
>>old versions, but those are rare.
>>
>>Larry Kilgallen
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 15:13:36 GMT
>>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>>Subject: Re: CRC in Ada?
>>
>>In article <dewar.858095506@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
>>writes:
>>
>> > That's a pretty marginal optimization. Maybe Geert makes subtypes
>> > Positive_Float, but of all the code we ever had submitted to us,
>> > no one ever bothered to do this, they just used Float.
>>
>> > Still it can go on the list, it's way down there in priority though,
>> > there are MANY more important optimizations ahead of it!
>>
>> Let me put an optimization way ahead of it on the list and see if
>>anyone is interested...
>>
>> The easiest way of dealing with the A.5.1(37-42) requirements in a
>>portable manner is the one currently taken by GNAT--explicit code.
>>However, most of these requirements will be met by any IEEE conforming
>>implementation. So it should be possible to have two versions of the
>>elementary functions packages, one which assumes good underlying math
>>libraries, and one which does not.
>>
>> Note that the hard work here can be done completely separately from
>>other compiler maintenance and enhancement activities. It involves
>>writing some test code and running it on a lot of different
>>platforms. (The way I envision this is a set of alternate bodies, and
>>a test program which validates the elisions. Of course, the ultimate
>>would be a test program that generated a tailored version of the
>>bodies which matched the particular hardware.)
>>
>>
>>--
>>
>> Robert I. Eachus
>>
>>with Standard_Disclaimer;
>>use Standard_Disclaimer;
>>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 16:00:14 GMT
>>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>>Subject: Re: Random Numbers
>>
>>In article <dewar.858098083@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
>>writes:
>>
>> > Don't worry, Robert Eachus is a fanatic here (he wrote the random number
>> > generator) :-)
>>
>> A fanatic? A FANATIC? You dare to call ME a FANATIC on the subject?
>>
>> Well, maybe. ;-)
>>
>> > The orignal question came from a student writing a simple card playing
>> > program, and I think you will find that the random number routines
>> > are quite fine for this purpose!
>>
>> Oh, they are probably fine for this purpose, even if not used
>>correctly. But I would hope that a student would think about the
>>issues involved, even if the final decision was to ignore them.
>>Learning software engineering involves both learning to recognize the
>>issues, and learning to decide which potential problems can be ignored
>>in the case at hand.
>>
>> For example, my daughter had a similar assignment involving robots
>>moving one of eight directions in a limited field. Her action if the
>>random next move was outside the field was to make a recursive call if
>>the direction chosen would take the robot out of the field. Nice
>>properties from a bias point of view, but... Her answer to the worst
>>case scenario was to put in a comment indicating that the risk of
>>stack overflow had been considered and deemed acceptable in this
>>environment.
>>
>> If I was the instructor who handed out either problem, I'd care
>>whether students were aware of the issues, not whether they wrote
>>perfect code for dealing with all the possibilities. (The card
>>dealing problem is easy to handle, especially if the game is poker or
>>blackjack. In the robot problem, there is a nasty tradeoff between
>>required stack size and bias. You set one value and it determines the
>>other. Having three generators is a different approach, but now you
>>have to insure that they are truly independent.)
>>
>> More than you probably wanted to know, but as Robert said, I am
>>somewhat of a fanatic on the subject. I've never personally gotten
>>burned by a bad PRNG, or misuse of one, but I know several people who
>>have. Withdrawing published papers is no fun, as happened to a friend
>>of mine who used RANDU. Even worse was one case where the engineer
>>involved had to go to the NRC and say the nuclear reactor wasn't as
>>safe as they thought. (In fact I don't think the Diablo Canyon
>>reactor was ever operated. By the time they fixed the problems that
>>the wrong simulation had missed, new earthquake faults were found
>>running directly under the reactor.)
>>
>>--
>>
>> Robert I. Eachus
>>
>>with Standard_Disclaimer;
>>use Standard_Disclaimer;
>>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 10:02:30 -0800
>>From: Ken Garlington <GarlingtonKE@LMTAS.LMCO.COM>
>>Subject: Re: Please do not start a language war (was Re: Papers on the
>>Ariane-5
>> crash and Design by Contract
>>
>>Jean-Marc Jezequel wrote:
>>>
>>> In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington
>><GarlingtonKE@lmtas.lmco.com> writes:
>>>
>>> > 2. No one ran a full integration test with realistic flight data,
>>> >which would have
>>> > alerted them to the mistake made in #1. Particularly for a
>>> >distributed mission-
>>> > critical system, this should be considered an absolute
>>> >requirement.
>>>
>>> Yes, this is true. But you have to understand that the mere design of the
>>>SRI
>>> made it very difficult to test it in an other way that performing a
>>>launch.
>>> This is because of the tight integration of hard-to-fool hardware with
>>software
>>> in a black box functional unit.
>>
>>We have exactly the same coupling of inertials to flight controls on a
>>current project, and
>>we are able to test the coupled system in a black box environment in our
>>labs, with pilots in the loop, performing the same flight profiles we
>>expect to see in operation.
>>
>>Interestingly enough, the IRS for the this project is also "reused" from
>>a different platform, and there was a proposal to minimize testing of
>>the system because it had already
>>been "proven." We were able to quash that "cost-savings" measure before
>>it gained much
>>support. However, in an environment with Cost As an Independent Variable
>>(CAIV), I can
>>certainly see how easy it would be to adopt such ideas.
>>
>>> What can be your test strategy for a black box
>>> containing an inertial central? If the software had been designed with
>>>less
>>coupling
>>> on this particular hardware, you could have test the software vs. a
>>simulation of the
>>> hardware and its environment. Here, the launch was the test.
>>
>>Is this what Aerospatiale told you?
>>
>>>
>>> >Although I like some of Mr. Meyer's columns, I found this particular
>>> >column not only wrong,
>>> >but dangerous, since it continues the trend of denigrating sound test
>>> >strategy and common
>>> >sense system engineering in favor of a software-centric approach.
>>>
>>> I don't see where it denigrates sound testing. IMHO, sound testing *is*
>>needed.
>>> And testing is effective only if you have a sound test strategy.
>>> Even more when you use programming by contract. In the paper,
>>> we just recall that you cannot rely on tests only.
>>
>>Then why in your message on comp.lang.ada, did you say that to a "lesser
>>extent"
>>this was an integration test problem? Not doing this testing was a
>>*critical*
>>part of the problem!
>>
>>Although I think programming by contract is worthwhile, I still contend
>>that there
>>is no compelling reason to believe it would have avoided *this
>>particular problem*, for
>>two reasons:
>>
>>1. There is strong evidence to believe that the Ariane IV SRI team did
>>not see this
>> as a particularly important assertion to make (otherwise, they would
>>not have
>> suppressed the check). In the context of what they knew (the Ariane
>>IV flight
>> profile), their opinion was at least understandable if not
>>justifiable.
>>
>>2. There is some evidence to indicate that the Ariane V team would not
>>have considered
>> themselves in violation of the assertion, even if it had been
>>explictly coded. Apparently,
>> they did not challenge the decision of the Ariane IV team to suppress
>>the exception
>> checks for the unit. Based on my experience in similar situations, it
>>is sometimes
>> difficult to translate such high-level information as a flight
>>profile to the specific
>> range of parameters to be passed to a particular unit. Additionally,
>>there is no
>> evidence that the software team, reading the source code, had
>>sufficient systems
>> knowledge and experience to detect the violation of the assertion
>>strictly from reading
>> the code.
>>
>>Based on my experience with aerospace systems, and in particular
>>integrated inertial and
>>flight control systems (from the flight controls side), I see this
>>scenario as entirely
>>possible. In this case, no amount of documentation at the code level
>>would have solved
>>the problem, and no amount of embedded run-time checks would solve the
>>problem in the
>>absence of realistic testing.
>>>
>>> --
>>> Jean-Marc Jezequel Tel : +33 2 99847192
>>> IRISA/CNRS Fax : +33 2 99847171
>>> Campus de Beaulieu e-mail : jezequel@irisa.fr
>>> F-35042 RENNES (FRANCE) http://www.irisa.fr/pampa/PROF/jmj.html
>>
>>--
>>LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
>>For job listings, other info: http://www.lmtas.com or
>>http://www.lmco.com
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 16:16:45 GMT
>>From: Fergus Henderson <fjh@MURLIBOBO.CS.MU.OZ.AU>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>rkaiser@dimensional.com (Richard Kaiser) writes:
>>
>>>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>>>using #include <assert.h> for years? Software engineers have been using
>>>assert macros to verify program limits are not exceeded.
>>
>>The major difference between C/C++/Ada assertions and Eiffel style
>>design-by-contract is that in the latter, the assertions are part of
>>the interface, not just embedded in the implementation.
>>
>>--
>>Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the
>>pursuit
>>WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
>>PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 14:53:35 GMT
>>From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>>Subject: Re: floating point problem
>>
>>In article <dewar.858142750@merv>, dewar@merv.cs.nyu.edu (Robert Dewar)
>>writes:
>>> Larry asks
>>>
>>> <<So can anyone give an example for the Intel-challenged regarding how
>>> one would easily detect this float-challenged hardware at runtime in
>>> order to issue a nastygram ?>>
>>>
>>> The proper code is a little delicate, but is documented in the relevant
>>> Intel microprocessor manuals. Note that all DX chips, and of course all
>>> Pentiums have built-in floating-point, so this is really only a concern
>>> with ancient machines that you cannot purchase any longer.
>>
>>So I would gather one cannot do this test from Ada.
>>
>>As to machine models affected, my concern is that when my program is
>>put onto the wrong machine (regardless of any documentation I might
>>provide) an unambiguous message regarding the nature of the problem
>>is issued to the naive user. Support calls cost money.
>>
>>Larry Kilgallen
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 21:16:55 GMT
>>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>>Subject: Re: Ariane-5: can you clarify? (Re: Please do not start a language
>>war)
>>
>>In article <01bc3389$46204f70$b280400a@gavinspc> "Gavin Collings"
>><gcollings@sperry-sun.com> writes:
>>
>>> (2) To treat the software as intrinsically more reliable than the
>>> hardware seems to go against all experience and indeed against
>>> common sense.
>>
>>Truer words have never been spoken or written in software circles.
>>This should be framed and required to be hung on the wall in all such
>>circles.
>>
>>
>>/Jon
>>--
>>Jon Anthony
>>Organon Motives, Inc.
>>Belmont, MA 02178
>>617.484.3383
>>jsa@organon.com
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 12:41:01 +0000
>>From: Nick Leaton <nickle@CALFP.CO.UK>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>Richard Kaiser wrote:
>>
>>> The first mistake was to not put the time limit in some human readable
>>> documentation, or if the time limit was documenting then it was not read.
>>> Writing code so it documents itself reduces or eliminates the code
>>> documentation, but this can be done in Ada, EIffel, C, C++ and even
>>> assembly language and FORTRAN. These limits are part of the design
>>> and belong in a Software Requirements/Requirements Verification document
>>> and in the Version Description Document. And these documents must be
>>> reviewed prior to reuse.
>>
>>The difference between writting comments that document code, and
>>writting assertions is simple. The assertions will get tested, your
>>comments will not. I prefer to trust the latter
>>
>>> >2) Design. Writting assertions makes design easier. This is a personal
>>> >observation and harder to justify. I find being clear about what
>>> >something does helps clear up what I am doing. Having complex
>>> >preconditions is not a good idea, again you probably don't have the
>>> >right structure.
>>>
>>> The code is going to say "I am not in my original application and may or
>>> will fail?" Assertions are only going to catch problems if there is:
>>>
>>
>>No, the code does what it is contracted to do. If you break the
>>contract, it raises an exception.
>>
>>--
>>
>>Nick
>>
>>------------------------------
>>
>>Date: Fri, 14 Mar 1997 14:03:57 -0700
>>From: Akihito Tanaka <tanaka@CS.BUY.EDU>
>>Subject: need free compiler
>>
>>I am college student and looking for free ada compiler on the web. My
>>prof told me to research on ada language and write a code in ada. If
>>you know the sites please tell me.
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 10:15:57 -0800
>>From: Ken Garlington <GarlingtonKE@LMTAS.LMCO.COM>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>Thomas wrote:
>>>
>>> Well, what if a lot more money had been budgeted for hardware? Could
>>> the space agency have paid the processor manufacturers to come out
>>> with a version that was 30% faster (that should have been sufficient
>>> to use runtime checks everywhere without changing the design)?
>>
>>Some problems with doing that:
>>
>>1. New designs add risk, since there's not a history of use.
>>2. Faster usually means more power/cooling required, which reduces
>>payload.
>>3. Processor manufacturers charge more for small production runs, which
>> cuts into the profit margin. Remember that hardware is a recurring
>> cost; software (in the absence of maintenance) isn't.
>>
>>> Another option could have been to add more individual processors and
>>> use them in parallel (almost certainly harder than it sounds, but
>>> still a possibility).
>>
>>1. Adds weight, power and cooling requirements (reducing payload).
>>2. Costs more (more parts)
>>3. Adds complexity to the design, and thus risk.
>>
>>> Or what about choosing a less ambitious flight
>>> trajectory and maybe lower payload so that control required less
>>> computation?
>>
>>Would have made the Ariane V less competitive, and possibly non-viable.
>>
>>> Of course, none of those would have been easy choices to make. Design
>>> by contract and other methodologies are useful, but I still think
>>> without a solid foundation of runtime checks in the production code
>>> and multiple exception handlers and recovery blocks, no methodology
>>> alone is going to give sufficient protection from failure. In fact,
>>> Eiffel itself, which has been mentioned here because of its assertion
>>> system, is built on a foundation of runtime safety.
>>
>>However, runtime safety doesn't do much good if either/or (a) you test
>>on the ground to see what exceptions are raised; (b) you know how to
>>correct from the exception (in some cases, there IS no good response
>>to certain exceptions).
>>
>>
>>--
>>LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
>>For job listings, other info: http://www.lmtas.com or
>>http://www.lmco.com
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 11:04:14 -0600
>>From: Robert Oeckl <oeckl@PHENO.PHYSICS.WISC.EDU>
>>Subject: numerical libraries
>>
>>I am looking for an Ada95 (or Ada83 if no compatiblity problems arise)
>>numerics library and am specifically interested in the following
>>capabilities:
>>
>>- special functions: specifically the Exponential Integral function and
>> related functions
>>
>>- high accuracy floating point types: I am looking for accuracies of
>> let's say 20 or 25 decimal digits. Best would be (almost) arbitrary
>> accuracy
>>
>>- routines to calculate definite integrals
>>
>>I would greatly appreciate any help.
>>
>>Thanks in advance,
>>Robert
>>
>>------------------------------------
>>
>>Robert Oeckl, graduate student
>>University of Wisconsin
>>Department of Physics
>>1150 University Avenue
>>Madison WI 53706-1390, USA
>>
>>phone: +1 (608) 262-8947
>>e-mail: oeckl@pheno.physics.wisc.edu
>>
>>------------------------------
>>
>>End of INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>>*******************************************************************
>>
>
>------------------------------
>
>End of INFO-ADA Digest - 19 Mar 1997 - Special issue
>****************************************************
>
reply other threads:[~1997-03-19 0:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox