Neuer Aufgabentyp `ComposeFormula`

[nimec01]

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:

data TreeDisplayMode = FormulaDisplay | TreeDisplay deriving (Show,Eq)

data ComposeFormulaConfig = ComposeFormulaConfig {
      syntaxTreeConfig :: SynTreeConfig
    , treeDisplayModes :: (TreeDisplayMode, TreeDisplayMode)
    , extraHintsOnSemanticEquivalence :: Bool
    , extraText :: Maybe (Map Language String)
    , printSolution :: Bool
    } deriving (Typeable, Generic)

Eine Default-Config könnte so aussehen:

defaultComposeFormulaConfig :: ComposeFormulaConfig
defaultComposeFormulaConfig = ComposeFormulaConfig
    { syntaxTreeConfig = defaultSynTreeConfig
    , treeDisplayModes = (TreeDisplay, TreeDisplay)
    , extraHintsOnSemanticEquivalence = True
    , extraText = Nothing
    , printSolution = False
    }

Eine konkrete Instanz verfügt über die folgenden Werte:

data ComposeFormulaInst = ComposeFormulaInst
               { operator :: BinOp
               , leftTree :: SynTree BinOp Char
               , rightTree :: SynTree BinOp Char
               , leftTreeDisplayMode :: TreeDisplayMode
               , rightTreeDisplayMode :: TreeDisplayMode
               , leftTreeImage :: String
               , rightTreeImage :: String
               , addExtraHintsOnSemanticEquivalence :: Bool
               , addText :: Maybe (Map Language String)
               , showSolution :: Bool
               }
               deriving (Show, Typeable, Generic)

Ein Debug-Printout der Aufgabe sieht derzeit so aus:

Stellen Sie sich vor, die beiden angezeigten Bäume/Formeln würden unterhalb eines Wurzelknotens mit Operator ∧ gehängt. Einmal der eine Teilbaum links und der andere Teilbaum rechts, und einmal genau andersherum.
file: /tmp/ed6a0fb4827732b9dcf53703a083531fc53985927d957097ad018884b5e51e4935adf5a82aa3a815e4e52cb90e718026f54c04f9.svgfile: /tmp/tree-8b8aa99be5e59cb0fa14d56d6278dadadb77c7522d0f58ddf65facd74dd2f7bd236d806890010adf154bfe34fbd87e47ca87c804.svg
Geben Sie für die beiden entstehenden Bäume jeweils die dadurch repräsentierte Formel ein.
(Dabei dürfen Sie beliebig viele zusätzliche Klammerpaare hinzufügen.)
Hinweise: Es müssen die exakten Formeln der Syntaxbäume angegeben werden. Andere, selbst zu dieser Formel semantisch äquivalente Formeln sind keine korrekte Lösung! Auch dürfen Sie 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))> <<<<

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.

[jvoigtlaender]

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.

[jvoigtlaender]

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.

[jvoigtlaender]

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.)

[jvoigtlaender]

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).

[jvoigtlaender]

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.

[jvoigtlaender]

Neuer Vorschlag:

• Eingabe erfolgt in Form [ A /\ B, B /\ A]
• Erklärungen zu diesem Format werden ähnlich wie oben auf modelling-tasks verwiesen gegeben
• geparset wird die Eingabe mittels des vorhanden List-Parsers (es werden also auch kürzere und längere Listen eingelesen)
• in partialGrade wird die Liste erst genubed, dann geprüft, ob sie genau zweielementig ist; andernfalls wird es als Syntaxfehler zurückgewiesen ("Sie sollen genau zwei verschiedene Formeln eingeben.")

[nimec01]

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)]> <<<<

[jvoigtlaender]

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.