Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
The reliability of programs, regarding them as specific mechanisms, and the importance of understanding their structure for effective comparison. The author discusses the concept of 'taking the structure of the mechanism into account' and the need for systematic sequencing to reflect the structure of computations. The document also touches upon the difficulty of comparing programs with different sequencing and the importance of careful program structuring for modifications and adaptations.
Typology: Exams
1 / 83
This page cannot be seen from the preview
Don't miss anything!
Prof.dr. Edsger W. Dijkstra T.H.-Report 70-WSK- Second edition April 1970
prof. dr. Edsger W. Dijkstra
Table of con tents. O To^ my^ reader. On (^) our inability to do much. 4 On^ the^ reliability^ of^ mechan isms. 8 On^ our mental aids. 15 An^ example of a correctness proof. 19 On^ the validity of proofs versus the validity of implementations. 21 On (^) understanding programs. 30 On comparing programs. 35 A first example of step—wise program composition. 50 On program families.
57 On a program model.
75 Dn what we have achieved. 80 On grouping and sequencing.
I
I am faced with a basic problem of presentation. What I am really concerned about is the composition of large programs, the text of which may be, say, of the same size as the whole text of this booklet. Also I have to include examples to illustrate the various techniques. For practical reasons, the demonstration programs must be small, many times smaller than the "life—size programs" I have in mind. My basic problem is that precisely this difference in scale is one of the major sources of our difficulties in programming:
Let me give you two examples to rub this in. A one—year old child will crawl on all fours with a speed of, say, one mile per hour. But a speed of a thousand miles per hour is that of a supersonic jet. Considered as objects with moving ability the child and the jet are incomparable, far whatever one can do the other cannot and vice versa. Also: one can close one 's eyes and imagine how it feels to be standing in an open place, a prairie or a sea shore, while far away a big , rein less horse is approaching at a gallop, one can "see" it approaching and passing. To do the same with a phalanx of a thousand of these big beasts is mentally im— possible : your heart would miss a number of beats by pure panic, if you could!
To start with, we have the It^ size" of the computation, i.e. the amount of information and the number of operations involved in it. It is essential that this size -L e^ large, for if it were really small, it would be easier not to use the computer at all and to do it by hand. The automatic computer owes it right to exist, its usefulness, precisely to its ability to perform large computations whe-—e we humans cannot. We want the computer to do what we could never do ourselves and the power of present—day machinery is such that even small computations are by their very size already far beyond the powers of our unaided imagination. Yet we must organize the computations in such a way that our limited powers are sufficient to guarantee that the computation will establish the desired effect. This organizing includes the composition of the program and here we are faced with the next problem of size, viz. the length of the program text, and we should give this problem also explicit recognition. We should remain aware of the fact that the extent to which we can read or write a text is very much dependent on its size. In my country the entries in the telephone directory are grouped by town or village and within each such group the subscribers are listed by name in alphabstical order. I myself live in a small village and given a telephone number have only to scar a few columns to find out to whom the telephone number belongs, but to do the same in a large city would be a major data processing task!
used. Summarizing: as a slow—witted hurrar being I have a very small hsad and I had better learn to live with it and to respect my limitations and give them füll credit, rather than to try to ignore them, far the latter vain effort will be punished by failure.
performed correctly. So much for the justification of our desire far a correct multiplier. But haw is the correctness established in a convincing manner? As long as the multiplier is considered as a black box, the only thing we can do is "testing by sampling" , -i ; e. offering to the multiplier a feasible amount of factor pairs and checking the result. But in view of the 10 000 years, it is clear that we can only test a negligeable fraction of the possible multiplications. Whole classes of in some ser-toe "critical n joultiplications may remain untested and in view of the reliability just, Ly desired, our quality control is still most unsatisfactory. Therefore it is not clone that way. The St,raightforward conclusion is the following: a convincing demonstration of correctness being impossible as long as the mechanism ig regarded as a black box, our only hope lies in not regarding the mechanism as a black box. I shall call this "taking the structure of the mechanism into account" From now onwards the type of mechanisms we are going to deal with are programs. (In many respects, programs are mechanisms much easier to deal with than circuitry. which is really an analogue device and subject to wear and tear. ) And also with programs it is fairly hopeless to establish the correctness beyond even the mildest doubt by testing without taking their structure into account. In other words, we remark that the extent to which the program correctness can be established is not purely a function of the program's external specifications and behaviour but depends critically upon its internal structure. Recalling that OUI' true concern is with really large programs, we observe as an aside that the size ituelf requires a high confidence level for the individual program components. If the chance of correctness of an individual component, equals
p, the charnco of correctnest; of a whole program, composed D f such componentc;, something like p As will be very large, p should be very, very close to I if we desire P to differ significantly from zero: When we now take the position that it is not only the programmer t^ s task to produce a correct program but also ta demonstrate its correctness in a convincing manner, then the above remarks have a profound influence on the programmer's activity: the object he has to produce must be usefully structured. The remaining part of' this monograph will mainly be an exploration D f what program structure can be used to goad advantage. In what follows it will become apparent
EWD249 - 5 that program correctness is not my only concern, program adaptability or rnanageability will be another. This stress on program manageability is my deliberate choice, a choice that, therefore, I Should like to justify. While in the past the growth in power of the generally available equiprnent has mitigated the urgency of the efficiency requirements, this very same growth has created if,s new difficulties. Once one has a powerful machine at one 's; disposal one tries to use it and the size of the problems one tackles adjusts itself to the scope of the qui proem t: na one thinks about programming an algorithm that would take twenty years to execute. With processing power increased by a factor of a thousand aver the mast ten to fifteen years, Man has become considerably more ambitious in selecting problems that now should be "technically feasible". Size, complexity and sophistication of programs one should like ta make have exploded and over the past years it has become patently clear that on the whole our programming ability has not kept pace with these exploding demands made on it. The power of available equipment will continue to grow: we can expect manufacturers to develop still faster machines and even without that development we shall witness that the type of machine that is presently considered as except— Ional Iy fast will become with these machines will
more and common. The things we should like to do grow in proportion and it is on this extrapolation that of the programmer 1 5 task. My conclusion is that it is becoming most urgent to stop to consider programming primarily as the minimization of a cost/performance ratio. We should recognize that already now programming is much more an intellectual challenge: the art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.
In the previous section we have stated that the programmer 's duty is to make his product "usefully structured" and we mentioned the program structure in con— nectian with a convincing demonstration of the correctness of the program, But how do we convince? And haw do we convince ourselves? What are the typical patterns of thought enabling OUTSeIves to understand? It is to a broad survey of such questions that the current section is devoted. It is written with my sincerest apologies to the professional psychologist, because it will be amateurishly superficial. Yet I hope (and trust) that it will be sufficient to give us a yardstick by which to measure the usefulness Q f a proposed structuring. Among the mental aids available to understand a program (or a proof of its correctness) there are three that I should like to mention explicitly: l ) Enumeration
operating on the variables and "dd" leaves the relations O < r < dd invariant. One juts t t^! follows" the little piece of program assuming that (1 ) is satisfied to start with. After the execution of the first staternent, which halves
the value of dd, but leaves unchanged, the relations O < r < 2 * dd (2) will hold. Now we distinguish two mutually exclusive cases.
EWD249 - 8 l ) dd < Together with (2) this leads to the relations
In this case the statement following do will be executed, ordering a decrease of r by dd, so that from (3) it fallows that eventually O < < dd
do' dd2 ' d3 (l )
'for 1 — d - D for i
the relation d d (3)
prop(d ) (4) and non prop(d. ) for ail satisfying O < i < k We now consider the following program part:
EWD249 - 10 so that the net effect of the N+I st execution of the repeated statement established the relation d
i.e. relation (7 a) for N N + I and thus theinduction step (7) has been proved. Now we uhall show that the repetition terminates after tho k—th execution of the repeated statement. The n —th execution cannot take place for ro > k for ora account of 7b) this would imply non prop(d ) thereby violating When the repetition terminates after the n—th execution of the repeated statement, the necessary and sufficient condition for termination, viz. non prop(d) ) becomes, thanks to (7 a) prop(d ) (8) This excludes termination for n < k, as this would violate (5). As a result the repetition will terminate with n k, so that (3) fallows from (4) follows from (8) and (5) follows from (7b). Which terminates our proof. Before turning our attention away from this example illustrating the use of mathematical induction as a pattern of reasoning, I should like to add some remarks, because I have the uneasy feeling that by now some of rny readers —in particular experienced and competent programrners— will be terribly irritated, viz. those
Of course I WOUId not dare to suggest (at least at present:) that it is the programmer t^ s duty to supply such a proof whenever he writes a simple loop in his program. If so, he could never write a program of any size at al 12 It would ba as impractical as reducing each proof in plane geometry explicitly and in extenso to Euclid's axioms. (Cf. Section '1 0m our inability to do much.
familiar, while becornirnq very alert and careful whenever he constructs something unusual (for him). For an established style of programming, however, it might be a useful activity to look far a body of theorems pertinent to such programs.
EWD249 - 13 using a theorem regardless of how it has been proved. Even if its proof is highly intricate, it may be a very convenient theorem to use!
Here Mike Woodger, P'åational Physical Laboratory, Teddington, England, made the following remark, which I insert in gratitude: "There is a parallel analogy between the unanalyzed terms in which an axiom or theorem is expressed and the unanalyzed operands upon which a named operation is expec±ed to act
An example of a correctness proof.
end " To apply the Linear Search Theorem see Section "Dn our mental aids" sub— section "On mathematical inductionwe consider the sequence of values given by far dd. d for i > O dd n from which dd n (l^ ) can be derived by normal mathematical techniques, d > O) for finite r
which also tell us that (because
with dd
d
and the Linear Search Theorem then tells us, that the second repetition will also terminate. (As a matter of fact the second repeated statement will be executed exactly the same number of times as the first one.
— dd (^) / (^) 2;
assigns to q the value of the corresponding quotient. The proof can be established by observing the invariance of the relation
(I owe this example to my colleague N.G.de Bruijn.
one has to show that S is such that the truth of
prior to the execution of S implies the truth of
Remark As an exercise (for which acknowledgement is due to James King, CMU, Pittsburgh, USA) for the reader, prove that with integer A, B, x, y and z and A > O and B > O after the execution of the program section
EWD249 - while y O do begin if odd(y) do begin
