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-Thread: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Attributes: gid103376,gid1094ba,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!npeer.de.kpn-eurorings.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada vs Fortran for scientific applications Newsgroups: comp.lang.ada,comp.lang.fortran User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> <4e078qF1cb6frU1@individual.net> <4e0e21F1chamsU1@individual.net> <10qtgfusyium5.1fe6t8kirrzbf$.dlg@40tude.net> <4e0h2aF1ccvnqU1@individual.net> <1j8hpasemtm7n$.1l1wrnukz7ewf$.dlg@40tude.net> <4e29g8F1c5p6tU1@individual.net> Date: Tue, 30 May 2006 10:29:05 +0200 Message-ID: NNTP-Posting-Date: 30 May 2006 10:28:59 MEST NNTP-Posting-Host: 72835910.newsread4.arcor-online.net X-Trace: DXC=>hF1Gfn3N6bP8MgCCFiJ[l:ejgIfPPlddjW\KbG]kaMh]kI_X=5Keaffgmd^[B9Gia[6LHn;2LCVn[ On Tue, 30 May 2006 09:11:39 +0200, Jan Vorbr�ggen wrote: >> Ah, but an unforeseen error is a bug. One cannot be bug-tolerant, it is >> self-contradictory, after all. Programming error (bug) means that the >> system's state is not adequate to the physical system. Which could be the >> rocket falling right onto the control tower. But that's no matter, because >> there is no way for the program to know anything about that. Once you start >> to judge about such undesired program states (even purely statistically), >> and change the program, they automatically become *foreseen*. > > I don't consider that distinction helpful - it's like saying that economically > important algorithms are NP-complete and thus unsolveable, while experience > tells you that almost all practical problems turn out to be solveable with > polynomial algorithms or at least reach approximations to the optimal solution > that are economically indistinguishable. Good example. You cannot solve NP, but you can a practical [sub]problem. Exactly so, you cannot write a bug-tolerant program, but you can a fault-tolerant one. > It's similar to approaches people have in driving cars. On the one hand, you > can drive "defensively", i.e., you take into account that other participants > in traffic might not behave in an optimal way. Or you can drive agressively, > with the expactation that should somebody else suffer a momentary lapse of > concentration, say, you will have a crash. > > Incidentally, I consider "graceful degradation" the hallmark of good engi- > neering, and the Ariane 501 design was anything but that. The control system > of your body, on the other hand, is the best known example of a system showing > this property. I agree with this. But these aren't examples of bug-tolerant design. Service quality degradation is a result of a proper behavior of a system in response to some exceptional state. But all inputs are still valid, as well as the system state. So the human body can handle, say, outer temperature change. But it cannot handle electron mass as a temperature. That would be an "unforeseen" error, if God decided to swap both in the Universe. My point is that a false positive cannot be handled. When you calculate sin(0.5) actually meaning sin(0.1) there is nothing sine could do about it. It is not an error, it is a bug on your side. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de