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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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-24 02:59:33 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!newsfeed.media.kyoto-u.ac.jp!newsfeed.icl.net!newsfeed.fjserv.net!proxad.net!213.200.89.82.MISMATCH!tiscali!newsfeed1.ip.tiscali.net!feed.news.nacamar.de!fu-berlin.de!uni-berlin.de!adsl-213-200-246-247.cybernet.CH!not-for-mail From: Vinzent Hoefler Newsgroups: comp.lang.ada Subject: Re: Ariane5 FAQ Date: Thu, 24 Jul 2003 11:57:24 +0200 Organization: JeLlyFish software Message-ID: References: <1058810510.375902@master.nyc.kbcfp.com> <1058813341.841940@master.nyc.kbcfp.com> <1058816605.566685@master.nyc.kbcfp.com> <1058969472.350716@master.nyc.kbcfp.com> <1058982513.114816@master.nyc.kbcfp.com> Reply-To: v.hoefler@acm.org NNTP-Posting-Host: adsl-213-200-246-247.cybernet.ch (213.200.246.247) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: news.uni-berlin.de 1059040771 17499297 213.200.246.247 (16 [175126]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40757 Date: 2003-07-24T11:57:24+02:00 List-Id: Hyman Rosen wrote: >Vinzent Hoefler wrote: >> I don't see, how someone can avoid such problem. > >By having lots of meetings, and coming up with a >definite specification for what to do. The result >will be some hard numbers - if the reading is less >than this, it's good, otherwise it's suspect. It is supect. And what to do, if you *suspect* a wrong value? Pop up a window and let a human operator confirm, everything is still good? Please also take limited CPU-time into your considerations. >Then >the code is written to implement the decision. I got code here that controls a DAC and the maximum value is (of course) 255. I *know* that this will never be reached in real world cases, so if someone comes up with the 255 or even larger it *must* be wrong. But to decide when exactly a particular value is really wrong or not is indefinitely harder to make. There is a gray area and you really don't want to implement some fuzzy logic in such CPUs. >It's also perfectly valid to say "go ahead and write >this code as if this variable will never exceed this >value". Yes. But you should ask, what are the results of the rest of the code, if it exceeds the limit? They don't make sense anymore. >Now, often that arbitrary way will in retrospect be >exactly what you wanted, while the range check could >cause an entire abort, so it's not a given which >approach to use. You don't understand. If the DAC value overflows, I definitely *don't* want to calculate with a modulo value, because this is absolutely wrong. Definitely. But the calculation will be still *correct* with 255, even if it *might* make not much /sense/ in real world. >In the Ariane 5 case, it turned out >that this approach caused an unhappy outcome. Well, and in my case I almost got a screwed up machine, because another value underflowed below zero, this underflow was not catched, and so the result was interpreted as very large unsigned value later then in the embedded system, because negative values can be considered plainly impossible there. And you know what? Under certain other circumstance such a large value could have made sense. Vinzent.