Schemer: GeoGebra-Variablen nutzerfreundlich als Wert hinter `=` kodieren

[jurei733]

Hintergrund

Im Zusammenhang mit iqb-berlin/verona-modules-aspect#1050 bzw. dem Kommentar iqb-berlin/verona-modules-aspect#1050 (comment) ist aufgefallen, dass getrackte GeoGebra-Variablen im Coding nicht als nackte Werte ankommen, sondern als Strings im Schema:

ggb_490000 = 429979.167

Die Variable selbst wird im Schemer als VariableInfo mit format: "ggb-variable" geführt und daraus als normale BASE-Variable angelegt. Für Nutzer:innen ist aber nicht naheliegend, dass eine numerische Regel wie NUMERIC_MATCH: 468500 auf diesem Response-Wert nicht matcht, weil der gesamte String nicht numerisch parsebar ist.

Problem

Aktuell muss man wissen, dass GeoGebra-Variablenwerte als String mit Variablennamen, Gleichheitszeichen und Wert geliefert werden. Dadurch ist die naheliegende Bedienung im Schemer fehleranfällig:

• Nutzer:innen sehen/fachlich erwarten einen Zahlenwert.
• Sie legen eine numerische Regel auf den Zielwert an.
• Die Regel matcht nicht, weil der reale Response-Wert z. B. ggb_490000 = 429979.167 lautet.
• Die bessere Lösung über MATCH_REGEX oder fragmenting ist möglich, aber für diesen Spezialfall zu versteckt.

Vorschlag

Der Schemer sollte für Variablen mit VariableInfo.format === "ggb-variable" eine nutzerfreundliche Kodierhilfe anbieten.

Mögliche Umsetzung:

• Im Smart-Schemer/Generieren-Dialog GeoGebra-Variablen gesondert erkennen.
• Eine Option anbieten wie „GeoGebra-Wert hinter = kodieren“.
• Automatisch eine passende Fragmentierung setzen, z. B.:

^ggb_490000\s*=\s*([-+]?\d+(?:[.,]\d+)?)$

• Danach je nach gewünschter Kodierung normale Regeln erzeugen:
  • numerische Regeln (NUMERIC_MATCH, NUMERIC_MIN, NUMERIC_FULL_RANGE, ...)
  • boolesche Regeln (IS_TRUE, IS_FALSE) für GeoGebra-Werte wie ggb_X = true
  • optional String-/Regex-Regeln für nichtnumerische Werte
• Alternativ oder zusätzlich warnen, wenn bei format: "ggb-variable" numerische Regeln ohne Fragmentierung verwendet werden.

Akzeptanzkriterien

• Der Schemer erkennt format: "ggb-variable" und bietet eine spezifische Kodierhilfe an.
• Für numerische GeoGebra-Werte kann eine Nutzerin einen Zielwert eingeben, ohne manuell Regex/Fragmentierung kennen zu müssen.
• Die erzeugte Codierung extrahiert den Wert hinter = und verwendet danach passende numerische Regeln.
• Boolesche GeoGebra-Werte wie ggb_PunktRichtig = true/false bleiben sinnvoll kodierbar.
• Es gibt mindestens einen Testfall mit einem Response-Wert wie ggb_490000 = 429979.167, der zeigt, dass die generierte Regel korrekt matcht.
• Die bestehende Behandlung normaler string- und integer-Variablen bleibt unverändert.

Abgrenzung

Dieses Ticket betrifft die Bedienbarkeit und Regelerzeugung im Schemer. Das Status-/UNSET-Verhalten von GeoGebra-Variablen wird bereits separat in #174 bzw. in Aspect behandelt.

[jurei733]

Umgesetzt in PR #199: #199

Enthalten ist:

• Erkennung von Variablen mit format: "ggb-variable" im Schemer-Generator.
• Standardmäßig aktivierte Extraktion des GeoGebra-Werts hinter = per Fragmentierung.
• Auswahl, ob der extrahierte Wert als Zahl, Wahr/Falsch-Wert oder Text kodiert werden soll.
• Generierung passender Regeln für Zahlenwerte und Wahr/Falsch-Werte inklusive Abschluss-Code.
• Tests für den Beispielwert ggb_490000 = 429979.167 und für einen extrahierten Boolean-Wert.

Direkt in der Demo-UI geprüft:

Zahlenmodus mit extrahiertem GeoGebra-Wert

Wahr/Falsch-Modus mit extrahiertem GeoGebra-Wert

Das Issue bleibt offen.

[schumaki]

Finde ich gut soweit. Insbesondere die Automatisch passende Fragmentierung müsste eine große Hilfe sein.

Wie ist das, wenn eine Variable mehrere Fragmente enthält? Häufig sind z. B. Punkte in der Form A = (1, 2) oder A = (-1.3, 2.4) oder Mischformen. Da müsste sowohl der regex beides (mit/ohne Nachkommastellen, ggf. über eine non-capturing group -?\d+(?:\.\d+)?) flexibel erfassen als auch die Eingabemaske des Generators mehrere Fragmente ermöglichen (zumindest wenn aus der Struktur der Variable erkannt wurde, dass es mehrere Fragmente gibt).

Und solange #174 offen ist, bringt dieser Generator aber wahrscheinlich noch nicht so viel für die praktische Kodierung.

[schumaki]

Was es auch noch gibt sind Häufigkeitslisten der Form ^HäufigkeitsListe = {(\d+), (\d+), (\d+)}$ (als Bsp. mit 3 Elementen/Fragmenten, mehr sind aber auch denkbar).

[jurei733]

Danke, guter Punkt.

Die aktuelle Umsetzung ist erstmal bewusst generisch: Bei format: "ggb-variable" wird mit „GeoGebra-Wert hinter '=' kodieren“ der komplette rechte Teil als ein Fragment extrahiert, also z. B. 429979.167, true, (1, 2) oder {1, 2, 3}. Für einfache numerische/boolesche Werte funktioniert das damit.

Mehrere fachliche Fragmente innerhalb eines GeoGebra-Werts werden damit aber noch nicht automatisch als getrennte Fragmentreferenzen angelegt. Das betrifft z. B. Koordinaten wie A = (1, 2), aber auch Häufigkeitslisten wie HäufigkeitsListe = {1, 2, 3}, bei denen mehr Elemente denkbar sind.

Dafür sollten wir den Generator m. E. nicht nur auf Koordinaten spezialisieren, sondern allgemein strukturierte GeoGebra-Werte erkennen und daraus bei Bedarf mehrere Fragmente erzeugen. Bei bekannter Elementanzahl könnte der Generator z. B. explizite Capture-Groups erzeugen; für eine Häufigkeitsliste mit drei Elementen etwa:

^\s*HäufigkeitsListe\s*=\s*\{\s*(\d+)\s*,\s*(\d+)\s*,\s*(\d+)\s*\}\s*$

Für Dezimalzahlen/Vorzeichen analog flexibler, z. B. mit [-+]?\d+(?:[.,]\d+)?.

Wichtig ist dabei: Eine Regex mit wiederholter Capture-Group wie ^(\d+)(?:,\s*(\d+))*$ reicht für echte Einzelfragmente eher nicht, weil wiederholte Captures praktisch nicht als beliebig viele Fragmentreferenzen nutzbar sind. Wenn die Fragmente einzeln kodierbar sein sollen, muss der Generator vermutlich anhand eines Beispielwerts oder der Variablenstruktur eine konkrete Anzahl von Capture-Groups erzeugen.

#174 sehe ich weiterhin als praktischen Blocker: Der Generator nimmt die manuelle Regex-/Fragmentierungsarbeit ab, ändert aber nichts daran, dass bei UNSET nicht kodiert wird. Das Ticket hier wäre also eher die Bedienhilfe im Schemer; die volle praktische Nutzbarkeit hängt weiterhin an #174 bzw. Aspect.

[schumaki]

allgemein strukturierte GeoGebra-Werte erkennen und daraus bei Bedarf mehrere Fragmente erzeugen

Das ist aber u. U. nicht immer gleich offensichtlich, wie man an Vorzeichen und Dezimalzahlen sieht.

Ich bin mir deshalb nicht sicher wie gut/sinnvoll hier ein Generator ist und ob wir damit nicht letztendlich mehr Probleme schaffen (à la "der Zauberstab hat .. ausgegeben, aber das funktioniert nicht") als wenn wir die Aufgabenersteller in der Verwendung von Regex schulen.

[jurei733]

Ja, der Einwand überzeugt mich. Ich würde das deshalb nicht als „allgemeinen GeoGebra-Regex-Generator“ verstehen wollen.

Für die einfachen und häufigen Fälle finde ich die Kodierhilfe weiterhin sinnvoll: ggb_X = 429979.167 oder ggb_X = true sind aus Nutzersicht Werte, und da ist es hilfreich, wenn der Schemer den technischen Präfix vor = automatisch wegfragmentiert.

Bei strukturierten Werten wie Punkten, Listen oder gemischten Zahlenformaten sollten wir aber m. E. vorsichtig sein. Sobald der Generator anfängt, aus beliebigen Beispielen komplexe Regexe mit mehreren Fragmenten zu erzeugen, entsteht schnell der Eindruck, das sei allgemein korrekt. Genau da können Vorzeichen, Dezimaltrennzeichen, optionale Leerzeichen, variable Listenlängen usw. zu falscher Sicherheit führen.

Ich würde daher eher enger abgrenzen:

• Generator/Kodierhilfe für einfache GeoGebra-Werte hinter =: Zahl, Boolean, ggf. Text.
• Für strukturierte Werte höchstens klar benannte Spezialfälle oder Vorlagen, wenn wir sie zuverlässig validieren können.
• Wenn die Struktur nicht eindeutig ist, keine automatische Mehrfragment-Regex erzeugen, sondern auf manuelle Regex/Fragmentierung verweisen.
• Dazu ggf. Dokumentation/Beispiele für typische GeoGebra-Regexe, damit Aufgabenersteller:innen nicht bei null anfangen müssen.

Damit hätten wir die Hürde für den häufigen Spezialfall reduziert, ohne zu versprechen, dass der Generator beliebige GeoGebra-Strukturen korrekt versteht.

[schumaki]

Nutzerfreundlich wäre ein Generator erst, wenn die typischen Anwenderfälle abgedeckt sind. Das wären aus meiner Sicht:

• Punkte (2 Koordinaten, jeweils mit Vorzeichen und optionalen Nachkommastellen)
• Streckenlänge und andere Zahlenwerte (im Prinzip wie schon für ggb_X = 429979.167 implementiert, aber explizite Extraktion der Ziffern über \d mit optionalem Vorzeichen und (optionalen!) Nachkommastellen)
• Winkel (meist in der Form α = -42.14159°)
• Wahrheitswerte (im Prinzip wie für ggb_X = true)

Falls das bis 2.8.0 nicht mehr möglich ist, würde ich von halben Lösungen absehen und das lieber in ein späteres Release packen.

[schumaki]

Dinge wie Häufigkeitsliste o. Ä. sind eher selten und könnten davon ausgenommen werden.
Aber zumindest diese vier Punkte sollten mindestens enthalten sein.