Re: [DSA Manager] Scripting oder nicht Scripting

[Matthias W. <Mat...@gm...>]

Oliver Schulz wrote:
> Hallo Matthias und Tilmann!
> 
> 
>>kk.resolve() erstellt zunächst mal einen neuen String, der so aussieht:
>>
>>"<Basiswert=10> + <ModiXYZ = 2> + [EIG_MR <= 4 ? 5 : 0]"
> 
> 
> Was ich nicht ganz verstehe ist, warum ihr das alles auf
> String-Ebene macht. Ist es nicht viel effizienter,
> stabiler und einfacher, mit fertig geparsten Syntaxbäumen
> zu arbeiten?
> Ich müßt diese Operationen ja sehr häufig durchführen,
> weil bei eurem Konzept für jede Wertberechnung alle dazu nötigen
> anderen Werte rekursiv komplett neu berechnet werden müssen
> (hab ich das richtig verstanden?).

Das war ein falscher Fehler von mir. Tschuldigung. Nicht die resolve() 
Methode konkateniert die Strings, sondern die 
relationenAuswerten()-Methode, die schon deutlich seltener aufgerufen 
wird. Wir verwenden in der Tat den Syntaxbaum, um die Ausdrücke 
auszuwerten. Wenn die Modifikatoren aus XML geholt und zusammengepfercht 
wurden, der Charakter instanziiert und die Relationen ausgewertet 
wurden, verwenden wir keine String-operationen mehr. Unsere 
Implementierung der ArithmeticExpression enthält eine Referenz auf den 
Root-Knoten des Syntaxbaums des dazugehörigen Ausdrucks.

Die resolve() Methode arbeitet dann auf dem Syntaxbaum, der Syntaxbaum 
enthält dann natürlich an diversen Knoten Strings - und zwar die 
Identifikatoren, mit denen aus der HashMap dann wieder 
ArithmeticExpressions geholt werden (das sind dann wiederum Syntaxbäume, 
die den Ausdruck darstellen, der dann diesem Identifikator gehört)


> 
>>wobei Basiswert durch den entsprechenden basiswert (hier z.B. 10) zu 
>>ersetzen ist, und ModiXYZ ein beliebiger anderer Modi sei (ein simpler, 
>>der nur "2" enthält, z.B. von der Rasse).
>>Dies ist also alles in allem ein arithmetischer Ausdruck:
>>"10 + 2 + [EIG_MR <= 4 ? 5 : 0]"
> 
> 
> Vorschlag: runde Klammern (wie in der Grammatik im CVS vorgesehen).
> Ist irgendwie "natürlicher".

das lässt sich machen

> Ich würde mir zu dieser Grammatik ein paar Kommentare wünschen.
Die sind dabei, wenn ich sie hochgeladen hab.

> Passt die nun zu euren Ausdrücken, oder nicht (von Zuweisungen
> und durch ";" getrennten Anweisungen mal abgesehen)?

was soll passen ? das Beispiel oben ? ja

> 
>>Ich will euch jetzt nicht mit einer Art "hier, wir haben da schonmal was 
>>vorbereitet" überrumpeln, aber da unsere Implementierung die 
>>vorgestellten Konflikte eigentlich lösen kann, weiß ich nicht, warum wir 
>>da noch groß Hirnschmalz für eine andere Lösung investieren sollten.
> 
> 
> Das läuft aber irgendwie doch auf "wir haben da schonmal was vorbereitet"
> hinaus. :-(
> 
> Ich sehe u.a. folgende Probleme mit eurer Lösung, die einen anderen Ansatz
> begründen würden:
> 
> - Ineffezienz - Alles wird vielfach neu berechnet, es wird viel geparst.

da hab ich was falsch erklärt, sorry. Wie gesagt, wir arbeiten auf den 
Syntaxbäumen der Ausdrücke, die erstellt werden, nach dem das 
"relationenAuswerten()" ausgeführt wurde.

Da ich heute das Modell umgestellt hab von Anbindung an net.sf.dsaman.damath
zu
net.sf.dsaman.model.arithmetic
hab ich das jetzt erst gemerkt, das ich was falsch erklärt hab. Der Rest 
dürfte aber stimmen.


> - Mangelnde Leistungsfähigkeit -> es muß viel hart gecodet werden.

Dieses Argument kann ich nun wirklich nicht durchgehen lassen. Wir coden 
nichts hart, wir wollen nur ein einheitliches Modell entwickeln das 
jegliche Art von Verbindungen und Veränderungen darstellen kann.
(Also in dieser Implementierung Relationen und Modifikatoren)

> - Sprachoperationen auf string-Ebene sind ein Hack, keine elegante Implementierung.
> - Rundbezüge lassen sich nur recht brutal auflösen, in dem ein Modi ganz rausfällt.

Da Rundbezüge eigentlich illegal sind und nicht berechenbar, ist "brutal 
aufgelöst" ja wohl die einzige Möglichkeit, oder ???
Das ganze in Verbindung mit einer detaillierten Info für den Benutzer, 
also was willst du denn noch ?


> Zudem hat man sichergestellt, daß die implementierte Sprache mit der
> vorher definierten identisch ist. Euer jetziger Parser braucht vermutlich
> noch einiges an Debugging, z.B. führt folgende Eingabe: "-2" zu dem
> Ergebnis: "-2 = 2.0".

Könntest du mir deine Informanten nennen ? Oder 'spekulierst' du einfach 
mal, was wir so an Mist gebaut haben ?
-2 wertet er schon richtig aus.
auch -(2+2)
auch -2*(2+2)
sogar -sqrt(2)
und ja, auch +sqrt(2)



Gruß
Matthias