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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 107d55,a48e5b99425d742a X-Google-Attributes: gid107d55,public X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public From: ae59@rz.uni-karlsruhe.de Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/21 Message-ID: <5gtf8v$bjq$1@nz12.rz.uni-karlsruhe.de>#1/1 X-Deja-AN: 227217803 References: <332B5495.167EB0E7@eiffel.com> Organization: University of Karlsruhe Reply-To: Heiner.Berlejung@math.uni-karlsruhe.de Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada,comp.lang.java.tech Date: 1997-03-21T00:00:00+00:00 List-Id: In , nouser@nohost.nodomain (Thomas) writes: >In article <33308069.3279956@news.demon.co.uk> john@assen.demon.co.uk (John McCabe) writes: >Well, with a more powerful CPU, it might have been possible to use >floating point arithmetic throught the system and implement algorithms >that were valid over the whole physically meaningful ranges of >parameters, not just those actually encountered by Ariane 4. Didn't say J. v. Neumann that he would never use an aeroplane that was constructed using floating -points calculation ? > >Or, to put that in the context of the paper we are discussing, >even better than to declare and manage arbitrary restrictions >on a reusable piece of code is to avoid them in the first place. > >I have implemented a number of signal processing algorithms both using >small integer and floating point arithmetic. The floating point >versions were not only much easier to develop, they also were >considerably more robust. That is true even if both the inputs Sounds interesting for me. Why is this the case? How did you handle rounding errors and states of your FPU (or software model), which needs a proper error analysis. You will also need to have an exception handler, won't you. >and outputs of the system are actually small integers (as they >usually are when it comes to sensors and effectors). On low-end >hardware, the floating point versions are, of course, somewhat >slower (on modern RISCs there is often no difference). In the case of interval computations using floating-point I would totally agree, but interval computations would double the number of floating-point operations. I think the problem here is that _after_ a crash it is pretty simple to say that this or that assertion would have avoided it, but how to formulate them before s.th. has happend? Ciao Heiner ------------- URL http://www.uni-karlsruhe.de/~ae59 --------------------- Heinrich Berlejung |Institut f. Angewandte Mathematik Tel.:+49 721 377936 / Fax:+49 721 385979 |P.O. Box 6980,D-76128 Karlsruhe Mail:Heiner.Berlejung@math.uni-karlsruhe.de|Universitaet Karlsruhe (TH)