Fortsetzung `ComposeFormula` & `DecomposeFormula`

[nimec01]

Fügt den Aufgabentyp DecomposeFormula wie in #112 beschrieben ein. Analog zu ComposeFormula werden erstmal keine Pfeiloperatoren benutzt.

[jvoigtlaender]

Dies:

Analog zu ComposeFormula werden erstmal keine Pfeiloperatoren benutzt.

verstehe ich nicht so recht. Sowohl hier als auch in ComposeFormula werden doch Pfeiloperatoren unterstützt. Bei ComposeFormula sogar explizit auch in der default config: https://github.com/fmidue/logic-tasks/blob/2a963e511585edf72ecae02abf875744b959b518/src/Tasks/ComposeFormula/Config.hs#L31-L33

Eingeschränkt wird doch nur, dass an der Wurzel des Baumes kein <= oder => stehen darf. Anderswo dürfen diese Operatoren stehen, und an der Wurzel auch <=>.

[jvoigtlaender]

Ich denke, es sollte per config checker noch geprüft werden, dass hier immer minUniqueBinOperators > 0 gesetzt ist. Und ebenso beim ComposeFormula-Typ.

[jvoigtlaender]

Außerdem wird scheinbar schon beim ComposeFormula-Typ (und hier ist es dann genauso relevant) diese Bedingung aus https://github.com/fmidue/logic-tasks/issues/103#issue-2126905286 bisher nicht berücksichtigt:

• Es wird dafür gesorgt, dass an dessen Wurzel ... die beiden darunter hängenden Teilbäume nicht gleich sind.

Das lässt sich ja mittels suchThat noch in den Generator einbringen. Dann muss allerdings auch noch ein bisschen getestet werden, ob die bisherigen config-constraints für den Aufgabentyp ausreichen. Mit sehr kleinen Setzungen etwa von maxNodes und availableAtoms könnte es ja sein, dass etwa nur Formeln der Art A /\ A möglich sind, also Verschiedenheit von linkem und rechtem Teilbaum nicht erreichbar ist.

[jvoigtlaender]

(Für ComposeFormula wäre der vorige Punkt vielleicht durch Tests aufgefallen, wenn systematisch geprüft würde, ob die in completeGrade ausgegebene Musterlösung auch immer tatsächlich die Überprüfung besteht. Denn in partialGrade wäre diese dann wohl an length (nubOrd sol) /= 2 gescheitert.)

[nimec01]

Dies:

Analog zu ComposeFormula werden erstmal keine Pfeiloperatoren benutzt.

verstehe ich nicht so recht. Sowohl hier als auch in ComposeFormula werden doch Pfeiloperatoren unterstützt. Bei ComposeFormula sogar explizit auch in der default config:

https://github.com/fmidue/logic-tasks/blob/2a963e511585edf72ecae02abf875744b959b518/src/Tasks/ComposeFormula/Config.hs#L31-L33

Eingeschränkt wird doch nur, dass an der Wurzel des Baumes kein <= oder => stehen darf. Anderswo dürfen diese Operatoren stehen, und an der Wurzel auch <=>.

Ja, ich hatte, warum auch immer, im Hinterkopf, dass wir beides ausgestellt hatten.

[jvoigtlaender]

Es sollten bei der Generierung wahrscheinlich noch mehr Sonderfälle (als Gleichheit von t1 und t2) ausgeschlossen werden, damit die Aufgabe nicht manchmal "aus Versehen" gelöst werden kann.

Sei zum Beispiel bei DecomposeFormula zufällig t1 = A /\ A und t2 = B /\ B und die vorgegebene Formel: t1 \/ t2.

Dann sollen die Studierenden eigentlich (A /\ A) \/ (B /\ B) anschauen, das in die beiden Teile zerlegen und dann neu anordnen zu (B /\ B) \/ (A /\ A). Aber zufälligerweise würden sie auch die richtige Lösung erhalten, wenn sie einfach den gegebenen String umdrehen. Ohne das Verständnis der Identifizierung des Root-Symbols etc.

Das liegt hier daran, dass t1 und t2 jeweils für sich genommen spiegelsymmetrisch sind, also mirror t1 == t1 und mirror t2 == t2. Vielleicht gibt es noch ähnliche Auffälligkeiten wenn etwa mirror t1 == t2 oder so, bzw. auch beim ComposeFormula-Aufgabentyp.

Mein Vorschlag nun wäre, bei beiden Aufgabentypen sicherheitshalber zu verlangen, dass gilt: length (nubOrd [t1, t2, mirror t1, mirror t2]) == 4. Die bisherige Forderung t1 /= t2 ist damit natürlich auch schon abgedeckt.

[jvoigtlaender]

For mirror to make sense in general, probably #29 should be done first.