jvoigtlaender
commented
2 months ago Verfeinerter Vorschlag:
In https://github.com/fmidue/logic-tasks/blob/8a9537b528e0981a048688b0df4f68cff07b3356/src/Tasks/SynTree/Config.hs#L24-L35 wird allowArrowOperators :: Bool durch etwas wie operatorFrequencies :: { ... } ersetzt, wobei der Record dort jeweils einen Int-Eintrag für jeden Operator aus https://github.com/fmidue/logic-tasks/blob/8a9537b528e0981a048688b0df4f68cff07b3356/src/Trees/Types.hs#L24 enthält.
Typische Default-Konfigurationswerte wären dann "alles Eins" für Fälle, wo bisher allowArrowOperators = True oder "nur für And und Or Eins" für Fälle, wo bisher allowArrowOperators = False. Aber es könnte bei Bedarf eben auch abweichend gewichtet werden.
Zu entscheiden wäre noch, ob auch die Häufigkeit des Auftretens von Negation mit einbezogen werden soll.
Natürlich ergibt sich einiges an Änderungsnotwendigkeiten an existierendem Generator-Code.
Aspekte wie "LegalProposition sollte kein <= benutzen" ließen sich einbringen, indem der Config-Checker für diesen Aufgabentyp einfach nicht erlaubt, dass für BackImpl ein positiver Wert gesetzt ist.
Andersherum müsste bei bestimmten Aufgabentypen sichergestellt werden, dass beim Konfigurieren nicht zu viele (oder die falschen) Operationen ausgeschlossen werden. Zum Beispiel weil es sonst passieren könnte, dass folgende Bedingung nicht mehr erfüllbar ist: https://github.com/fmidue/logic-tasks/blob/8a9537b528e0981a048688b0df4f68cff07b3356/src/Tasks/DecomposeFormula/Quiz.hs#L23
in verschiedenen Aufgabentypen kommt neuerdings
<=vor und das zudem in relativ hoher Häufigkeitbeim Lösen des Aufgabentyps
LegalPropositionkönnte sich zudem gefragt werden, ob das nicht bereits ein Fehler ist, da man die Implikation nur in die andere Richtung kennengelernt hatAllgemein kann die Verwendung von zwei möglichen Implikationsrichtungen dazu führen, dass beim Übersetzen von natürlichsprachlichen Sätzen zu Formeln sich angewöhnt wird, die Implikation die zur Satzstruktur passt, zu wählen und nicht logisch umzustellen. Bsp.: Man benötigt einen Schirm, wenn es regnet. --> bedeutet Nutzung von: <=, und bei Vertauschung von Haupt- und Konditionalsatz entsprechend: =>.
Dadurch wird nicht "richtig" gelernt den Satz/ die Formel umzustellen. (in Vergangenheit wurde die "Implikation in die andere Richtung" vereinzelt selbstständig von den Studierenden eingeführt, um zu vermeiden, die Symbole in einer anderen Reihenfolge als diese im natürlichsprachlichen Satz vorkommen, schreiben zu müssen)
Vorschlag: Die Häufigkeit des <= Operators könnte feinkörniger konfiguriert werden.