From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f039470e8f537101 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-22 14:45:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.cs.utexas.edu!geraldo.cc.utexas.edu!not-for-mail From: "Bobby D. Bryant" Newsgroups: comp.lang.ada Subject: Re: Ariane5 FAQ Date: Tue, 22 Jul 2003 15:38:48 -0600 Organization: dis- Message-ID: References: <1058810510.375902@master.nyc.kbcfp.com> <1058813341.841940@master.nyc.kbcfp.com> <1058816605.566685@master.nyc.kbcfp.com> <20619edc.0307221029.47fe6d31@posting.google.com> <1058899826.878512@master.nyc.kbcfp.com> <20619edc.0307221247.30165bbf@posting.google.com> <1058908265.829369@master.nyc.kbcfp.com> NNTP-Posting-Host: dial-106-36.ots.utexas.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: geraldo.cc.utexas.edu 1058909974 1996 128.83.177.36 (22 Jul 2003 21:39:34 GMT) X-Complaints-To: abuse@utexas.edu NNTP-Posting-Date: Tue, 22 Jul 2003 21:39:34 +0000 (UTC) User-Agent: Pan/0.14.0 (I'm Being Nibbled to Death by Cats!) Xref: archiver1.google.com comp.lang.ada:40672 Date: 2003-07-22T15:38:48-06:00 List-Id: On Tue, 22 Jul 2003 17:11:05 -0400, Hyman Rosen wrote: > Mike Silva wrote: >> The behavior of the module over the entire possible range of inputs was >> neither random nor undefined. > > Sure it was. It entered what digital circuit designers call a "don't > care" state. The designers of the code didn't need to specify the > behavior above the Ariane 4 limit, and didn't. The code behaved in the > same arbitrary way that a C program does when presented with the same > sort of overflow. It happened to be running on a processor which faulted > on overflow, and so the overflow caused the subsequent events, but in no > way is that a designed property of the code. Actually it was -- if I understand the report correctly. CPU time was an issue, so they _deliberately_ left in some don't-care states for numbers not physically obtainable, rather than adding the small overhead of a check. But you are picking nits that fall far from your original objection to Alexandre's claim that "there were no reasons to expect that it should work for this new rocket". The simple fact is that the project completely skipped over the steps of asking whether it should be expected to work and then looking to see what the answer was. Merely assuming that software (or other rocket components) will work is neither sensible nor safe: you need good engineering to give you a _reason_ to expect it to work. -- Bobby Bryant Austin, Texas