Simpli er: Datenstrukturabh angige Regeln · Simpli er: Lokale und globale Regeln 2 Klassen von Simpli erregeln Lokale Simpli erregeln: Werden in Beweisen uber der Spezi kation, in

Simplifier: Datenstrukturabhangige Regeln

• Simplifierregeln sind Axiome oder Theoreme (Sequenzen),die einen entsprechenden Verwendungseintrag haben

• Die syntaktische Form bestimmt den Effekt

• Es gibt mehrere Klassen:• Simplifierregeln• Forward-Regeln

• Alle Regeln konnen lokal oder global sein

Zentral fur das Verstandnis von KIV:Welche Simplifierregel hat welchen Effekt?

7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 70 / 290

Simplifier: Lokale und globale Regeln

2 Klassen von Simplifierregeln

• Lokale Simplifierregeln: Werden in Beweisen uber der Spezifikation,in der sie definiert sind, benutzt.

• Globale Simplifierregeln: Werden in Beweisen in Spezifikationen, dieuber der, in der sie definiert sind, benutzt.

Pragmatik

• Lokal werden Axiome als Simplifierregeln verwendet

• Global werden Theoreme verwendet, die “gute” Simplifierregeln sind

Analog fur Forward-Regeln

Simplifier: Eingabe von Simplifierregeln

Theoreme werden als Simplifierregeln eingetragen, wahlweise durch:

• Am Ende der Sequenz in der specification/sequents-Datei:used for: s, ls;

used for: f, lf;

• Auf Spezifikationsebene im Menu:Add (Local) Simplifierrules

Add (Local) Forwardrules

• Auf Spezifikationsebene: Durch Rechtsklick auf das Theoremund Anklicken der Checkbox

Simplifier: Typen von Simplifierregeln

Simplifierregeln (mit Eintrag s und/oder ls) gehoren zu einer der Klassen

• Termersetzungsregel = Rewriteregel:

Generelle Form: Γ ` ϕ → (σ = τ)Effekt: (Instanzen von) σ durch τ ersetzen

• Formelersetzungsregel = Aquivalenzregel

Generelle Form: Γ ` ϕ → (ψ ↔ χ)Effekt: (Instanzen von) ψ durch χ ersetzen

• Assoziativitat und Kommutativitat:

Generelle Form: (a + b) + c = a + (b + c) und a + b = b + aEffekt: Alle anderen Regeln modulo Ass. und Komm. anwenden

Simplifier: Pragmatik von Bedingungen

Rewrite- und Aquivalenzregeln haben die generelle Form

Γ ` ϕ → σ = τ und Γ ` ϕ → (ψ ↔ χ)

• Vorbedingungen Γ und ϕ:Als Formel dieselbe Bedeutung, aber unterschiedlich behandelt.

• ϕ = ϕ1 ∧ . . . ∧ ϕn muss Konjunktion von Literalen sein

• Literal = evtl. negierte atomare Formel

• Atomare Formel = Anwendung von Gleicheit odernicht vordefiniertem Pradikat (ungleich ∧, ∨, . . . ) auf Terme

• (Instanzen von) ϕ1, . . . , ϕn werden in Sequenz gesucht:Nichtnegierte Formeln im Antezedent, negierte im Sukzedent

• Γ wird versucht durch rekursiven Simplifieraufruf zu beweisen

• Γ darf beliebige Formeln enthalten

Simplifier: Pragmatik von Bedingungen

Wann sollte man Vorbedingungen in Γ stecken, wann in ϕ1, . . . ,ϕn?

• Vorbedingungen vor dem Sequenzenhaken in Γ sollten nur danndefiniert werden, wenn sie in sinnvollen Sequenzen immer erfullt sind.

• Typische sinnvolle Vorbedingungen sind Definiertheitsbedingungen:

• m −1 (Vorganger von m) ist nur fur m 6= 0 definiert• m − n ist nur fur n ≤ m definiert• .rest und .last sind nur fur nichtleere Listen definiert• Arrays: i < #ar sollte fur Zugriff a[i ] immer wahr sein

• Wenn man die Pragmatik nicht befolgt:Viele nutzlose Simplifieraufrufe (wird schnell sehr langsam)

Simplifier: Beispiele zu Vorbedingungen

• n 6= 0 ` (m < n −1 ↔ m +1 < n)Vorbedingung ok im Antezedent, da 0 −1 nicht sinnvoll ist

• ` m < n → (n < m + 2 ↔ m + 1 = n)Nicht im Antezedent, sonst, sobald Instanzen von n < m + 2vorkommen: Viele unnotige Beweisversuche fur m < n

• m ≤ n ` (n − m) + m = m

Beweist z. B. die Sequenz f(x) > 5 ` (f(x) − 3) + 3 = f(x)(da der Simplifier f(x) > 5 ` 3 ≤ f(x) beweisen kann)

` m ≤ n → (n − m) + m = m beweist die Sequenz nicht,da 3 ≤ f(x) nicht in der Sequenz vorkommt

Simplifier: Rewrite-Regeln

Γ ` ϕ → σ = τ

ersetzt (Instanzen von) σ durch τ , wenn Vorbedingungen ok

Einschrankungen:

• free(ϕ) ∪ free(σ) muß alle freien Variablen abdecken

• σ und τ mussen Terme sein, σ darf keine Variable sein

Beispiele:

• (m + n) − n = m

• i > 0 → sqrt(i ˆ 2) = i (i integer; warum nicht im Antezedent?)

• (s1 ∪ s2) \ s2 = s1 \ s2 (Mengen)

• x 6= [] → (x + y).first = x .first (Listen, + = append, warum nichtAnt.?)

Simplifier: Aquivalenzregeln

Γ ` ϕ → (ψ ↔ χ)

ersetzt (Instanzen von) ψ durch χ, wenn Vorbedingungen ok

Einschrankungen:

• free(ϕ) ∪ free(ψ) muß alle freien Variablen abdecken

• ψ muss Literal sein, χ ist beliebige Formel

• Vereinfachung: Falls ψ keine Gleichung, statt (ψ ↔ true) nur ψ

• Vereinfachung: Statt (ψ ↔ false) nur ¬ ψ

Beispiele:

• sorted(a + []), # x = 0 ↔ x = [] (Listen)

• m + n < m + n0 ↔ n < n0

• n 6= 0 ` (m < n −1 ↔ m +1 < n)

Simplifier: Kommutativitat und Assoziativitat

• Kommutativitat: m + n = n + m

• Assoziativitat: (m + n) + k = n + (m + k)

• Kurz: C(+), A(+), AC(+) fur komm., ass., komm. und ass.

• Werden nicht direkt verwendet (Warum?)

• Ob eine Simplifierregel passt, wird “modulo” dieser Regeln gepruft

• ` a + b ∗ c = c ∗ b + a wird mit C(+,*) sofort (per Reflexivitat)bewiesen

• ` b ∗ c ≤ (c ∗ a) ∗ b wird fur AC(∗) mit der Regel m ≤ m ∗ nbewiesen

• Viele Operatoren sind AC: +, ∗, min, ggt, ∪• Nur assoziativ ist z. B. append auf Listen, ∗ auf Matrizen

• Nur kommutativ ist sehr selten

Simplifier: Forwardregeln

• Manchmal will man neue Information zu einer Sequenz dazunehmen

• Fast nur fur Transitivitat von Ordnungs- und Aquivalenzrelationen:• m < n ∧ n < n0 → m < n0• isperm(x , y) ∧ isperm(y , z) → isperm(x , z)

• Dazu gibt es Forward-Regeln der Form:

Γ ` ϕ1 ∧ . . . ∧ ϕn → ϕ

• Vorbedingungen werden wie bei Simplifierregeln behandelt

• ϕ wird genau einmal zur Sequenz addiert

Simplifier: Hinweise zu Forwardregeln

• Transitivitat ist unkritisch (sollte man machen)

• Haufig etliche Varianten notwendig:• m < n ∧ n ≤ n0 → m < n0• m < n ∧ ¬ n0 < n → m < n0• m ≤ n + 1 ∧ n < n0 → m ≤ n0

• Ein Lemma sollte nie Forward- und Simplifierregel sein. Warum?

• Forward-Regeln geben sehr leicht Endlosschleifen im Simplifier! ⇒Sehr vorsichtig, nur mit gutem Grund verwenden

• Einfaches Bsp. fur Endlosschleife: ` m < n → m < n + 1

• Bsp.: 0 < n ` (∗ n) ≤ m → m 6= 0

• Warum nur (∗ n) und nicht einfach n? Warum 0 < n im Antezedent?

KIV-Kalkul: Elimination fur Selektoren

• Listen haben (Postfix-)Selektoren• .first (erstes Element)• .rest (Rest der Liste)

• Trick: Selektoren loswerden mit Hilfe von insert elim lemma

• Benotigt wird Lemma` x 6= [] → (a = x .first ∧ y = x .rest ↔ x = a + y)

• Eliminationsregel sucht einen Term t.first oder t.rest

• Wenn t 6= [] gilt, wird t = a + y ersetzt (neue Variablen a, y)

• Damit wird aus t.first bzw. t.rest jetzt a bzw. y

t = a + y ,Γ(a, y , a + y) ` ∆(a, y , a + y)

t 6= [],Γ(t.first, t.rest, t) ` ∆(t.first, t.rest, t)

KIV-Kalkul: Elimination fur andere Funktionen

• Manchmal geht Elimination auch fur andere “unbeliebte” Funktionen

• Beliebte Beispiele: Minus und Division

• Lemma fur Minus: n ≤ m ` n0 = m − n ↔ m = n0 + n

• Vorteil: Man kann auf Simplifierregeln fur − verzichten!

• Nachteil: Neue Variable n0 wird eingefuhrt (manchmal unintuitiv)

Γ(n0 + n, n, n0) ` ∆(n0 + n, n, n0)

n ≤ m, Γ(m, n,m − n) ` ∆(m, n,m − n)

Automatisierung in KIV: Heuristiken

• Flexible Automatisierung ist zentral, um bei grossen Fallstudien nichtimmer wieder die gleichen Beweisschritte wiederholen zu mussen

• Deshalb in KIV: Automatisierung durch zuschaltbare Heuristiken

• Speziell: Der Simplifier ist eine Heuristik⇒ Sollte man (fast) immer benutzen

• Fur jedes Beweisziel werden alle Heuristiken der Reihen nachausprobiert

• Gewahlte Heuristiken jederzeit anderbar

Sehr wichtig fur das Verstandnis von KIV:Welche Heuristik hat welchen Effekt?

Wichtige Heuristiken fur PL in KIV (1)

• Simplifier• Wendet die Simplifier-Regel an

• pl case distinction• Wendet Regel case distinction an• Fur einfache bis mittelschwere Beweise• Gefahr, unnotige Fallunterscheidungen zu machen

• if-then-else-split• if-then-else-Operator:

(ϕ ⊃ σ; τ) bezeichnet σ, falls ϕ wahr ist, sonst τ• Wendet cut Regel mit ϕ an• Haufig einsetzbar, um sinnvolle Fallunterscheidungen zu erzwingen• Beispiel: Fallunterscheidung nach Anwendung von Rewrite-Regel

abs(i) = (i ≥ 0 ⊃ i ; − i)

• Quantifier closing• Sucht Instanzen, mit denen eine Pramisse direkt geschlossen werden

kann• Immer verwenden• Einziges Problem: Bei sehr vielen Quantoren braucht die Heuristik viel

unnotige Zeit• Deshalb Spezifikationsmethodik:

Pradikat (+ Simplifierregeln) definieren statt grosse Quantorenformelnzu verwenden

• Quantifier:• Sucht

”sinnvolle“ Instanzen fur Quantoren

• Kann Endlosschleifen verursachen!• Nur bei einfachen Quantorenbeweisen einsetzbar

• structural induction:• Macht strukturelle Induktion uber “sinnvolle” Terme• Idee fur “sinnvoll”: Variablen an rekursiven Positionen:

n ist sinnvoll in m + n, da + rekursiv uber das zweite Argumentdefiniert: m + 0 = m, m + (n +1) = (m + n) +1

• Klappt meistens, aber nicht immer• Heuristik wendet ausserdem einmal die Induktionshypothese an

• module specific:• Eigentlich eine Meta-Heuristik: Erlaubt heuristische Anwendung von

Regeln durch Patterns• Pattern: Gibt Formeln (oder Schemas fur Formeln) an, die in der

Sequenz vorkommen mussen bzw. nicht vorkommen durfen + Regeldie angewandt werden soll

• Alle Patterns stehen in der Datei module-specific

elimination:

• Heuristik gesteuert durch Eliminationsregeln(analog zu: Simplifier durch Simplifierregeln)

• KIV-Eingabe analog: used for: e; etc.

• Beispiel: n ≤ m ` n0 = m − n ↔ m = n0 + n

• Vorbedingung im Antezedent: n ≤ m muss beweisbar sein(analog zu Simplifierregeln)

KIV-Kalkul: Heuristiksatze

• In KIV: 3 vordefinierte Heuristiksatze:• PL Heuristics: Minimale Menge sinnvoller Heuristiken• PL Heuristics + Case Splitting: Keine Induktion, FU automatisch• PL Heuristics + Struct. Ind.:

Versucht, Ziel induktiv zu beweisen und Fallunterscheidungen (FU)automatisch zu machen

• Fur grossere Projekte definiert man haufig seinen eigenenStandardsatz⇒ Datei default-heuristics

• Weitere Heuristiken fur Programme (DL). Dort noch wichtiger, daProgramme mehr Struktur haben (spater)

Formale Spezifikation und Induktion

Was ist ein SW-System mathematisch?

1. Sicht: Operational

Ein SW-System ist ein Automat

• mit Zustand,

• Zustandsubergangen und

• mit Ablaufen.

2. Sicht: Algebraisch

Ein SW-System ist eine Algebra = Datenstruktur, d. h. ein System vonDaten und Operationen.

Was ist spezieller?

Einen Automaten kann man als spezielle Algebra auffassen:

• Zustand = Element einer Datenstruktur ⇒ Algebra!

• Sorten = State, Input, Output mit Operationen• Anfangszustande:

isinitial: State → Bool• Zustandsubergangsfunktion (oder auch Relation):

exec: Input × State → (State × Output → Bool)

• Z. B. Zustand eines Programms:Programm + Programmzahler + Speicherbelegung

• Theoretisch: Algebraische Sicht genugt

• Praktisch: Automatensicht hat viele Spezialeigenschaften(u. a. ist eine Idee von

”Zeit“ damit verbunden).

Deshalb Codierung oft nicht die beste Idee.

SW-Beschreibungsformalismen

SW-System ist Datentyp:

• Modellorientierte Spezifikation (Z, VDM):Alle Datentypen sind mit Mengenlehre gebildet (Tupel und Mengenz. B. fur UML-Klassendiagramme)

• Algebraische Spezifikation

SW-System ist Menge von Ablaufen:

• Algorithmische Spezifikation, z. B. Programmiersprachen

• Programme uber algebraischen/modellorientierten Datentypen

• Automaten, Harel/UML Statecharts, Abstract State Machines(ASMs)

Eignung hangt von den Zielen ab (Was will ich beschreiben? Wasbeweisen?)

Spezifikation

Ziel: Ein bestimmter Datentyp (Algebra) soll spezifiziert werden.

Fragen:

1 Was fur Operationen brauche ich?

2 Welche Axiome brauche ich?

3 Welche Datentypen kann ich uberhaupt spezifizieren?

4 Kann ich alle wahren Aussagen uber dem Datentyp auch beweisen?

Zunachst: Fragen 3 + 4 speziell fur die naturlichen Zahlen

Naturliche Zahlen: Die Peano-Axiome

• Es gibt eine ausgezeichnete Zahl 0 ∈ IN.

• Jede Zahl n ∈ IN hat einen Nachfolger succ(n) ∈ IN.

• Zu zwei Zahlen gibt es Summe m + n und Produkt m ∗ n

• Axiom 1: 0 ist kein Nachfolger.

• Axiom 2: Die Nachfolgerfunktion ist injektiv.

• Axiom 3: m + 0 = m, m + succ(n) = succ(m + n)

• Axiom 4: m ∗ 0 = 0, m ∗ succ(n) = m ∗ n + m

• Axiom 5: IN ist die kleinste Menge M mit:0 ∈ M und wenn n ∈ M, dann succ(n) ∈ M

Aus dem letzten Axiom folgt das Induktionsprinzip:Wenn ϕ(0) gilt, und sich ϕ von n auf n +1 vererbt, dann ist ϕ fur alle nwahr

Begrundung: M := {n : ϕ(n)} ist mindestens so groß wie IN.

Naturliche Zahlen: Mit PL nicht spezifizierbar!

Satz (Charakterisierung der naturlichen Zahlen)Die Peano-Axiome charakterisieren ein Modell (eben die naturlichenZahlen) bis auf Isomorphie (= Umbenennung).

Beachte dabei: Peano-Axiom 5 ist kein pradikatenlogisches Axiom!

Satz von SkolemEs gibt keine Menge Ax-Nat von pradikatenlogischen Formeln, die alseinziges Modell (modulo Umbenennung) nur die naturlichen Zahlen hat.Beweisbar mit Vollstandigkeitssatz

Intuition: Pradikatenlogische Axiome konnen nicht ausdrucken, dass esneben den

”echten“ naturlichen Zahlen keine weiteren Zahlen gibt.

Naturliche Zahlen: Ein schwacheres Ziel

Wir wissen schon: Jede Axiomenmenge hat auch andereModelle als IN mit zusatzlichen Elementen.

Wir versuchen es schwacher: Suche Axiomenmenge, mit der alle uber INwahren Aussagen bewiesen werden konnen (dass sie auch uber anderenModellen gelten, konnte uns ja egal sein).

Die Axiomenmenge sollte entscheidbar sein, d. h. es gibt Programm,das immer terminiert und sagt: “ja, ist Axiom” oder “nein, ist keinAxiom”.Sonst Triviallosung: Nehme als Axiome samtliche wahren Aussagen.

Zum Beispiel: Nehme Induktionsschema zu den Axiomen dazu:ϕ0n ∧ (∀ n. ϕ → ϕn +1

n ) → ∀ n. ϕ; (: fur jedes ϕ ∈ For(Σ,X) :)

Die Formel ϕ(n) mit freier Variable n beschreibt die Menge{n : IN |= ϕ(n)}.Das Induktionsschema fur ϕ entspricht Peano-Axiom 5 fur diese Menge

Naturliche Zahlen: Unvollstandigkeit

Problem: Alle Formeln (abzahlbar viele) beschreiben nicht alle Mengen(uberabzahlbar viele)!

Es gilt leider:

Godelscher UnvollstandigkeitssatzEs gibt keine entscheidbare Menge von Formeln uber (0, succ, +, ∗), diedie ersten 4 Peano-Axiome und n 6= 0 → ∃ n. n = succ(m) enthalt oderimpliziert, mit der sich alle in IN wahren Aussagen ableiten lassen(insbesondere ist das Induktionsschema auch unvollstandig).

Der Trick zum Beweis ist das Lugnerparadoxon (”ich luge jetzt“)

in Form einer Formel, die sagt:”Ich bin nicht beweisbar“.

Indem man die Formeln durchnumeriert (z.B. ASCII-Codierung),wird das

”Ich“ durch

”Meine Nummer“ ausdruckbar.

Naturliche Zahlen: Unvollstandigkeit

Intuition:

• Leider findet man auch keine”gute“ Axiomenmenge, mit der die

wahren Aussagen herleitbar sind

• Alle wahren Aussagen konnte man als Axiome trivialerweise nehmen.

• Die Menge der wahren Aussagen ist also nicht entscheidbar.

• Wahre Aussagen fur die naturlichen Zahlen zu beweisen, ist kreativ.

• Verursachte ziemlich viel Wirbel in den 30er Jahren:Die Idee, Mathematik auf ganz einfachen Grundlagen aufzubauen(Hilbert’sches Programm), war gescheitert

• Heute: Komplizierte Mengenlehre (Zermelo-Frankel, Godel-Bernays)als Grundlage fur Mathematik.

Problem: Pradikatenlogik reicht nicht

Problem: Pradikatenlogik kann nicht ausdrucken, dass es ausser denZahlen 0, 1, 2 (= die aus 0 und +1 gebildeten Terme 0, 0 +1, 0 +1 +1, . . .)keine weiteren Elemente gibt.

Dasselbe Problem gibt es auch fur andere Datentypen:

• Alle ganzen Zahlen sind mit 0, +1, −1 gebildet• Alle Listen sind die aus [] und + gebildeten Terme:

[], a + [], a + b + [], . . .• Bei Listen: Terme durfen Elementvariablen enthalten

• Alle (endlichen) Graphen bekommt man aus dem leeren ∅, durchAddieren von Knoten (addnode) und Kanten (addedge)

• Alle Arrays bekommt man durch:• mkarray(n) (erzeugt Array der Grosse n)• put(a, i , d) (schreibt an Position i das Datum d)

Gemeinsame Idee: Alle Datenelemente durch endlich-malige Anwendungvon Konstruktoren bildbar

Generiertheitsklauseln: Syntax

Deshalb Idee: Wir definieren ein “Spezialaxiom”, genanntGeneriertheitsklausel, das aussagt: Die Daten eines Datentyps sind genaudie mit bestimmten Konstruktoren gebildeten Terme.

Syntaxs generated by C ist Termerzeugtheitsklausel (∈ Gen(Σ)) ⇔

• s ∈ S , C = {f1, . . . , fn} ⊆ OP,

• die Konstruktoren fi haben die Ergebnissorte s(Konstanten sind als Konstruktoren erlaubt)

• fur wenigstens ein fi sind alle Argumentsorten ungleich s(sonst gibt es keine Konstruktorterme!)

Ein Konstruktorterm t hat die Sorte s, ist mit Konstruktoren aus Cgebildet und enthalt nur Variablen anderer Sorten, ist also ausTs((S,C),X \ Xs).

Generiertheitsklauseln: Semantik

Idee: Jedes Element der generierten Sorte ist der Wert einesKonstruktorterms, wenn man die (Parameter)-Variablen geeignet belegt.

Semantik

A |= s generated by C :⇔fur jedes a ∈ As gibt es ein v und t ∈ Ts((S ,C ),X \ Xs) mit a = [[t]]A,v .

Beispiel: Zur Liste [2,5] gibt es den Konstruktorterm a + b + [].

Mit einer Belegung v der Variablen a, b als v(a) = 2 und v(b) = 5 gilt:

[[a + b + []]]A,v = [2,5].

Basisspezifikation

BasisspezifikationEine Spezifikation SP = (Σ, Ax , Gen) ist ein Tripel mit:

• Σ = (S , OP)

• Ax ⊆ For(Σ, X ) endlich

• Gen ⊆ Gen(Σ) endlich

ModellA ist Modell von SP (A |= SP, A ∈ Mod(SP))A |= SP :⇔ A ∈ Alg(Σ), A |= Gen und A |= Ax .

GultigkeitSP |= ϕ :⇔ fur alle A in Mod(SP): A |= ϕ

Konsistenz und Monomorphie

Definition Eine Spezifikation ist konsistent:⇔ Axiome nicht widerspruchlich⇔ Kein Beweis von false moglich⇔ Es gibt ein Modell A der Spezifikation

⇒ Das muss sein!

Definition Eine Spezifikation ist monomorph:⇔ Axiome legen Verhalten eindeutig fest⇔ Je zwei Modelle sind bis auf Umbenennung (Isomorphie) gleich

⇒ Sollte fur Datentypen wie naturliche Zahlen etc. so sein(die Axiome sollten ja nicht versehentlich auch reelle Zahlen erlauben).

⇒ Fur Systembeschreibungen oft nicht erforderlich bzw. wunschenswert.Man will ja gerade Details offenlassen.

Minimale Spez. der naturlichen Zahlen in KIV

specificationsorts nat;constants 0 : nat;functions . +1 : nat → nat;induction nat generated by 0, +1;variables m, n : nat;axioms0 6= n +1;m 6= n → m +1 6= n +1;

end specification

ist konsistent und mononorph

Spez. der naturlichen Zahlen mit Add. und Mult.

specificationsorts nat;constants 0 : nat;functions . +1 : nat → nat;

. + . : nat × nat → nat;

. ∗ . : nat × nat → nat;induction nat generated by 0, +1;variables m, n : nat;axioms0 6= n +1;m 6= n → m +1 6= n +1;m + 0 = m; m + n +1 = (m + n) +1;m ∗ 0 = 0; m ∗ (n +1) = m * n + m;

end specification

ist konsistent und mononorph

Minimale Spez. der Listen in KIV

specificationsorts elem; list;constants [] : list;functions . + . : elem × list → list;induction list generated by [], +;variables a, b : elem;

x, y : list;axioms[] 6= a + x;a 6= b ∨ x 6= y → a + x 6= b + y;

end specification

ist konsistent und mononorph, wenn die Tragermengefur die Elemente vorgegeben ist (“monomorph modulo Parameter”)

Kalkul mit struktureller Induktion

Strukturelle Induktion

Sorte s erzeugt von Konstruktoren c , f ⇒ Jedes Element derTragermenge ist darstellbar als Konstruktorterm f (f (. . . f (c)))

Induktionsformeln: ϕ(c) ∧ (∀ x . ϕ(x) → ϕ(f (x))) → ∀ x . ϕ(x)

Induktionsregel:` ϕ(c) ϕ(x) ` ϕ(f (x))

Γ ` ∆

ϕ = ∀ y .∧

Γ →∨

∆, y = free(Γ→ ∆) \ {x}

AbleitungWenn man aus der Spezifikation SP durch Anwendung vonSequenzenkalkul + Induktions-Regel die Formel ϕ ableiten kann, dannschreibt man SP `IND ϕ.

Kalkul mit struktureller Induktion:Korrektheit und Unvollstandigkeit

Satz (Korrektheit)Es gilt SP `IND ϕ ⇒ SP |= ϕ

Satz (Unvollstandigkeit)Es gibt Spezifikationen und Theoreme mit SP |= ϕ, die aber mitInduktion nicht beweisbar sind (SP 6`IND ϕ).

Wie schlimm ist Unvollstandigkeit?

• Der Kalkul mit der Induktions-Regel ist”fast vollstandig“:

Wenn SP |= ϕ, dann gibt es eine Erweiterung SP ′ von SP um neuerekursiv definierte Hilfsfunktionen, so dass SP ′ `IND ϕ gilt.

• Praktisch gesehen: Mit den zusatzlichen Symbolen in SP ′ wird einepassend (verallgemeinerte) Induktionshypothese fur den Beweis vonϕ ausdruckbar.

• Beachte: Mit der Generiertheitsklausel ist die Induktionsregel auchauf Formeln mit den Hilfsfunktionen anwendbar (die Menge dermoglichen Ind. hypothesen wachst!)

• SP ′ ist je nach ϕ verschieden (kein uniformes SP ′).

• In jedem SP ′ gibt es neue Formeln ψ, die wahr aber nicht ableitbarsind.

• Kreativititat also fur Verallgemeinerung und passendeHilfsfunktionen.

Strukturierte Spezifikation:

Freie Datentypen

Wie spezifiziert man Datentypen?

Vorgehen:

• Schritt 1: Definiere benotigte Sorten

• Schritt 2: Datentypen auf Rechnern sind generiert⇒ Definiere Konstruktoren und Generiertheitsklauseln

• Schritt 3(?): Definiere weitere Operationen und ihre Axiome

Problem: Wie geeignete, ,,richtige“ Axiome finden?

Formal ,,richtig“: Sie sollten fur den gewunschten Datentyp stimmen(keine Inkonsistenz!), und sollten ihn moglichst eindeutig charakterisieren.

Freie und nichtfreie Datentypen

nat ???? bynat ???? byinteger???? byset ???? byset ???? bystack ???? bybintree???? bygraph ???? by

list ???? by

Beobachtung: Manche Datentypen sind frei (erzeugt): Zwei verschiedeneKonstruktorterme reprasentieren auch immer zwei verschiedene Elemente.

nat 0,+1nat 0, 1,+integer 0,+1,−1set ∅, insset ∅, {.}, ∪stack empty, pushbintree mkleaf, mkbranchgraph ∅, +node, +edge

list [], +

Beobachtung: Manche Datentypen sind frei (erzeugt): Zwei verschiedeneKonstruktorterme reprasentieren auch immer zwei verschiedene Elemente.

nat freely generated by 0,+1nat generated by 0, 1,+ 0 + 0 = 0integer generated by 0,+1,−1 0 +1−1 = 0set generated by ∅, ins ins(a,ins(a,∅)) = ins(a,∅)

set generated by ∅, {.}, ∪ {a} ∪ {a} = {a}stack freely generated by empty, pushbintree freely generated by mkleaf, mkbranchgraph generated by ∅, +node, +edge ∅ +node n +node n

= ∅ +node nlist freely generated by [], +

Axiome fur freie Datentypen

Beispiel: Konstante c , einstellige Funktion f , zweistellige Funktion g

• Verschiedenheit der Konstruktoren c , f und g :c 6= f (x), f (x) 6= g(y , z), c 6= g(x , y)

• Injektivitat der Konstruktoren:f (x) = f (y) ↔ x = y , g(x , y) = g(u, v) ↔ x = u ∧ y = v

Satz: Die Spezifikation mit diesen Axiomen ist monomorph und

konsistent, sie charakterisiert also genau einen Datentyp.

KIV: Schreibe freely generated by, Axiome werden generiert.

Freie Erzeugtheitsklauseln

A |= S ′ freely generated by C :⇔• A |= S ′ generated by C

• Fur 2 Konstruktorterme t, t ′ ∈ T s((S ,C ),X \ Xs) mit s ∈ S ′ gilt nurdann

[[t]]A,v = [[t ′]]A,v ′

wenn sie mit den exakt gleichen Konstruktoren gebildet sind,und die Variablen an gleichen Positionen gleich belegt sind.

Beispiel Listen:

• [[[]]]A,v , [[a + []]]A,v ′ , [[a + b + []]]A,v ′′ sind auf jeden Fallverschiedene Listen (egal wie die Belegungen v , v ′, v ′′ sind)

• [[a + []]]A,v = [[b + []]]A,v ′ gdw. wenn v(a) = v ′(b).

Naturliche Zahlen als freier Datentyp

Beispiel: Die naturlichen Zahlen

Nat3 =specificationsorts nat;constants 0 : nat;functions +1 : nat → nat;variables n : nat;induction nat freely generated by 0, +1;end specification

⇒ Neu: Axiome jetzt generiert.

Listen als freier Datentyp

Beispiel: Listen als freier Datentyp

List2 =specificationsorts list, elem;functions

[] : → list;. + . : elem × list → list;

variables a, b: elem; l, l1, l2: list;induction list freely generated by [], +;end specification

Generierte Axiome fur Listen

Generierte Axiome

Spezifikation generiert:[] 6= a + l ,a + l1 = b + l2 ↔ a = b ∧ l1 = l2

Induktionsregel fur die Sorte list

∀ y .∧

Γ→∨

∆,Γa+ll ` ∆a+l

l Γ[]l ` ∆

Γ ` ∆

y = free(Γ ` ∆) \ {l}

Datentyp-Definion (Motivation)

Haufige Situation:

• Freie Erzeugbarkeit mit Konstruktoren ci

• Selektoren, die aus ci (x1, . . . xn) die xj selektieren

• Testpradikate”ist mit Konstruktor cl gebildet“

• Ordnung:”ist Unterterm von“

• Großenfunktion:”Anzahl nichtkonstanter Konstruktoren“

⇒ Eigenes Syntaxkonstrukt data specification vermeidet unnotigeSchreibarbeit.

In KIV typischerweise nie freely generated, sondern gleich dataspecification

Data Specification (Beispiel 1)

Beispiel 1: Wochentage

Weekday2 =data specificationweekday = Mon | Tue | Wed | Thu | Fri | Sat | Sun;variables w : weekday;end data specification

Generierte Axiome: Die Konstanten sind paarweise verschieden:

Mon 6= Tue, Mon 6= Wed, Mon 6= Thu, Mon 6= Fri, . . .

Induktionsregel:ΓMonw ` ∆Mon

w . . . ΓSunw ` ∆Sun

Γ ` ∆

⇒ Beweis durch Fallunterscheidung nach dem Tag

Verallgemeinerung: Aufzahlungstypen

Beispiel 2: Paare

Pair =data specificationusing Elem1, Elem2;pair = mkpair ( . .1 : elem1; . .2 : elem2 )variables p : pair;end data specification

Generierte Axiome: mkpair(a, b).1 = a; mkpair(a, b).2 = b

Induktionsregel:Γmkpair(a,b)p ` ∆

mkpair(a,b)p

Γ ` ∆

⇒ Expandiert Variable p zu mkpair(a, b)

Verallgemeinerung: Tupel

Beispiel 3: naturliche Zahlen

Nat =data specificationnat = 0

| . +1 (. −1 : nat);variables n : nat → nat;order predicates . < . : nat × nat;end data specification

Generierte Axiome: n +1−1 = n; (: 0−1 ist unspezifiziert :)¬ n < n; m<n ∧ n<k → m<k ;¬ n < 0; m < n +1 ↔ (m = n ∨ m < n)

Beispiel 4: Listen

List =data specificationusing Nat, Elem;list = . + . (. .first : elem; . .rest : list) with consp

| [] with nilp;variables l : list;(: ist Unterterm fur Listen = ist Endstuck :)order predicates . � . : list × list;size functions length : list → nat;end data specification

Selektoren als partielle Funktionen

Problem: Was tun, wenn ein Selektor auf den falschen Summandangewandt wird?

Hier: Was sind [] .first und [] .rest?

.first und .rest sollten fur [] gar nicht definiert sein ⇒ Partielle Funktionen

In KIV: []. first und [].rest sind unspezifiziert (i. e. kein Axiom)

Semantik: [].rest ist in jeder Algebra (Datenstruktur) irgendeine andereListe ⇒ Echte Implementierung muss irgendeine Liste zuruckgeben

Pragmatik: Formeln mit [].rest sollten nicht vorkommen.Wenn doch, muss die Sequenz ohne die Formeln beweisbar sein.

Bem.: Alternativen sind moglich aber komplizierter (u. a. Fehlerelemente,echte Partialitat, etc.)

Neue Axiome fur List3:

nilp([]);¬ nilp(a + l);

¬ consp([]);consp(a + l);

(a + l).first = a; (: kein Axiom fur [] .first :)

(a + l).rest = l ; (: kein Axiom fur [] .rest :)

¬ l � [];l � (a + l1) ↔ l = l1 ∨ l � l1;

(: beweisbar, aber der Einfachheit halber generiert :)¬ l � l ; l1 � l2 ∧ l2 � l3 → l1 � l3;

length([]) = 0;length(a + l) = length(l) +1;

Data Specification allgemein

Definition (Datendefinition)

Eine Datendefinition D hat die Form (optionales in eckigen Klammern):

s = c1(sel1,1 : s1,1; . . . ; sel1,n1 : s1,n1) [with p1]| . . .| ck(selk,1 : sk,1; . . . ; selk,nk : sk,nk ) [with pk ];

[order predicate . � . : s × s;][size function sz : s → nat;]

Uberladen: sel i ,j = sel i ′,j ′ erlaubt, falls si ,j = si ′,j ′ ,ansonsten alle Operationen paarweise verschieden.

Eigenschaften von Data Specifications

Satz: Alle Data Specifications sind immer konsistent. Sie sind immer

monomorph bis auf unspezifizierte Selektoren und Parameter.

Intuition bei Listen ist also:

1 Wir haben exakt den Datentyp der Listen beschrieben.

2 Fur die Realisierung auf einem Rechner ist lediglich offen,

• was fur ein Elementtyp verwendet wird und• was fur eine Element bzw. Liste [].first und [].rest zuruckgeben.

Datentyp-Definitionen in Java

Implementierung von Datentyp-Definitionen in Java:

abstract class s {} /* Dies entspricht der Sorte s */

/* Subklasse fur Konstruktor c1 */

class c1 extends s {s11 sel11; /* ein Feld pro Selektor */

s12 sel12; ...

s1n1 : sel1n1;

/* Konstruktor */

public c1(s11 se1, s12 se2, ...) {sel11 = se1; sel12 = se2; ...}

/* Subklasse fur Konstruktor c2 */

class c2 extends s {...

Simpli er: Datenstrukturabh angige Regeln · Simpli er: Lokale und globale Regeln 2 Klassen von Simpli erregeln Lokale Simpli erregeln: Werden in Beweisen uber der Spezi kation, in

Documents

Simpli ed Constructibility Theory

Die Regeln

Mini–Regeln Modifizierte Regeln für U12 und U11 Stand: ....

Ebene 1 Erfolgskriterien der Beziehungsebene – das Wie ·...

Ramai Motivat in 9 Pasi Simpli

Handball-Regeln (gültig seit 1. August 2001) Geänderte...

BUSINESS PRIORITY PRODUCTS - Simpli Connect

Learning simpli ed functions to understand

Verbinden - Haltern - Regeln

MB.IDEAS.MAG #1 - SIMPLI-CITY

Regeln – Grenzen – Konsequenzen

... ein paar Regeln ...

Biscuitii simpli raman in topul vanzarilor

Meetings Simpli ed by DoubleTree by...

Simpli 5 Camp - bvmashti.edu.in

Trei pasi simpli catre prosperitatea financiara