Upload
trantu
View
214
Download
0
Embed Size (px)
Citation preview
Beispiel: Anreicherung um rek. Definition
Append =enrich List withfunctions . + . : list × list → list;axioms[] + l = l;(a + l) + l’ = a + (l + l’);end enrich
Append ist hierarchiepersistent und eindeutig(+ ist überladen: sowohl Element vor Liste hängen (rot und schwarz),als auch 2 Listen zusammenhängen (blau))
146
Beispiel: Anreicherung um rek. Prädikat (FU)
Sorted =enrich List withpredicates sorted : listaxiomsordered([]),ordered(a + []),ordered(a + b + l) ↔ a < b ∧ ordered(b + l)end enrich
Ordered ist hierarchiepersistent und eindeutig,
da die FU vollständig ist (jede Liste ist entweder = [], a+ [], a+ b+ l)
147
Strukturierte Spezifikationen:
Umbenennung und Parameter
148
Strukturierte Spezifikationen:Umbenennung
Umbenennung:
• benennt die Operationen einer Spezifikation um
• nützlich um 2 Kopien zu erhalten
• Syntax: rename <SPEC> by morphism<renaming1>;...<renamingn>;
end rename
• renaming = <sort/op/var> → <sort/op/var>;
• identische Umbenennungen weglassen(werden beim Ansehen der Spezifikation aber angezeigt)
• Nicht 2 Symbole auf dasselbe abbilden: injektiv umbenennen
• entweder alle Variablen oder keine umbenennen
149
Beispiel Umbenennung:Listen zu Stacks
rename List by morphismlist → stack;[] → empty;(: Typangabe f ur uberladenes Symbol :)+ :: (elem × list → list) → push;(: pop nicht mehr postfix, Schreibweise stattdessen pop(x) ,
default ist in/prae/postfix uebernehmen :).rest → pop prio 0;(: top soll nun praefix sein :).first → top .;(: eigentlich keine Stack-Operation,
nur um Overloading zu zeigen :)+ :: (list × list → list) → concat prio 0;x → st;y → st0;z → st1;end rename 150
Strukturierte Spezifikationen:Generische Spezifikation
Generische Spezifikation:
• Syntax: generic specificationparameter <SPEC>using <SPEC1>, ..., <SPECn>target
<signature><induction><axioms>
end generic specification
• wie Anreicherung (von <SPEC>, <SPEC1>, ..., <SPECn> ), nur wirdvon <SPEC>explizit gesagt, dass es sich um einen Parameter handelt
• Vereinigung und Anreicherung übernimmt den (oder die) Parameter derUnterspezifikationen
• Variante: generic data specification : wie data specification nur mit Parameter
151
Strukturierte Spezifikationen:Aktualisierung (1)
Aktualisierung:
• instanziert Parameter (oder einen Parameter) einer Spezifikation
• Beispiel: Listen beliebiger Elemente → Listen von Zahlen
• Syntax: actualize <SPEC> with <ASPEC1>,...,<ASPECn> by morphism<renaming1>;...<renamingn>;
end actualize
• renaming = <sort/op/var> → <sort/op/var>;
• Die Vereinigung von <ASPEC1>,...,<ASPECn>heisst aktuelle Spezifikation
• identische Umbenennungen weglassen
• entweder alle Variablen oder keine umbenennen
152
Strukturierte Spezifikationen:Aktualisierung (2)
Aktualisierung:
• Der Parameter muss in die aktuelle Spez. abgebildet werden
• Abbildung darf nicht-injektiv sein: pair(elem1 , elem2 ) → pair(nat ,nat)
• Der Nicht-Parameter-Teil darf nur injektiv,und disjunkt zur aktuellen Spez. umbenannt werden, z.B. list → natlist
• Die instanzierten Axiome des Parameters müssen Axiome in deraktuellen Spezifikation sein
• Verallgemeinerung instantiated specification :⋆ Axiome werden bewiesen⋆ mapping statt morphism erlaubt es,
eine Sorte auf ein Tupel von Sorten abzubilden⋆ (später bei ASMs)
153
Aktualisierung: Beispiel (1)
Order =specificationsorts elem;constants d : elem;predicates ≪ : elem × elem;variables a, b, c : elem;axioms¬ a ≪ a; a ≪ b ∧ b ≪ c → a ≪ c;¬ a ≪ d; (: d ist minimal :)end specification
List-Ord =generic data specificationparameter Orderusing Natlist = [] | . + . (. .first : elem; . .rest : list);size functions length : list → nat;end generic data specification
154
Aktualisierung: Beispiel (2)
NatList =actualize List-Ord with Natby morphismlist → natlist;elem → nat;≪ → <;d → 0;a → n; b → n0; c → n1;end actualize
Die instanzierten Axiome (u.a. ¬ n < 0) sind(modulo Umbenennung) in Nat vorhanden.
Die Listenoperationen (+, .rest etc.) werden nicht umbenannt(sie bekommen nur die neuen Sorten als Argumente)
155
Strukturierte Spezifikation:
Nichtfreie Datentypen
156
Nichtfreie Datentypen: der typische Fehler
Orderedlist =enrich List3 withpredicates
. < . : elem × elem ;ordered : list ;
axioms¬ a < a; a < b ∨ a = b ∨ b < a;a < b ∧ b < c → a < c;ordered([]); ordered(a + []);ordered(a + b + l) ↔ a < b ∧ ordered (b + l);
end enrich
NICHT ∀ l. ordered(l) addieren!!! Das wäre INKONSISTENT!!!
Allgemein: Ein generierter Datentyp enthält immer alle Konstruktorterme.Man kann nicht nachträglich welche ausschliessen. Man kann nur einennichtfreien Datentyp bilden, der Terme identifiziert
157
Spezifikation nichtfreier Datentypen
• Spezifikationen nichtfreier Datentypen werden sehr leicht inkonsistentoder uneindeutig
• Konstruiere nichtfreien Datentyp durch Zusammenfassung von denTermen, die die gleichen Elemente repräsentieren sollen, in Klassen
• Deshalb als erstes nach der Bestimmung der Konstruktoren:Definiere Gleichheit durch Extensionalitätsaxiom: x = y ↔ ϕ(x, y)
• Dann: die in ϕ definierten Operationen werden rekursiv definiert
• damit: monomorph: höchstens ein Datentyp spezifiziert
• Vorsicht: rek. Def. kann inkonsistent sein!
• Jetzt: Arrays, im Praktikum: Mengen (einfacher)
158
Beispiel: Arrayspezifikation, Teil 1
Array=specification
using Nat; Elem;sorts array;functions
mkar : nat × elem → array;. [ . , . ] : array × nat × elem → array;. [ . ] : array × nat → elem;# . : array → nat;
inductionarray generated by mkar, . [ . , . ];
variables d : elem; a, a’ : array;
159
Beispiel: Arrayspezifikation, Teil 2
Festlegungen:
• Konstruktor mkar(n, d) bekommt Initialelement d(Alternative: unspezifizierte Initialisierung)
• Für m ≥ # a ist Selektion a[m] unspezifiziert
• Für m ≥ # a ist Modifikation Identität: a[m,d] = a.
axiomsa = a’ ↔ # a = # a’ ∧ ∀ n. n < # a → a[n] = a’[n];
# mkar(n,d) = n; # a[m , d] = # a;
m < n → mkar(n,d)[m] = d;
m < # a → a[m , d][m] = d; n 6= m → a[m , d][n] = a[n];end specification
160
Inkonsistente rekursive Definition
• Annahmen:⋆ Mengen von nat. Zahlen definiert⋆ Die Mengen sind von ∅ und insert generiert⋆ Für Mengen gilt: insert(a,insert(a,∅)) = insert(a,∅)
• Rekursive Definition:sum(∅) = 0,sum(insert(a, s)) = a + sum(s)
• Inkonsistent, da aus insert(1,insert(1,∅))) = insert(1,∅) folgt:2 = sum(insert(1,insert(1,∅))) = sum(insert(1,∅)) = 1
• Korrekte Definition:sum(∅) = 0,¬ a ∈ s→ sum(insert(a, s)) = a + sum(s)(im Fall a ∈ s ist insert(a, s) = s)
• Operation sum muss mit der Definition der Gleichheit auf Mengen,i.e. dem Extensionalitätsaxiom verträglich sein!
161
Anforderungen an nichtfreie Datentypen
• Semantische Überlegungen zur Spezifikation nichtfreier Datentypen:⋆ Es gibt den Datentyp ⇒ Konsistenz (wenn Axiome für den
intendierten Datentyp gelten)⋆ Die im Extensionalitätsaxiom durch ϕ beschriebene Relation muss
wenigstens Äquivalenzrelation sein:− Reflexivität: ϕ (a, a)− Kommutativität: ϕ (a, b) → ϕ (b, a)− Transitivität: ϕ (a, b) ∧ ϕ (b, c) → ϕ (a, c)
• Für gleiche Konstruktorterme t1, t2 muss Operation f dasselbe liefern:ϕ (t1,t2) → f(t1) = f(t2)⇒ Beweisverpflichtungen; genaueres: siehe Modulversuch!
• Äquivalenzrel. + Verträglichkeit = Kongruenz
162
Korrekte Spez. der geordneten Listen (1)
Orderedlist = specificationsorts elem; ordlist;constants [] : ordlist;functions
. + . : elem × ordlist → ordlist ;min : ordlist → elem ;butmin : ordlist → ordlist ;
predicates
. < . : elem × elem ;variables
a, b, c : elem;l, l ′ : ordlist;
inductionordlist generated by [], +;
163
Korrekte Spez. der geordneten Listen (2)
axioms¬ a < a; a < b ∨ a = b ∨ b < a;a < b ∧ b < c → a < c;
l = l′ ↔ l = [] ∧ l’ = []∨ l 6= [] ∧ l’ 6= []
∧ min(l) = min(l′)∧ butmin(l) = butmin(l′);
min(a + []) = a;a < b → min(a + b + l) = min(a + l);¬ a < b → min(a + b + l) = min(b + l);
butmin(a + []) = [];a < b → butmin(a + b + l) = b + butmin(a + l);¬ a < b → butmin(a + b + l) = a + butmin(b + l);
end specification
164
Noethersche Induktion
165
Noethersche Induktion (1)
Definition (noethersche Relationen)Sei ≪ ⊆ A×A. Die Relation ≪ heißt noethersch (oder wohlfundiert, engl.well-founded) wenn es keine unendlichen ≪-Ketten gibt:
. . .≪ a3 ≪ a2 ≪ a1 ≪ a0
Satz (Ordnungsprädikate)Ordnungsprädikate von Datendefinitionen sind noethersch in jedem Modellder Spezifikation.
166
Noethersche Induktion (2)
Satz (noethersche Induktion)Für noethersche Relationen ≪ gilt:Wenn für jedes a aus E(a′) für alle Elemente a′ ≪ a die Aussage E(a)gefolgert werden kann, so gilt E für alle Elemente:
(∀ a. (∀ a′. a′ ≪ a⇒ E(a′)) ⇒ E(a)) ⇒ ∀ b. E(b)
Definition (noethersche Induktionsregel)Sei y := free(Γ ⊢ ∆) \ {x} und ≪ noethersch. Induktion über x:
IND(≪)
∀ y.∀ x′. x′ ≪ x→ (∧
Γ →∨
∆)x′
x ,Γ ⊢ ∆
Γ ⊢ ∆
167
Noethersche Induktion (Beispiele)
Beispiel: Natürliche Zahlen
∀ n0. n0 < n→ ϕ(n0) ⊢ ϕ(n)
⊢ ∀ n. ϕ(n)
Beispiel: Listen
∀ l0. (l0 ≪ l) → ϕ(l0) ⊢ ϕ(l)
⊢ ∀ l. ϕ(l)
168
Noethersche Induktion (Beispielprädikate)
Größenordnung:Sei size : s→ nat . Dann ist ≪ noethersch mit
x≪ y :↔ size(x) < size(y).
Lexikalische Ordnung:Betrachte Spezifikation Pair2 von vorher. Seien <1 : elem1 × elem1 und <2 :elem2 × elem2 noethersch. Dann auch ≪ mit
mkpair(a, b) ≪ mkpair(a′, b′) :⇔ a <1 a′ ∨ (a = a′ ∧ b <2 b
′).
Untermengenordnung:Seien s, s′ zwei endliche Mengen (Spezifikation später). Dann ist
s ⊂ s′ ↔ s ⊆ s ∧ s 6= s′
noethersch, da s ⊂ s′ → card(s) < card(s′).
169