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: a07f3367d7,b6d862eabdeb1fc4 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.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: <82pr06yvqu.fsf@stephe-leake.org> Date: Sat, 5 Jun 2010 10:00:07 +0200 Message-ID: <7sxhe3ad80de$.5yvimcxk9vjb.dlg@40tude.net> NNTP-Posting-Date: 05 Jun 2010 10:00:07 CEST NNTP-Posting-Host: 3476b94a.newsspool1.arcor-online.net X-Trace: DXC=NclY]ckgCSe]l@YUW5NBknic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgbRUbKm`amj0n[6LHn;2LCVn[f X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:11298 Date: 2010-06-05T10:00:07+02:00 List-Id: On Sat, 5 Jun 2010 06:13:59 +0000 (UTC), tmoran@acm.org wrote: >>> The technical problem is that mechanical components faults have a >>> stochastic nature. I.e. you have a certain probability of fault (due >>> to physical processes involved in production and function of the given >>> component). On the contrary, a software fault is not stochastic, >>> neither in its production nor at run-time. A given bug is either here >>> or not. >> >>Whether the bug is encountered is sometimes stochastic. But generally >>you are correct. > There are a set of bugs in a given piece of software. On any given > day, there's a certainly probability that's when you will stumble > across one. When you remove a bug you remove its probability component > so the total probability of going a day without a bug is now larger > (assuming any newly introduced bug is less likely than the removed one). > Bugs that are more likely to bite will be found and removed sooner, > so the rate of finding bugs will tend to drop. This is all describable > with simple probability and statistics. Yes, this is what I tried to describe in terms of program states. (Encounter bug = program transits an "error state") The problem with this 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. [You booted reliable Windows? That's your fault! (:-))] Another problem which worries me, is program changes. Let I modify the program, the result is *another* program. How can I talk about the "reliability" of what? Well, they share some code, but certainly we cannot consider source lines random. 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. > If you want to claim it's > "not stochastic" then I would claim neither is a physical fault - the > pressure applied today on the weak joint either is or is not sufficient > to cause a fracture, and metal fatigue weakening is a straightforward > physical process. Yes, one could say that physical components at some macro level have the nature of a discrete deterministic system, i.e. function like programs do. But the underlying processes and the process of "discretization" (pressure>X) are stochastic. Well, maybe the notion of reliability cannot be applied to complex physical system? But on the other hand, the more complex system is more random its behavior appears to the observer, looks like a paradox... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de