Makros für Solver?

[Engywuck]

Da ja an anderer Stelle schon fleißig über den Solver diskutiert wird, wollte ich mal eine Idee in die Runde werfen, die den Komfort für erfahrene Solver-Nutzer erhöhen könnte:
Ich fände so etwas wie die Möglichkeit einer Makrodefinition im Solver lecker. Ich könnte mir das so vorstellen:
Man definiert ein Makro, dass im Grunde eine Zusammenfassung von Solvercode darstellt. Damit man auch was damit anfangen kann natürlich mit Argumentsubstitution.
Ok, Anwendungsfall: Ein Owner findet es super, die Werte für die Buchstabensummen so zu definieren: A=26, B=25, C=24... Die kann man auch berechnen mit length("Wort")*27-val("Wort"). Wenn dies jetzt überall in den Berechnungen verwendet wird, wo Buchstabensummen (eben hier die modifizierte) verwendet werden, wird es schnell unübersichtlich. Andererseits wäre es auch doof, für so abgefahrene Teile eigene Funktionen zu definieren. Daher definiert man hier ein Makro:
macrodef("xval", 1, "(length(%1)*27-val(%1)")
Das erste Argument gibt den Namen des Makros an, das zweite die Anzahl der Argumente, diese werden im Makro mit %1, %2, %3 etc. referenziert. Verwendet würde die Formel dann mit
xval("Wort")
was schon deutlich übersichtlicher aussieht. Andere Anwendungsfälle:
Wenn man hier viel Text zulässt, kann man auch komplexere häufiger wiederkehrende Aufgaben zusammenfassen. Sei WP ein Wegpunkt, so könnte z.B. der Codeabschnitt
goto(WP)
center(WP)
"Nächstes Ziel: "WP
ersetzt werden durch
deploy(WP)
Oder auch die Funktion zum berechnen der Einer-, Zehner oder Hunderter... Stelle einer Zahl:
macrodef("stelle", 2, "mid(reverse(%1),%2,1)")
macht aus
A=mid(reverse(X),2,1)
einfach
A=stelle(X,2)

Wer öfter den Solver befüllt (so wie ich), kann damit sicher was anfangen...

Gruß,
E.

[MiK]

Diese Beispiele würde man dann aber wohl gerne in jedem Cache zur Verfügung haben. Also schreibt man sie wohl eher nicht in den Solvercode eines Caches. Ich könnte mir dafür besser eine extra Datei vorstellen. Darin kann man dann auch besser eine mehrzeilige Syntax unterbringen.

[Robin888]

Da bin ich auch dafür.

Damit könnte sich vielleicht auch das Problem lösen lassen, die einzelnen Ziffern einer mehrstelligen Zahl einzelnen Variablen zuzuordnen.

Aber dazu wären erstmal Schleifen sehr hilftreich. 0:-)

Robin(888)

[Wutschkow]

Makros bzw. selbstdefinierte Funktionen im Solver fände ich auch eine schöne Sache. Allerdings sollten sie dann auch unbedingt dauerhaft speicherbar sein.
Auf diese Weise wäre der Solver auch einfach um neue Funktionen erweiterbar (sofern diese sich aus der vorhandenen Funktionalität zusammensetzen lassen).

Wäre es aus organisatorischen und Performance-Gründen vielleicht sinnvoller, jedes Makro in einer eigenen Datei zu speichern (natürlich in einem eigenen Unterverzeichnis)? Ich denke, das würde die Verwaltung (für den Anwender) erleichtern und vielleicht auch den Zugriff flott halten, wenn die Makrobibliothek im Lauf der Zeit anwächst. Wenn alles in einer Datei steht ist ja womöglich eine Menge Text zu parsen, bis man bei der benötigten Funktion angelangt ist.

[MiK]

Also wenn man die Makros einmal einliest, geht es wohl schneller in einer Datei. Wenn man sie erst "on-the-fly" einlesen will, wären einzelne Dateien wohl schneller. Ich denke aber, der erste Weg wäre sinnvoller.

[Engywuck]

Das werden ja keine Riesen-Dateien werden. Da empfiehlt sich eigentlich ein XML-Format, dann kann man es auch problemlos einlesen und die Struktur ist einigermaßen einfach. Die kann man dann beim Start (oder auch beim ersten Verwenden des Solvers) einlesen und für den Rest der Sitzung merken.

Gruß,
E.

[pfeffer]

alles in 1 Datei erscheint mir sinnvoll.
XML weniger: XML einzulesen ist recht aufwändig. Warum nicht einfach die von Dir beschriebene Syntax in die Datei schreiben?

Gruß,
Pfeffer.

[Engywuck]

Wieso soll xml aufwendig sein? Einen Parser muss man selber schreiben, xml schenkt ihn Dir.

Gruß,
E.

[Wutschkow]

Wieso soll xml aufwendig sein? Einen Parser muss man selber schreiben, xml schenkt ihn Dir.

Das "aufwändiger" bezog sich wohl mehr auf den Rechen- und Zeitaufwand beim Parsen.

[MiK]

Und da man die Makrodateien wohl von Hand schreiben wird, ist XML auch nicht das praktischste Format.