Closed nimec01 closed 3 months ago
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 <=>
.
Ich denke, es sollte per config checker noch geprüft werden, dass hier immer minUniqueBinOperators > 0
gesetzt ist. Und ebenso beim ComposeFormula
-Typ.
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.
(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.)
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. BeiComposeFormula
sogar explizit auch in der default config: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.
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.
For mirror
to make sense in general, probably #29 should be done first.
Fügt den Aufgabentyp
DecomposeFormula
wie in #112 beschrieben ein. Analog zuComposeFormula
werden erstmal keine Pfeiloperatoren benutzt.