TU Wien:Einführung in wissensbasierte Systeme LU (Fink)/Test 2010-01-27

1. Teil Diagnose: (15 pkt)

• 1a) (6 pkt) gegeben P={avb:-}, Q= {a:- not b, b:- not a} , R={a:-b,b:-a}
• gesucht: answersets von
• P
• Q
• P U R (Vereinigt)
• b) (3 pkt) Was versteht man unter einer konsistenzbasierten Diagnose <H,T,O> ? (so aehnlich)
• c) (2 pkt) Frage, ob in DLV Disjunktionen in den Regeln erlaubt sind (es war glaub ich genauer, entweder -koepfen oder -koerpern oder ueberhaupt spezielle Regeln) (ja / nein)
• d) (4 pkt) Subtrahierer definieren, der wenn er nicht defekt ist und auf Eingang1 V1 anliegen hat und auf Eingang2 V2 auf seinem Ausgang V1 - V2 ausgibt sofern V1 - V2 >= 0

gegeben hatte man um das darzustellen folgende Prädikate: in1(C,V1), in2(C,V2), sub(C), out(C,V), ab(C)

• (in1 = input eingang 1, sub bedeutet C ist ein subtrahierer, ab bedeutet C ist defekt)

Teil 1 Lösungen

Answerset von

P = {a v b} // Da hier keine Prämisse vorhanden ist, ist der Kopf immer herleitbar
Q = {a},{b} // 2 mögliche Answer-Sets, entweder a, oder b. {a,b} ist nicht möglich
R = {a,b}   //

Die teile der konsistensbasierten Diagnose sind folgende:

• Hypothese (H) - Ein Set an Grundatomen (informell: "Was ist möglicherweise kaputt"), wobei hier die Prädikate ab(.) heißen (für abnormal(.)).
• Theorie (T) - Ein logisches Programm (informell: "Wie funktioniert mein System")
• Beobachtungen (Observations, O) - Ein Set an Grundliteralen (informell: "Was habe ich tatsächlich beobachtet")

Die konsistensbasiertes Problem ist jetzt das Tripel P = <H,T,O>. Und gegeben P, dann ist die konsistenzbasierte Diagnose $S\subseteq H$, sodass $T\cup O\cup S\cup \{\neg h|h\in H\setminus S\}$ konsistent ist. Oder wiederum informell: Die Vereinigung von Theorie, Beobachtungen, Diagnose, und das Negat aller in der Hypothese vorkommenden Atome, die nicht in der Diagnose aufscheinen, müssen konsistent sein. Sprich, wenn man alle Informationen inklusive der Lösung zusammenwirft, muss das Endresultat konsistent sein und keinen Widerspruch beinhalten.

In DLV sind Disjunktionen zwar erlaubt, aber nur im Kopf. Sprich alle Literale im Körper einer Regel sind mit einer Konjunktion verknüpft, alle Literale im Kopf sind mit einer Disjunktion verknüpft. Ähnlich wie in Prolog kann man aber eine Disjunktion mittel mehrerer Regeln realisieren:

P :- A > 3, B > 3.
P :- A < 3, B < 3.

% Definition des Subtrahierers
% Wenn C ein subtrahierer ist, er nicht defekt ist, und V1 und V2 die beiden Eingänge sind, 
% dann ist das Ergebnis out(C,V), die Subtraktion der beiden Eingänge. Weiters muss V1-V2 >= 0 sein.
out(C,V) :- sub(C), not ab(C), in1(C,V1), in2(C,V2), V = V1-V2, V >= 0.

2. Teil Planen (15 pkt)

Blocksworld war gegeben wie in den VO Folien

• Theoriefrage wofür inertial on(B,L) steht (es waren 3 sachen mit ja nein Möglichkeit gegeben in der Form: caused - on(B,L), on(B,L))
• Noch etwas mit ja/nein Möglichkeit im Stile von "Wofür ist <Befehl> eine Abkuerzung?" und dann wieder drei Moeglichkeiten mit ja/nein daneben
• man sollte zum Beispiel above(B, B1) definieren wobei das bedeutet dass ein Block sich über einem anderen befindet (also auch wenn ein Block zwischen a und c liegt ist a über c)
• man musste einen anfangszustand und ein goal definieren ( a liegt auf b b liegt am tisch c liegt am tisch)
• kick definieren (man kann einen block kicken)
• wenn man einen block kickt liegen er und alle blöcke über ihm auf dem tisch
• sagen was man nicht ins prog schreiben darf wenn alles parallel ausführbar sein soll (noConcurrency)
• definieren dass man kick und move nicht gleichzeitig ausführen kann

man musste immer die passenden Befehle (fluent, always, goal usw vor die Befehle schreiben) Es wurden alle Befehle abgedeckt mit der Angabe (caused, executable, nonexecutable, inertial, goal, usw)

Teil 2 Lösungen

Inertia (lat. die Trägheit) verwendet man um darzustellen, das Prädikate, die sich in einer Aktion nicht verändert haben, in dem nächsten Zustand noch immer vorhanden sind (sprich, dass Blöcke nicht einfach verschwinden, oder plötzlich wo anders stehen).

inertial on(B,L).
% Könnte man auch so schreiben:
caused on(B,L) if not -on(B,L) after on(B,L).

above(B,L) könnte man folgendermaßen definieren:

            % Fluent-Typ definieren für above
fluents:    above(B,L) requires block(B), location(L).
            % Alles was aufeinander steht, ist auch übereinander. Z.B. above(C,B), above(B,A).
always:     caused above(B,L) if on(B,L), B<>L.
            % Alles was übereinander steht ist transitiv. Z.B. above(C,A).
            caused above(B,L) if above(B,Z), above(Z,L), B<>Z, Z<>L.

Anfangszustand und Zieldefinition:

initially: 	on(a,b).
		on(b,table).
		on(c,table).
			
%Goals are a conjunction of fluents + optional planlength
goal: 		on(b,c), on(a,b), on(c,table) ? (3)

Kick definieren:

                % Kick-Typ definieren
actions:	kick(B) requires block(B).
                % Kick ist immer ausführbar.
always:         executable kick(B).
                % Effekte eines Kicks beschreiben (der gekickte und alle darüberliegenden Blöcke sind jetzt am Tisch).
                caused on(B,table) after kick(B).
                caused on(X,table) after kick(B), above(X,B).