Validierungssprache

[rob]

In der Contest-Engine gibt es seit neuestem Lösungscodevalidierung. Das beruht auf einer noch unvollständigen Implementation einer noch unvollständigen Validierungssprache. Die möchte ich hier mal beschreiben.

Es interessiert mich, was ihr davon haltet. Insbesondere ob es Fälle gibt, die damit nicht abgedeckt sind.

(Ein paar Unklarheiten schiebe ich in einen Folgekommentar.)

Ziel ist hier übrigens mehr als nur die Contest-Engine. Ich würde das dann gerne auch im Rätselportal angeben. Idealerweise aber könnte ich die gleiche Sprache benutzen, um den Lösungscode für ein Rätsel auf meinem Blog zu beschreiben.

Grundbaustein ist die "Bedingung"; eine Bedingung wird als Wort mit (durch Leerzeichen getrennten) Argumenten dargestellt, und stellt eine Bedingung an ein Lösungswort.

An elementaren Bedingungen gibt es zur Zeit

length <Zahl>: das Lösungswort hat die vorgegebene Länge
chars <Wort>: das Lösungswort enthält nur die im Wort vorkommenden Zeichen
permute <Wort>: das Lösungswort ist eine Permutation des Worts
sum10  <Zahl>: die  Ziffern des Lösungswort addieren sich modulo 10 zur vorgegebenen Zahl (nicht implementiert)
prescribed <Zahl> <Zeichen>: an der angegebenen Stelle steht das angegebene Zeichen (nicht implementiert)

Ein "Validierungsteil" ist dann eine Verknüpfung mehrerer elementarer Bedingung, getrennt durch Komma. Z.B. könnte man

length 9, chars 123456789, prescribed 4 9

für eine Sudokuzeile verwenden, in der an vierter Stelle eine 9 angegeben wurde, ohne Mehrfachziffern auszuschließen.

Auf dieser Ebene ist dann ein Ersetzungsschritt vorgesehen, mit dem man Bedingungskombinationen zusammenfassen kann. Eine komplexe Bedingung sieht aus wie eine elementare, sie wird aber nach vorgebenen Regeln in mehrere elementare übersetzt. Z.B.:

latin <Zahl>/<Zeichen>: Zeile/Spalte eines Lateinischen-Quadrat-Rätsels mit Ziffern 1 bis <Zahl> oder A bis <Zeichen>. (bisher nur für Zahlen implementiert)
latin <Zahl> <Zahl>/<Zeichen>: Wie latin mit Lücken (erstes Argument ist die Gesamtlänge, es werden Differenz-viele X dazugepackt.

Z.B: latin 5 C -> length 5, chars ABCX, permute ABCXX

(Hier kann man anmerken, dass "permute ABCXX" schon genügt; in dem zunächst Länge und Zeichensatz überprüft werden, kann man aber einfacher bessere Fehlermeldungen geben.)

Schließlich kann man noch Validierungsteile aneinanderhängen, getrennt durch Semikolon.

[rob]

Zu den verschiedenen Validierungsteilen: Das braucht man z.B. um bei unserer Contest Engine mehere Zeilen in einem Code abzufragen. Damit mehrere Teile sinnvoll einen einzelnen Code prüfen können, muss in jedem Teil "length" oder "sum10" vorkommen. Andernorts könnte so ein Code dann auch mit getrennten Eingabefeldern abgefragt werden. So ganz glücklich bin ich damit aber nicht, weil das die "ein Code pro Rätsel"-Einschränkung unserer Contest Engine weitergibt. Wo ich gerade darüber nachdenke, wie wäre es mit

code1 ; code2: Zwei Codes nach einander, mit überprüfter Trennung (zwei Eingabefelder, oder ein Trennzeichen)
code1 + code2: Zwei Codes nach einander, ohne überprüfte Trennung

[rob]

Bei der Auswertung ist ein Normalisierungsschritt vorgesehen, der aus der Benutzereingabe Leerzeichen und Kommata entfernt und Buchstaben groß macht.

Ich bin mir noch nicht ganz sicher, wie weit man den Zeichensatz einschränken sollte. Um die Lösungscodes für jeden leicht eingebbar zu machen, würde ich am liebsten nur 0-9A-Z zulassen, über +-*/=_. könnte man vielleicht diskutieren...

[Semax]

Lösungscodevalidierung finde ich gut. Und es geht für mich auch schon in die richtige Richtung.

Kleine Anmerkungen:
- prescribed: Statt 'prescribed 4 9' hätte ich eher sowas wie 'prescribed ---9-----' erwartet. Das wäre bei mehreren Vorgaben leichter für den Ersteller zu schreiben und zu prüfen.
- chars: Könnte vielleicht eher 'allowedChars' heißen. Das passt besser zusammen mit folgenden zusätzlichen Bedingungen:
- charsAtLeast <Zahl> <Wort>: Alle im <Wort> vorkommenden Zeichen müssen mindestens <Zahl> mal im Lösungscode vorkommen.
- charsAtMost <Zahl> <Wort>: Alle im <Wort> vorkommenden Zeichen dürfen höchstens <Zahl> mal im Lösungscode vorkommen.
- charsExactly <Zahl> <Wort> -> charsAtLeast <Zahl> <Wort>, charsAtMost <Zahl> <Wort>

Und dann habe ich gerade überlegt, wie man einen Lösungscode für Japanische Summen sinnvoll zur Verfügung stellen könnte. Sowas wie japsum <Length> <MinZahl> <MaxZahl> (z.B. japsum 12 0 8).
Zum einen bräuchte man eine Hilfsfunktion zum Zusammenbauen von Wörtern, da nicht alle Inhalte mit 123.. starten, z.B.:
- word <Zahl1> <Zahl2> <Zahl3>: Alle Zahlen von <Zahl1> bis <Zahl2> im Abstand von jeweils <Zahl3>
(z.B. word -4 8 2 => -4,-2,0,2,4,6,8)
Und dann bräuchte man noch etwas, um Wörter zu verbinden, da ja nicht nur die Zahlen, sondern auch die Schwarzfelder eingegeben werden müssen (z.B. mit x oder X).
- <Wort1> & <Wort2> -> Wort1Wort2 (oder wie auch immer man das in dieser Syntax schreiben würde...)

japsum <Zahl1> <Zahl2> <Zahl3> -> length <Zahl1>, charsAllowed X & word <Zahl2> <Zahl3> 1, charsAtMost 1 word <Zahl2> <Zahl3> 1

Um nicht alle Rätselarten hardzucoden, sollten diese Zwischenbedingungen so flexibel wie möglich sein.

Und dann müsste man wohl auch über Präzedenz und/oder Klammern nachdenken.

[Realshaggy]

Ich finde die Vorschläge von Semax schon fast zu weitgehend. Aus meiner Sicht sollte eine Validierung grobe offensichtliche Nutzerfehler abfangen die i.d.R. auf Tippfehlern oder Fehlinterpretation der Lösungscodebeschreibung beruhen. Z.B. unzulässige Zeichen, Code hat falsche Länge, Zahlenvorgabe bei Sudoku nicht erfüllt etc. Verzählen um 1 bei Wegerätseln ist auch noch so ein beliebter Fehler, der aber schwer zu validieren ist (Streckenlänge vs. Anzahl der benutzten Felder).

Alles andere sollte der Löser gefälligst durch Überprüfung seiner Lösung finden. Auch doppelte Zeichen in lateinischen Quadraten, erst Recht nicht erfüllte Summenvorgaben in Japanischen Summen. Die zur Überprüfung aufzuwendende Zeit gehört zur Rätselzeit dazu und gerade bei Wettbewerben hat man ja die Wahl zwischen "auf Risiko gehen" oder gründlich sein.
Validierung sollte Fehleingaben abfangen, aber nicht auf fehlerhafte Lösungen hinweisen.

Letztenendes geht es hier ja aber um die Beschreibung/Definition und nicht darum, wie es jeder Autor dann nutzt.

[Hausigel]

Hallo,

ich finde es gut, wenn die Validierungssprache so viele Optionen wie möglich unterstützt (natürlich in Relation zu dem Aufwand, den der Programmierer bei der Umsetzung hat). Mir gefällt auch, dass es sowohl elementare Befehle als auch "Makros" gibt.

Was die Wettbewerbsautoren daraus machen, ist eine andere Frage. Prinzipiell sollte das jeder selbst entscheiden dürfen, welche Eingabefehler er abfangen möchte, z.B. nur falsche Längen oder auch sowas wie Wiederholungen innerhalb einer Zeile von Lateinischen Quadraten.

Potentiell würde ich es gut finden, wenn sich bei unseren offiziellen Wettbewerben (Qualis zu DLM, DSM usw.) ein Standard durchsetzt. Da das aber eine ganz neue Funktionalität ist, hat dieses in meinen Augen Zeit, zuerst sollte man das ganze praktisch testen.

Viele Grüße
Roland

[Semax]

Ich finde die Vorschläge von Semax schon fast zu weitgehend.

Wie meinst du das? Meine Vorschläge gehen in Richtung Löser-Hilfe nicht weiter als die von Rob vorgeschlagenen 'permute' und 'latin' Bedingungen.
Der einzige Zweck der neuen Bedingungen ist die Vereinfachung für den/die Programmierer und die Lösungscode-Ersteller.

Validierung sollte Fehleingaben abfangen, aber nicht auf fehlerhafte Lösungen hinweisen.

Stimme ich voll zu.
Leider gibt es Grenzfälle, in denen es schwierig ist, zwischen beiden zu unterscheiden. Z.B. kann ein doppeltes Zeichen in einer Sudokuzeile sowohl von einem Vertipper als auch von einer fehlerhaften Lösung stammen. Ist es jetzt besser, in ersteren Fällen die Fehleingaben nicht abzufangen oder in zweiteren Fällen auf die fehlerhafte Lösung hinzuweisen?

Und wie Hausigel schon schrieb: Wenn wir diese Frage nicht einfach so beantworten können, könnten wir beides testen und anhand von Rückmeldungen herausfinden, welche Variante besser für unseren 'Standard' geeignet ist.

[Hausigel]

Hallo,

Frage: In welchem Umfang ist die Validierungssprache jetzt implementiert? Hintergrund ist die Möglichkeit, sie beim Hochhausrätsel-Wettbewerb jetzt am Wochenende testweise zum Einsatz zu bringen, aber ich möchte absolut ungern während der Wettbewerbszeit die Wettbewerbseinstellungen ändern.

In der Autorenoberfläche zum Editieren eines Contests habe ich momentan die Validierungsbefehle eingegeben. Bis jetzt war es so, dass:
* die von mir eingegebenen Lösungscodes dort nicht darauf geprüft wurden, ob sie zu der Validierungsvorschrift passen;
* ich als Löser - testweise habe ich den Wettbewerb mal für mich gestartet - auch keine Hinweise auf falsche Lösungsformate erhalte.

Kurz gesagt, momentan scheint die Eingabe der Validierungsformate keinen Unterschied zu bewirken...

Viele Grüße
Roland

[rob]

Roland, das wäre natürlich cool, da etwas zu verwenden. Eigentlich dachte ich, es würde schon gehen, ich schaue nachher mal drauf und mache vielleicht einen kleinen Probewettbewerb.

[rob]

Also ich hatte da tatsächlich was kaputt gemacht und die Validierung ging gar nicht. Jetzt sollte es so sein, wie ich wollte.

Es ist jetzt ein kleiner Testwettbewerb eingerichtet, spielt mal mit darum. Ich habe eben mal einen mysteriösen Fehler gehabt, den ich aber nicht reproduzieren kann...