Closed nimec01 closed 5 months ago
Ich bin mir nicht sicher, ob extraHintsOnSemanticEquivalence
hier wirklich gebraucht wird, zumindest in seiner gesamten Auswirkung. Die Sache mit "es werden semantisch äquivalente Formeln eingegeben" (also etwa mit Kommutativität etc.) würde mich hier schon sehr überraschen, wenn es in Studierendenlösungen auftritt. Denn hier ist die Aufgabenstellung wirklich sehr auf die syntaktische Struktur konzentriert. Also es sollte klar sein, dass das mit dem "hänge dies links, dies rechts ein" wirklich heißt, dass man der Struktur treu sein muss, nicht einfach "irgendeine Formel, die dasselbe sagt" einzugeben hat.
Allenfalls der Hinweis mit der Assoziativität müsste wohl einschaltbar bleiben.
Im Instanz-Typ schiene mir statt
, leftTreeDisplayMode :: TreeDisplayMode
, rightTreeDisplayMode :: TreeDisplayMode
, leftTreeImage :: String
, rightTreeImage :: String
dies sinnvoll:
, leftTreeImage :: Maybe String
, rightTreeImage :: Maybe String
Also leftTreeDisplayMode
und rightTreeDisplayMode
müssen nicht abgespeichert werden, aber wenn eines von beiden == FormulaDisplay
wäre, dann ist das entsprechende ...TreeImage
== Nothing
.
Dies:
Anzumerken ist, dass es hier keine Rolle spielt, ob
((~A und ~B) und (D oder C),(D oder C) und (~A und ~B))
oder((D oder C) und (~A und ~B),(~A und ~B) und (D oder C))
als Lösung eingegeben wird.
müsste auf jeden Fall in irgendeiner Weise in den Anzeigetext der Aufgabe mit hinein. Denn sonst kommen mit Sicherheit Rückfragen, weil die Aufgabenstellung als nicht eindeutig empfunden wird.
Wahrscheinlich müsste auch noch explizit gesagt werden (nicht nur durch das Eingabebeispiel signalisiert), dass ein Paar in Kommaschreibweise anzugeben ist. Wobei das selbst nicht unbedingt ein allen Studierender bekannter Begriff ist (leider).
In einer Aufgabe in modelling-tasks
etwa, ist ein verwandter Eingabehinweis so: https://github.com/fmidue/modelling-tasks/blob/2e2dbbc7ba1d2968fb189e13ca65a520d1d95f0c/src/Modelling/PetriNet/Conflict.hs#L191-L209 ... sehr ausführlich. (Und die teilnehmenden Studierenden dort haben schon etwas wie "Mathematische Strukturen" in Komedia oder die ersten Wochen von "Diskrete Mathematik" gehört; beides bei "Einführung in die Logik" für Komedia nicht der Fall.)
Vielleicht ist sogar überhaupt die Verwendung von ( ... , ... )
als Eingabeformat hier ein Problem. Denn die Klammern spielen ja in der Aufgabe ansonsten eine komplett andere Rolle. Das wird manche Studierende in dem Stadium irritieren. Etwa auch wegen dieses Hinweises (der ja aber auch wichtig ist):
(Dabei dürfen Sie beliebig viele zusätzliche Klammerpaare hinzufügen.)
Da wird es Verwirrung geben, was diese "Klammerpaare" sind. Ob damit (auch) die um (formel1, formel2)
gemeint sind, usw.
Vielleicht sollte einfach nicht die Tupelschreibweise verwendet werden. In modelling-tasks
gibt es zum Beispiel eine Aufgabe, die folgendes Eingabeformat verwendet:
Analog könnte die Eingabe hier ja in einer Form wie:
formulas:
- t1 /\ t2
- t2 /\ t1
verlangt werden.
Der relevante Code für die Unterstützung dieses YAML-Formats findet sich dort in src/Modelling/CdOd/NameCdError.hs
, also so Funktionen wie showNameCdErrorAnswer
und parseNameCdErrorAnswer
, zusammen mit import Data.Yaml (decodeEither', encode)
.
Aargh, dann wäre zumindest potentiell problematisch, dass -
auch schon für Negation steht. Ich sehe schon die Rückfragen von Studierenden vor mir, ob denn in
formulas:
- A /\ B
- B /\ A
nicht das erste A
negiert ist, usw.
Neuer Vorschlag:
[ A /\ B, B /\ A]
modelling-tasks
verwiesen gegebenpartialGrade
wird die Liste erst genub
ed, dann geprüft, ob sie genau zweielementig ist; andernfalls wird es als Syntaxfehler zurückgewiesen ("Sie sollen genau zwei verschiedene Formeln eingeben.")So sieht die Aufgabenbeschreibung nach den neusten Änderungen aus (wobei hier (TreeDisplay, FormulaDisplay)
als Einstellung gesetzt ist):
Stellen Sie sich vor, die beiden angezeigten Bäume/Formeln würden unterhalb eines Wurzelknotens mit Operator ∨ gehängt. Einmal der/die eine Baum/Formel links und der/die andere Baum/Formel rechts, und einmal genau andersherum.
file: C:/temp/tree-bf1d5460ffba584809daa6c03d989cd4cd6383406643bc94d35de2cce760f85ed6510a0fe0b75d3456ea36bfd2d49ed8348c8a76.svg <¬¬(A ∨ C)>
Bilden Sie für die beiden entstehenden Bäume die repräsentierenden Formeln und fügen Sie diese in eine Liste ein. Es spielt keine Rolle, in welcher Reihenfolge die Formeln in der Liste stehen.
(Während der Formelbildung dürfen Sie beliebig viele zusätzliche Klammerpaare hinzufügen.)
Hinweis: Sie dürfen bei dieser Aufgabe nicht Assoziativität verwenden, um Klammern einzusparen.
Beachten Sie dabei die folgenden möglichen Schreibweisen:
>>>>Negation: <-, ~, nicht> <<<<
>>>>Und: </\, und> <<<<
>>>>Oder: <\/, oder> <<<<
>>>>Implikation: <=>> <<<<
>>>>Bi-Implikation: <<=>> <<<<
>>>>Ein Lösungsversuch könnte beispielsweise so aussehen: <[(A oder nicht B) und C, C und (A oder nicht B)]> <<<<
Bezogen auf https://github.com/fmidue/logic-tasks/issues/103#issuecomment-1936979125 wäre mein Vorschlag nun erstmal einfach, =>
oder <=
als den an der Wurzel befindlichen Operator auszuschließen.
Wie in #103 vorgeschlagen wird ein neuer Aufgabentyp
ComposeFormula
hinzugefügt. Der aktuelle Stand umfasst aber noch nicht alle erwähnten Features.Die Config-Optionen für den neuen Aufgabentypen sehen so aus:
Eine Default-Config könnte so aussehen:
Eine konkrete Instanz verfügt über die folgenden Werte:
Ein Debug-Printout der Aufgabe sieht derzeit so aus:
wobei die Teilbäume wie folgt aussehen:
Anzumerken ist, dass es hier keine Rolle spielt, ob
((~A und ~B) und (D oder C),(D oder C) und (~A und ~B))
oder((D oder C) und (~A und ~B),(~A und ~B) und (D oder C))
als Lösung eingegeben wird.