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,PLING_QUERY, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b6d862eabdeb1fc4 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder2.cambriumusenet.nl!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!87.79.20.105.MISMATCH!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada noob here! Is Ada widely used? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <7sxhe3ad80de$.5yvimcxk9vjb.dlg@40tude.net> Date: Sat, 5 Jun 2010 21:59:58 +0200 Message-ID: <7ukoz32sn15r$.2j0eybb3m2s1.dlg@40tude.net> NNTP-Posting-Date: 05 Jun 2010 21:59:58 CEST NNTP-Posting-Host: c69030b3.newsspool4.arcor-online.net X-Trace: DXC=j>DLQBh5B0VV0Pe9PRnbJ\4IUK On Sat, 5 Jun 2010 17:59:36 +0000 (UTC), tmoran@acm.org wrote: >>is that it presumes that states are random, which are not, because [most >>of] programs are deterministic. Any randomness which might exist is derived >>from the inputs. I.e. it is the program usage, which makes the *same* >>program less or more reliable. According to this approach the most reliable >>car is one you do not drive. > Mechanical devices also fail due to unfortunate, unanticipated, > combinations of random inputs. Rockets don't fail in the middle of the > night sitting in the assembly building. They fail when, for instance, the > air temperature is very low and the rocket is on full thrust and with > those inputs the O-ring can't sufficiently do its job. You don't say > "O-rings are or are not reliable" - you say "under such and such > conditions O-rings are 99.9999% likely to prevent dangerous amounts of > leakage. Under such and such other inputs, that drops to 99.9%, > or 90%, or 10%." That is the difference. if you fixed the inputs/environment there still would be a probability of fault. A Maxwell's daemon sits inside each of these things deciding if he let you go or not. There is nothing in, say, integer addition. If you fixed the inputs it would either overflow or not. >> ... E.g. Let I modify 0,01% of the source of 90% >> "reliable" program. I can tell nothing about whether the result is 90% >> reliable +/- factor * 0.01%. This model just does not work. > The word "model" is key. It is meaningless to talk about whether > something, software or hardware, *is* stochastic - but one can observe > whether a stochastic *model* of the system is helpful or not. Hmm, I think a physicist would strongly disagree with that. AFAIK, there is no working deterministic models of quantum processes. > As to program changes, one talks about how confident you are that the > program will not hit a bug today, as compared to yesterday before you made > the change. Maybe, but 1. Confidence has nothing to do with probability. It is an absolutely different model of uncertainly. That returns us to the square one. Confidences and probabilities are incomparable. 2. Your confidence describes you, it does not the program. It fact, it is like - I give my word, it works. Fine, but why anybody should trust my word? > Your confidence will depend not just on the fraction of > source code changed, but also on careful consideration of the nature and > expected effects of the change, and observations while testing the changed > version. No, it will not, because you defined it as confidence. If there is something behind it, then why confidence? Name that thing, and define reliability in terms of that. The problem that there seems nothing there, except for confidences of other people. BTW, this is my concern about software certification procedures. It fact, they act quite as you suggested. They certify programmers, they don't the software. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de