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-Thread: 103376,699cc914522aa7c4
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!uns-out.usenetserver.com!news.usenetserver.com!pc02.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Structured exception information
References: <eog0g5$2bn$1@cernne03.cern.ch> <u7ivnp09z.fsf@stephe-leake.org>
  <eoinoh$855$1@cernne03.cern.ch> <ud55drgzz.fsf@stephe-leake.org>
  <eolaen$b4h$1@cernne03.cern.ch> <ur6trwdov.fsf@stephe-leake.org>
  <5e0owbs5cgtv$.kyfgnvskadxd.dlg@40tude.net>
  <uejppyc2g.fsf@stephe-leake.org>
  <6rw4k9rlnssv.1lwvk86ldjblo.dlg@40tude.net>
  <ufya2dwxf.fsf@stephe-leake.org>
  <whjok6zzdisu.t6spc9vchgp3.dlg@40tude.net>
From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Wed, 24 Jan 2007 21:39:59 -0500
Message-ID: <uodonbzi8.fsf@stephe-leake.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt)
Cancel-Lock: sha1:kJJbJBjsZE0SEGq1Ii2Q3dBA/1g=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: 63b6e45b81888759e00d415979
Xref: g2news2.google.com comp.lang.ada:8530
Date: 2007-01-24T21:39:59-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> Basically, the result of any sensor read is a record:
>> 
>> type Sensor_Result_Type is record
>>     Quality : Quality_Type;
>>     Value   : Value_Type;
>> end record;
>> 
>> Any algorithm that deals with the sensor must be prepared for Quality
>> to be Bad.
>
> I don't think so. From a system-wide perspective, yes, sure, but locally I
> have a problem with that. Let's consider:
>
>    function "+" (X, Y : Sensor_Result_Type) return Value_Type;
>
> We have to discard this on the same reasons (if we had accepted them (:-))
> and replace it with:
>
>    function "+" (X, Y : Sensor_Result_Type) return Sensor_Result_Type;
>
> Now, before we would rush into developing a home-brewed IEEE arithmetic.
> May I ask you, how Quality_Type compose under "+"? I know what 1+2 is, but
> what is (1, Try_Again) + (2, Change_Battery)?
>
> (2, First_Change_Then_Try)? (:-))

Obviously, a system that is prepared to deal with failing sensors has
to define what to do in this situation.

It is not typical to define "+" for a sensor quality like this, which
has only a few values. The quality would be considered at the top
level, with a case statement.

On the other hand, some sensors (for example star trackers) have a
floating point quality, which can be used in a Kalman filter to arrive
at a correctly balanced result. In that case, defining "+" probably
makes sense.

-- 
-- Stephe