Kann man Punkt 5.4 ohne Ord lösen?
Um zu überprüfen, ob es sich bei einem Teilbaum um einen Suchbaum handelt verwenden wir die Methode von 5.1, wodurch wir natürlich auch die Ordnungsrelation benötigen.
Deshalb schaut unser Konstruktor so aus:
maxSearchTreeSum :: (Ord a, Num a) => (Tree a) -> a
In der Angabe steht aber nur Num, weshalb ich mich frage, ob das ein Fehler in der Angabe ist, oder ob wir irgendwas übersehen haben.
Um mal wieder zum Topic zurückzukommen. Weiß jemand die Antwort auf die Multiple Choice Frage
"Wenn es prinzipiell eine Lösung gibt, dann wird diese auch von einem rationalen Agenten gefunden."
Ich würde mal sagen im Allgemeinen Nein, weil das von der Vorgangsweise/Strategie des Agenten abhängt.
Edit: Hat sich erledigt, in den Folien steht eh "Rational != successful", daher ist die Antwort wohl Nein.
ich würd schreiben:
Ex A(x) => (!B(x) ^ !T(x))
Nachdem ^ das "main connective" für E ist würd ich
Ex A(x) ^ (!B(x) ^ !T(x))
schreiben. Mit => wäre die Aussage auch wahr, wenn es gar kein Tier ist, aber wir wollen ja eine Aussage über Tiere treffen. (Bin mir aber natürlich auch nicht ganz sicher)
In den Folien steht "Problem: Satisfiability (consistency) of the CWA". Da steht also schon vor der Klammer, dass damit einfach satisfiable gemeint ist. 
Außerdem würde ich sagen, dass die CWA in jeglicher Hinsicht geschlossen ist. (immerhin haben wir mit Cn(T u Tasm) alles drinnen was unter der CWA ableitbar ist)
für 2.3 (a) mit par.plan bekomme ich
planlength = 4 => 8
planlength = 5 => 640
planlength = 6 => 17256
stimmt leider nicht mit der Angabe von AFDia überein.
kann das noch jemand bitte verifizieren.
Ich hab mir meine Lösung nochmal angeschaut und bin auf folgendes gestoßen:
Bei der Fragestellung
Quote(p4) Unterschiedliche Krüge dürfen nicht gleichzeitig in einen Krug als Auffangbehälter geleert werden.
habe ich bei der nonexcecutable Regel hinten ein jug(R) angehängt, weil steht, dass unterschiedliche Krüge nur nicht gleichzeitig in einen Krug als Auffangbehälter geleert werden dürfen. (Gleichzeitiges ausleeren am Boden ist zb erlaubt)
Wenn ich das rauslösche komm ich auf dein Ergebnis (wobei ich aber denke, dass meins richtig ist, weil sich mehr Möglichkeiten ergeben wenn man zB gleichzeitig am Boden ausleeren darf).
Ich komme auf die selben Ergebnisse wie blueroot.
Damit man besser vergleichen kann, ob die Programme funktionell richtig sind, hab ich auch jeweils etwas längere Pläne getestet und poste mal meine Ergebnisse:
Kommt ihr da auf dasselbe?
Übrigens gibts wieder ein Abgabeblatt dass man ausfüllen muss.
Raven: In den Gesamtsystemtests sieht man es leider nicht. Ich hatte auch das Problem, dass richtige Diagnosen leer waren und falsche immer alle 4 Komponenten lieferten.
Bei mir waren es folgende 2 Fehler wenn ich mich richtig erinnere:
1.) Hatte ich den selben Fehler wie Gerd:
Quote from Gerd_4DDisplay More% wenn s von i1=1 und s von i3 = 0 oder wenn beide 1 sind wird weitergleietet.
t(V,o1,T):- valve(V), d(V,i2,heat), s(V,i1,1), s(V,i3,1), t(V,i1,T), not ab(V).
t(V,o1,T):- valve(V), d(V,i2,heat), s(V,i1,1), s(V,i3,0), t(V,i1,T), not ab(V).
Bei mir kamen bei einer Diagnose alle vier Komponenten als einzelstörmöglichkeit heraus. Erst als ich beide FOrmeln durch die hier ersetzt habe hat es ufnktionirt:
%Wenn s von i1 vorhanden leite diesen weiter
t(V,o1,T):- valve(V), d(V,i2,heat), s(V,i1,1), t(V,i1,T), not ab(V).
2.) Hab ich manchmal bestimmte Dinge aus der Angabe nicht 1 zu 1 umgesetzt, sondern versucht zu vereinfachen, weil eh das selbe Ergebnis rauskommen sollte. Das Problem ist, dass die Fehlerfälle, die bei der Diagnose wichtig sind teilweise aber dadurch verändert wurden.
Kurz gesagt: Schau dir die formalen(!) Beschreibungen des Verhaltens der einzelnen Komponenten nochmal genau an und implementiere es genau so!
Das heißt nicht Text lesen und interpretieren, wie es gehen könnte (selbst wenn das Gesamtsystem geht, stimmen die Diagnosen nicht alle) sondern setze wirklich 1zu1 die angeführten Formeln um.
Das hat bei mir geholfen.
Display MoreHat mitlerweile schon jemand ein Programm welches bei folgendem Fehlerfall nur ab(v) liefert?
ambient_t(23).
in_t(air_in,26).
in_s(air_in,1).
in_d(threeway_in,heat).
in_d(scale_in,3).
out_t(air_out,56).
out_s(air_out,0).
Wenn ja würde mich sehr interessieren ob ihr da irgendwas extra eingefügt habt (z.b. irgendwelche speziellen zusätzlichen constraints), oder ob es bei euch einfach so funktioniert...
THX
Das würde mich auch brennend interessieren. Alles andere geht soweit schon, aber dieses Beispiel (und allgemein alle Bsple die am Ausgang 0 aber nicht die Umgebungstemperatur haben) bereiten mir Kopfzerbrechen.
Mal was anderes: Im TUWIS Forum hat jemand geschrieben, dass er 62 Files hat. Ich hab extra nochmal nachgezählt und komme nur auf 57 Files die in der Angabe angesprochen werden und ich hab auch genau 57 Files. Hab ich da was übersehen?
Zu guter Letzt versuch ich die Frage aus 1.3.2 zu beantworten:
Ein Fehlerfall von s oder von v könnte jede mögliche Fehlersituation erklären. Der Grund dürfte einfach sein, dass keine Alternative um die beiden Komponenten herumführt und dass sie immer wirklich gebraucht werden. (heater und combi werden abwechselnd gebraucht und können daher nur bestimmte Eingabe-Ausgabe Kombinationen verfälschen)
Hat sich sonst schon jemand Gedanken über die Frage gemacht bzw eine andere Antwort als ich gefunden?
Alles klar, danke!
Für alle die damit noch Verständnisprobleme haben, dieser Link hat mir auch weitergeholfen:
http://www.screenav.de/avc_doc…d/principle_viewplane.htm
Auch wenn man die Normals jetzt theoretisch noch nicht braucht - man kann Dich beim Gespräch fragen, wie der Transformations-Vorgang der Normalen funktioniert, und da tust Du dir sicher leichter, wenn Du es schon implementiert hast - einfach schon deshalb, weil du es anhand deines Codes erklären kannst.
Na gut, dann werd ich es wohl doch gleich machen. 
Blöde Frage, aber macht es etwas aus, wenn wir in der transform(...) Methode vorerst (bis Bsp5) die Normalvektoren komplett auslassen?
In der Angabe steht:
QuoteUm im 5. Beispiel korrekte Beleuchtung zu ermöglichen, müssen spätestens dort auch die Normalvektoren richtig transformiert werden. Es empfiehlt sich jedoch, dies jetzt (oder im nächsten Beispiel) schon zu tun.
Für mich heißt das, dass ich mich da ruhig erst beim Bsp4 oder 5 darum kümmern kann und trotzdem keine Probleme beim Abgabegespräch bekommen werde. Stimmt das soweit oder gibts da beim Abgabegespräch nach dem Bsp 3B Punkteabzüge oder ähnliches?
Sorry aber das lässt mir momentan noch keine Ruhe.
fault1.obs kann ich schon mal bestätigen
fault2.obs da gibt er mir c auch dazu... ich werd noch mal drüber nachdenken
Evtl hast du ja denselben Fehler wie Gerd und ich gemacht.
Quote from Gerd_4DDisplay More% wenn s von i1=1 und s von i3 = 0 oder wenn beide 1 sind wird weitergleietet.
t(V,o1,T):- valve(V), d(V,i2,heat), s(V,i1,1), s(V,i3,1), t(V,i1,T), not ab(V).
t(V,o1,T):- valve(V), d(V,i2,heat), s(V,i1,1), s(V,i3,0), t(V,i1,T), not ab(V).
Bei mir kamen bei einer Diagnose alle vier Komponenten als einzelstörmöglichkeit heraus. Erst als ich beide FOrmeln durch die hier ersetzt habe hat es ufnktionirt:
%Wenn s von i1 vorhanden leite diesen weiter
t(V,o1,T):- valve(V), d(V,i2,heat), s(V,i1,1), t(V,i1,T), not ab(V).
Danke für die Antwort!
Nochmal zu den Unklarkeiten:
Bei dp war meine Kernaussage, dass solange das Objekt vor der Kamera ist und zprp=0 folgendes gilt: dp ist immer positiv (und zvp negativ).
Erst wenn das Objekt hinter der Kamera ist, wird dp negativ (und zvp positiv).
Wenn das stimmt, dann denke ich, dass ichs verstanden habe.
@zvp: Um bei deinem Auge-Beispiel zu bleiben. Ich hätte mir das ganze eher so vorgestellt:
zprp ist das Auge, das heißt der Punkt von dem aus ich das Objekt anschaue. Wenn ich im Koordinatensystem bin welches ich vom Auge selbst ausgehen lasse (das View-Koordinatensystem sozusagen), dann ist zprp auch immer 0 wie im Beispiel.
Die viewPlane würde ich dann genau dorthin legen, wo ich mit meinem Auge hinfokusiere. Schaue ich zB den Monitor an, würde ich die ViewPlane genau darauf legen. Wenn ich weiter zurück gehe ist der Monitor weiter weg und zvp wäre niedriger als vorher.
Ist die Vorstellung soweit richtig (abgesehen davon dass das Auge bzw die Kamera im Bsp sich nie ändert, sondern immer nur die Welt drumherum)? Mich verwirrt es nur, dass du die Viewplane auf der Netzhaut ansetzt, aber nachdem auf der Netzhaut ja genau das Bild ist was auf der von mir beschriebenen ViewPlane liegt, denke ich, dass wir dasselbe meinen.
Stimmt das so oder lieg ich vollkommen daneben und zvp und zprp liegen genau umgekehrt?
Edit:
Nachdem ich jetzt schon weiter mit dem Programm bin und noch etwas nachgelesen habe, versuche ich nochmal ganz einfach zu definieren, was die view plane ist:
Wenn man auf ein 3D Objekt schaut bekommt man natürlich ein 2D Bild. In diesem 2D Bild wird allerdings die Perspektive nicht berücksichtigt. Die View Plane ist dann einfach ein 2D Bild welches die Perspektive beinhaltet.
Das heißt im Endeffekt dass der Schritt "Viewingkoordinaten -> Projektionskoordinaten" einfach nur die Perspektive in das 2D Bild einfügt und das Ergebnis nennt sich dann View Plane.
Ist es wirklich so einfach?
Mit heat, cool und off hast du schon recht, das wird eigentlich eh implizit überprüft und wenns ein anderer Wert ist, wird eh nicht weitergemacht. Aber da bleiben noch immer die anderen Überprüfungen. Ich hab mal im TUWIS Forum nachgefragt, ob es nötig ist wirklich immer alles zu prüfen. Wahrscheinlich wäre es eh am besten 1x pro {s,h,c,v}.dl File zu überprüfen ob die allgemeinen Bedingungen erfüllt sind und dann in jeder Regel ein valid(X) einzufügen, sodass die Regel nur feuert, wenn die allgemeinen Überprüfungen korrekt waren ... naja warten wir mal die TUWIS Antwort ab.
Zu deinem Beispiel:
Genau denselben Fehler hatte ich auch bei meiner Diagnose und ich verstehe ebenfalls nicht, warum das falsch ist.
Deinen Testfall hab ich mal bei mir ausprobiert und bin auch auf s v h gekommen, aber ich würde auch sagen, dass nur v richtig wäre.
Die einzige Möglichkeit bei "heat" dass der Status von o1 von v gleich 0 ist, ist dass die Eingangsrohre auch 0 sind. Wenn die Eingangsrohre aber 0 sind, müsste v die Umgebungstemperatur liefern und das wollen wir ja nicht.
Ich würde mal sagen, dass wir wahrscheinlich schon wieder genau denselben Fehler im Programm haben und am besten auf andere Antworten warten sollten. 
Überprüft ihr eigentlich irgendwelche Grenzen die nicht für die Fallunterscheidung nötig sind (zB dass die Temperatur immer zwischen 0 und 60 ist oder dass der luftstrom nur 0 oder 1 sein kann etc) und kann man überhaupt überprüfen, ob threeway_in den Wert "heat","cool" oder "off" hat? Soweit ich weiß kann man doch nur Zahlen einschränken oder?
Ich hab am Anfang zumindest alle Zahlen überprüft, aber genau dadurch hatte ich im Endeffekt einen Fehler im Programm (bei der Diagnose), darum gibts jetzt keine Überprüfungen mehr in meinem Programm.
Weiß da irgendjemand mehr, ob das nötig ist oder nicht?
Nachdem ich sehr viele alte Forenthreads durchstöbert habe, bin ich teilweise unsicherer als vorher.
Kann mir jemand der sich damit auskennt bitte sagen, ob ich die folgenden Begriffe richtig verstanden habe:
zprp: Die z-Koordinate des Projektionszentrums, das heißt des Punktes, auf den projeziert werden soll. In unserem Fall ist das die Kamera.
zvp: Die z-Koordinate der View Plane. Die View Plane ist die Ebene die wir sehen wollen, das heißt der Bildausschnitt auf den die Kamera schaut. Nachdem wir mit den Viewingkoordinaten arbeiten, ist zvp immer negativ, wenn das Objekt vor der Kamera liegt.
dp: Die Distanz von zprp zu zvp. Nachdem zprp immer näher an der Kamera liegt als zvp (zprp ist ja genau dort wo die Kamera ist), und Objekte die weiter wegrücken einen niedrigeren zvp Wert haben als nahe Objekte (wir schauen auf die negative z-Achse), ist dp immer positiv, solange die Objekte die wir betrachten vor der Kamera liegen (weil zvp immer ein negativer Wert ist wenn Objekte vor der Kamera liegen und 0 - zvp im Endeffekt dann ein positiver Wert ist).
Zum Abschluss noch kurz zu den Variablen nearPlaneZ und farPlaneZ
nearPlaneZ: die nahe an der Kamera liegende Clippingebene. Das heißt (nachdem bei uns zvp = nearPlaneZ gilt) alles was näher als zvp an der Kamera liegt kann geclipped (also nicht angezeigt) werden.
farPlaneZ: die in der Ferne liegende Clippingebene. Diese clipped alle Objekte die zu weit weg von zvp bzw von der Kamera liegen.
Ich bin bei der Implementierung von setupProjection noch nicht all zu weit, aber ich wüsste gerne, ob ich das soweit richtig verstanden habe, bevor ich großartig weitermache und dann was falsches zusammencode.
Danke für die Hilfe!
Du hast den Text aus der Angabe kopiert, richtig?
Ersetz mal alle ":−" durch ":-", dann gehts.
Übrigens: Hat jemand schon die 2 Fehlerfälle von 1.3.2 korrekt diagnostiziert und kann mal die Lösung posten?
Bei mir gehts wie oben beschrieben leider noch immer nicht (obwohl jetzt zumindest meine eigenen Testfälle gehn), aber ich hab versucht die 2 Beispiele im Kopf durchzugehen und bin auf folgendes gekommen:
Fehlerfall1:
Diagnosis: ab(c)
Diagnosis: ab(s)
Diagnosis: ab(v)
Fehlerfall2:
Diagnosis: ab(s)
Diagnosis: ab(h)
Diagnosis: ab(v)
Kann das jemand bestätigen? (evtl sogar mit einem funktionierenden DLV Programm )
Es geht bei mir zwar noch immer nicht alles, aber ich bin draufgekommen, dass scheinbar folgende Regel bei der Diagnose Probleme verursacht:
Beim normalen Testen (Aufgabe 1.2.3) nimmt er die Regel problemlos an, aber bei der Diagnose funktioniert es nur, wenn ich OX aufsplitte in o1 und o2 und die Regel zweimal anschreibe.
Weiß jemand, warum die "Kurzform" einen Fehler bei der Diagnose auslöst, aber zwei extra geschriebene Formeln nicht? Irgendwie ergibt das für mich wenig Sinn ... (oder der Fehler sitzt eh noch wo anders und wurde nur zufällig durch diese Änderung beeinflusst)
Ich bin echt am Verzweifeln mit der Diagnose ...
Bei mir funktionieren alle Tests aus 1.1 und 1.2 problemlos, aber sobald ich die Diagnose mache, gibts Probleme.
Es gehen nicht mal mehr alle eigenen Testfälle, die vorher problemlos gingen.
Zum Beispiel liefert die Diagnose für folgenden (korrekten) Code:
connect.test2.obs
sowohl bei -FRmin als auch -FRsingle das Ergebnis
Kann mir irgendwer bitte einen Tipp geben, woran das liegen kann? Wie gesagt das Beispiel funktioniert schon wunderbar, wenn man es mit "connect.tester.dl" aus 1.2.3 testet, aber sobald ich die Diagnose versuche gibts Probleme.
Folgende Änderungen hab ich für die Diagnose durchgeführt:
1.) Ich hab in {s,h,c,v}.dl in jeder Regel ein "not ab(X)" wobei X der jeweilige Komponentenname ist.
2.) components.hyp ist nur eine Auflistung aller vier ab()s ... wie in den Folien
3.) constraints.dl ist sowieso aus den Testfiles kopiert nur zu constraints umgeformt (linke Seite also leer)
4.) Bei den Testfällen hab ich "expect_" rausgelöscht.
Hab ich irgendwas nicht beachtet? Bis jetzt ging das Beispiel problemlos voran und gerade bei dem Schritt, wo man eigentlich nur Kleinigkeiten ändern muss hänge ich seit Stunden. 
Sicherheitshalber poste ich noch den dlv Aufruf, falls dieser falsch ist (kanns mir aber net vorstellen):
Falls mir jemand helfen könnte wäre das wirklich sehr nett!
