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-23 08:10:16 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!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: Wed, 23 Jul 2003 17:08:07 +0200 Organization: JeLlyFish software Message-ID: References: <1058799152.775376@master.nyc.kbcfp.com> <1058810510.375902@master.nyc.kbcfp.com> <1058813341.841940@master.nyc.kbcfp.com> <1058816605.566685@master.nyc.kbcfp.com> <1058969472.350716@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 1058973014 17316494 213.200.246.247 (16 [175126]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40710 Date: 2003-07-23T17:08:07+02:00 List-Id: Hyman Rosen wrote: >If the value of the parameter had exceeded the Ariane 4 maximum but >was less than the 16-bit maximum, there would have been no exception >at all at the conversion point, and the too-high value would have >gone through the rest of the system, doing something else. It would have handled that value as correct reading from the sensor. I don't see, how someone can avoid such problem. I mean, if, for instance, I read an indoor-temperature sensor, it might be reasonable to assume, that the read value will always be below 128 degrees (Celsius) if the sensor is working, so that I can use a 8-bit-value to store the reading. Now what, if we want to protect against a possible overflow? How would you handle that? Personally I think, just reading the value and calculating with it, even if the reading says 95 degrees is a quite reasonable decision. And it is also a very reasonable decision to say: If *that* reading overflows my 8 bits within I can handle it, *then* the sensor must definitely be broken. The room cannot get that warm. [Except in case of fire perhaps... ;)]. So even if you specify an arbitrary lower limit (let's say, 60 degrees Celsius) as reasonable maximum reading, you will *always* get some sort of grey range, where you cannot really tell if the sensor is broken or its reading is indeed correct. So what do you do, if you set the reasonable limit to 60 and you read 59? Assume that the value read is ok or already assume that the sensor must be broken? What, if you then lower this "reasonable" limit accordingly? Another example: If I count the flying time of an aircraft in a 32 Bit value in seconds, I can tell with a very high probability, if that counter overflows it *must* be an error, because no plane would be able to fly 130+ years in a single session. But the decision for a certain point when a particular flying time (24 hours?, 48 hours?, three weeks?) makes sense or not is indefinitely harder to make. Vinzent. --=20 Parents strongly cautioned -- this posting is intended for mature audiences over 18. It may contain some material that many parents would not find suitable for children and may include intense violence, sexual situations, coarse language and suggestive dialogue.