Einführung in die Programmierung I Systema=sches Programmieren

Transkript

1 Einführung in die Programmierung I 10.0 Systema=sches Programmieren Thomas R. Gross Department Informa=k ETH Zürich Copyright (c) Pearson 2013 and Thomas Gross 2016 All rights reserved.

2 Uebersicht! 10.4 Pre/Post CondiDons für Loops 2

3 Analyse von Schleifen Bis jetzt waren die Programme einfach Sie hamen zwei EigenschaOen, die die Analyse sehr vereinfachten: 1. Wenn ein Programm ausgeführt wurde, dann wurde jede Anweisung keinmal oder einmal ausgeführt 2. (Daher) terminierte jedes Programm trivialerweise. 3

4 Diese beiden EigenschaOen treffen nicht zu wenn wir Schleifen (loops) haben (oder rekursive Methoden)! Wir betrachten nur einfache Schleifen! while-loops alle anderen Loops können durch diese ausgedrückt werden! MoDvaDon: Konzept der Invariante einzuführen! Geht über Pre/PostcondiDon hinaus! Auch in anderen SituaDonen sehr hilfreich, z.b. Objek6nvarianten die die Zustände eine Objektes characterizieren.! Wir blenden aus dass wir (auch) zeigen müssen dass eine Schleife terminiert (wir greifen diesen Aspekt später kurz auf) 4

5 Beispiel (informell) Was ist die Grundidee? Sehen wir uns einen Loop an: // assume: x >= 0 y = 0; i = 0; // // while(i!= x) { // i = i+1; // y = y+i; // } // // assert: y == sum(1,x) 6

6 // assume: x >= 0 y = 0; i = 0; // x >= 0 y == 0 i == 0 // invariant: y == sum(1,i) while(i!= x) { // y == sum(1,i) i!= x i = i+1; // y == sum(1,i-1) y = y+i; // y == sum(1,i-1)+i } // i==x y == sum(1,i) // assert: y == sum(1,x) 7

7 Beobachtungen! Um Aussagen über die Ausführung des Loops zu machen brauchen wir eine Invariante! Der Rumpf der Schleife könnte beliebig oo ausgeführt werden! Die PrecondiDon für die Schleife muss die Invariante implizieren! PrecondiDon muss stärker als (oder gleich stark wie) die Invariante sein 8

8 ! Invariante und der Schleifen Test (wenn er wahr ist) müssen stark genug sein um zu zeigen dass die PostcondiDon des Rumpfs auch die Invariante impliziert! Invariante und der Schleifen Test (wenn er falsch ist) müssen stark genug sein um die PostcondiDon der Schleife zu zeigen. 9

9 Hoare Logik! Gegeben sei ein Tripel für einen while-loop {P} while(b) S; {Q} Ein solches Tripel ist güldg wenn es eine Invariante I gibt so dass:! P => I Invariante gilt zu Beginn! {I B} S {I} Nach Ausführen des Rumpfes gilt die Invariante wieder! (I!B) Q Invariante (und Verlassen der Schleife, d.h test B ist false) impliziert PostcondiDon Q. 10

10 ! Für ein güldges Hoare Tripel einer Schleife {P} while(b) S; {Q} sind Schleifentest B, Schleifenrumpf S und die Schleifeninvariante I aufeinander abgesdmmt! S kann eine Folge von Anweisungen sein (auch geschachtelte Loops)! Für eine PostcondiDon Q gibt es (oo, manchmal) verschiedene Schleifen, die für die PrecondiDon P das selbe Result berechnen! Diese Schleifen haben dann andere Invarianten und Statements im Rumpf! DefiniDon allgemein genug, deckt auch den Fall ab dass der Rumpf keinmal durchlaufen wird 11

11 {P} while B S {Q} P => I Invariante gilt zu Beginn {I B} S {I} Nach Ausführen des Rumpfes gilt die Invariante wieder (I!B) => Q Invariante und Verlassen der Schleife impliziert Q. {x >= 0} y = 0; i = 0; {pre: x >= 0 y == 0 i == 0} {inv: y == sum(1,i)} while(i!= x) { i = i+1; y = y+i; } {post: i==x y == sum(1,i)} (also: y == sum(1,x)) 13

12 Ein anderer Loop (für das selbe Problem) Ein anderer Loop hat eine andere Invariante {x >= 0} y = 0; i = 1; {pre: x >= 0 y==0 i==1} {inv: y == sum(1,i-1)} while(i!= x+1) { y = y+i; i = i+1; } {post: i==x+1 y == sum(1,i-1)} (also: y == sum(1,x)) 14

13 Invarianten helfen Bugs zu finden Dieser Loop ist ähnlich aber macht nicht was wir wollen: {x >= 0} y = 0; i = 1; {pre: x >= 0 y==0 i==1} {inv: y == sum(1,i-1)} while(i!= x) { y = y+i; i = i+1; } {post: i==x y == sum(1,i-1)} (also: y == sum(1,x)) 15

14 Mehr Bugs! Dieser Loop enthält ein ungüldges Hoare Triple {x >= 0} y = 0; i = 0; {pre: x >= 0 y==0 i==0} {inv: y == sum(1,i)} while(i!= x) { y = y+i; i = i+1; // Invariante gilt nicht warum? } {post: i==x y == sum(1,i)} 16

15 Invarianten.! dürfen weder zu stark noch zu schwach sein! Wenn die Invariante zu stark ist, dann ist sie evtl. false! D.h. wir können nicht zeigen, dass sie zu Beginn güldg ist, oder! Die Invariante ist nicht wahr nachdem der Rumpf ausgeführt wurde! Wenn die Invariante zu schwach ist! Dann kann die PostcondiDon nach dem Verlassen des Loops evtl. nicht die PostcondiDon der Schleife implizieren! Und/oder es ist unmöglich zu zeigen dass die Invariante nach der Ausführung des Rumpfes (wieder) gilt 17

16 Invarianten nicht zu stark und nicht zu schwach! Das ist der Grund warum es keinen vollautomadschen Weg gibt, eine Loop Invariante zu konstruieren! Programmieren eine krea6ve TäDgkeit! Finden der Invariante erfordert nachdenken (oder manchmal raten )! OO zusammen mit dem Schreiben des Programms! Wenn es keinen Beweis gibt, dann muss entweder der Code, die Invariante, oder beides geändert werden.! Manchmal gibt es verschiedene Invarianten, die alle genügen (d.h. sind weder zu stark noch zu schwach), aber unterschiedlich 18 zweckmässig sind

17 Eine Methodologie! Hier ist ein Ansatz wie wir Schleife und Invarianten entwickeln können! Kein vollständiges Rezept! Nicht stur zu befolgen aber besser als der "schnelle" Weg, erst den Code zu entwickeln und dann die Invariante zu suchen. 19

18 ! [M]ethodology is the general research strategy that outlines the way in which research is to be undertaken and, among other things, idendfies the methods to be used in it.! [Wikipedia]! Computer science usage, in general "analysis of the body of methods and principles associated with a branch of knowledge" [dto] 20

19 Eine Methodologie! Hier ist ein Ansatz wie wir Schleife und Invarianten entwickeln können! Kein vollständiges Rezept! Nicht stur zu befolgen aber besser als der "schnelle" Weg, erst den Code zu entwickeln und dann die Invariante zu raten. 22

20 Eine Methodologie! Vorschlag (funkdoniert überraschenderweise oo): 1. BesDmmen Sie zuerst die Invariante und lassen Sie sie die anderen SchriMe leiten (!)! Wie bringt uns jede IteraDon näher an das Ziel?! Was muss nach jeder IteraDon gelten? 2. Schreiben Sie einen Rumpf der die Invariante güldg lässt 3. BesDmmen Sie den Loop Test so, dass Test-ist-false die PostcondiDon impliziert 4. Schreiben Sie die IniDalisierung so dass dieser Code die Invariante sicher stellt. 23

21 Beispiel Wir wollen dass max den grössten (int) Wert, der in einem Array items auorim, enthält. 1. BesDmmen Sie zuerst die Invariante und lassen Sie sie die anderen SchriMe leiten! Invariante: max speichert den grössten Wert der Elemente 0..k-1 im Array items! Andere Invarianten sind auch möglich 25

22 Wir wollen dass max den grössten (int) Wert, der in einem Array items auorim, enthält. 2. Schreiben Sie einen Rumpf der die Invariante güldg lässt {inv: max holds largest value in items[0..k-1]} while ( ) { } // inv holds if (max < items[k]) { max = items[k]; // breaks inv temporarily } else { // nothing to do } // max holds largest value in items[0..k] k = k+1; // invariant holds again 26

23 Wir wollen dass max den grössten (int) Wert, der in einem Array items auorim, enthält. 3. BesDmmen Sie den Loop Test so, dass Test-ist-false die PostcondiDon impliziert {inv: max holds largest value in items[0..k-1]} while (k!= items.length) { } // inv holds if (max < items[k]) { max = items[k]; // breaks inv temporarily } else { // nothing to do } // max holds largest value in items[0..k] k = k+1; // invariant holds again 27

24 Wir wollen dass max den grössten (int) Wert, der in einem Array items auorim, enthält. 3. BesDmmen Sie den Loop Test so, dass Test-ist-false die PostcondiDon impliziert {inv: max holds largest value in items[0..k-1]} while (k!= items.length) { // inv holds if (max < items[k]) { max = items[k]; // breaks inv temporarily } else { } // nothing to do // max holds largest value in items[0..k] k = k+1; // invariant holds again } {post: k == items.length max largest in items[0..k-1] (also: max largest value in items) } 28

25 Wir wollen dass max den grössten (int) Wert, der in einem Array items auorim, enthält. 4. Schreiben Sie die IniDalisierung so dass dieser Code die Invariante sicher stellt. k=1; max = items[0]; {inv: max holds largest value in items[0..k-1]} while (k!= items.length) { } // inv holds k = k+1; // invariant holds again 29

26 Was muss noch gelten?! Die IniDalisierung hat eine PrecondiDon: items.length > 0 {items.length > 0} k=1; max = items[0]; {inv: max holds largest value in items[0..k-1]} while(k!= items.length) { } 30

27 PrecondiDon! Es ist (je nach SituaDon) akzeptabel eine solche PrecondiDon zu erfordern! Aber sie muss angegeben sein!! Oder wir brauchen eine andere PostcondiDon ( if length is 0, ) und ein If-Statement das diesen Fall prüo! Der Gewinn für uns: Genaue PrecondiDons halten fest, was der Code (die Methode) vom Klienten erwartet.! Für alle lesbar 31

28 QuoDent und Rest Wir suchen für x und y: q den QuoDenten von x / y und Rest r. PrecondiDon: x > 0 y > 0 PostcondiDon: q*y + r == x r >= 0 r < y 33

29 QuoDent und Rest Wir suchen für x und y: q den QuoDent von x / y und Rest r PrecondiDon: x > 0 y > 0 PostcondiDon: q*y + r == x r >= 0 r < y Idee: wiederholte SubtrakDon 34

30 QuoDent und Rest Eine mögliche Loop Invariante: q*y + r == x r >= 0 Ein Schleifenrumpf der die Invariante güldg lässt: q = q + 1; r = r y; Ein Looptest der (wenn falsch) mit der Invariante die PostcondiDon impliziert : y <= r IniDalisierung damit Invariante zu Beginn gilt: q = 0; r = x; 35

31 Alles zusammen {x > 0 y > 0} r = x; q = 0; {inv: q*y + r == x r >= 0 } while (y <= r) { q = q + 1; r = r y; } {q*y + r == x r >= 0 r < y} 36

32 Das Holländische NaDonalflaggen Problem "Klassisches" Problem aus den Anfängen der InformaDk Gegeben sei ein Array mit roten, weissen und blauen Kugeln. Sor6eren Sie den Array so, dass die roten Kugeln am Anfang, die weissen in der MiFe und die blauen am Ende liegen. Benutzen Sie nur die AustauschoperaDon stam (z.b.) zählen und zuweisen Edsgar Dijkstra 37

33 Pre- und PostcondiDons PrecondiDon: irgendeine Mischung von rot, weiss und blau Irgendeine Farbe : rot, weiss, blau PostcondiDon:! Reihenfolge ist rot, dann weiss, dann blau! Die Anzahl der Kugeln jeder Farbe ist die selbe wie zu Anfang Rot Weiss Blau 38

34 Einige mögliche Invarianten Jede dieser Invariante ist brauchbar der Array wird mehr und mehr sordert im Verlauf der Schleife Rot Weiss Blau Beliebig Rot Weiss Beliebig Blau Rot Beliebig Weiss Blau Beliebig Rot Weiss Blau Die beiden mimleren sind besser da wir höchstens nur eine Kugel verschieben müssen nicht evtl. sogar zwei. 40

35 Etwas genauer! PrecondiDon P: arr enthält r rote, w weisse und b blaue Kugeln! PostcondiDon: P 0 <= i <= j <= arr.length arr[0..i-1] ist rot arr[i..j-1] ist weiss arr[j..arr.length-1] ist blau 41

36 Etwas genauer! Invariante: P 0 <= i <= j <= k <= arr.length arr[0..i-1] ist rot arr[i..j-1] ist weiss arr[k..arr.length-1] ist blau! IniDalisierung damit die Invariante gilt (kann vor oder nach der KonstrukDon des Rumpfes gemacht werden): i=0; j=0; k=arr.length; 42

37 Loop Test und Body Rot Weiss Beliebig Blau i j k while(j!=k) { if(arr[j] == Weiss) { j = j+1; } else if (arr[j] == Blau) { swap(arr,j,k-1); k = k-1; } else { // arr[j] == Rot swap(arr,i,j) i = i+1; j = j+1; } } void swap(int[] x, int y, int z) { int tmp = x[y]; x[y] = x[z]; x[z] = tmp; } 43

38 Wann sollten wir Beweise einsetzen! Viele einfache Loops sind offensichtlich! for(string name : friends) { }! Dieser Ansatz lohn sich wenn die Zustände im Rumpf unklar sind, oder es Fencepost Probleme gibt.! Kann auch diesen Ansatz benutzen um eine Idee für den Rumpf zu entwickeln 45

39 Terminierung! Zwei Arten von Schleifen! Die, die immer terminieren sollen (Normalfall)! Die, die immer weiter laufen sollen (z.b. Web Server, Betriebssytem)! Korrektheitsbeweis erfordert im Normalfall einen Beweis, dass der Loop terminiert.! Bisher haben wir das nicht gemacht! Unsere HoareTriples sagen wenn die Schleife terminiert dann gilt die PostcondiDon! ParDelle Korrektheit (korrekt unter der Annahme Terminierung der Schleife) 46

40 Terminierung! Idee: wir bilden den Zustand (nach Ausfuehrung eines Durchlaufs durch die Schleife) auf eine ganze Zahl ab so dass diese Zahl durch jede Ausführung des Rumpfes verkleinert wird! Wir finden einen Beweis dass der Loop Test "false" ergibt wenn diese Zahl zu 0 wird! Damit zeigen wir Terminierung: jede Ausfuehrung verkleinert die Zahl, d.h. es gibt nur endlich viele SchriMe, die die Zahl auf 0 bringen. 47

41 Beispiele! QuoDent-und-Rest: r (am Anfang posidv, wird in jeder IteraDon immer kleiner)! Binäre Suche: Grösse des Bereichs der noch zu bearbeiten ist! Holländische Flagge: Grösse des Bereichs, der noch nicht (nach Farben) aufgeteilt ist (k-j) 48

42 It is easier to write an incorrect program than understand a correct one. Alan Perlis st Department Head at Carnegie Mellon 1 st Winner of the Turing Award 49