dsaman-list Mailing List for DSA Manager (Page 4)
Status: Planning
Brought to you by:
alexnofftz
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(244) |
Dec
(108) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(169) |
Feb
(41) |
Mar
(29) |
Apr
(69) |
May
(98) |
Jun
(9) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Tilmann K. <ds...@tk...> - 2002-05-09 19:20:51
|
Hi! Alexander Nofftz wrote: > <Modifikator auf="KK"> > <Modifikator add="7" wenn="MU > 15"/> > <Modifikator add="5" wenn="(MU > 10) and (MU < 15)"/> > </Modifikator> > > oder > > <Modifikator wenn="Rasse=Elf"> > <Modifikator auf="Schwimmen" add="1"/> > <Modifikator auf="Schwerter" sub="3"/> > </Modifikator> Ist bestimmt machbar, allerdings nicht so schoen zu verarbeiten. Ausserdem wuerde ich gerne auf 'add'/'sub' zugunsten von 'wert' oder so verzichten und ausserdem alle Beziehungen evtl in einem Relation-Element mit einem typ-Attribut zusammenfassen wuerde. Moegliche typen waeren: WertModifikator MaxModifikator Startwert Muttersprache AtModifikator PaModifikator ... Gruss, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-09 19:17:04
|
Hi Leute! Ich hab mir mal ueberlegt, was wir fuer diverse Features so an Properties xxx (Bsp. EIG_MU.xxx) brauchen koennten, Kritik erwuenscht: Talente: effektiv basis max mod (Summe der Modifikatoren) maxMod (Summe der Modifikatoren auf den Maximalwert) ( at pa atBasis paBasis atMod paMod sktSpalte sktMod ) Ich glaube zwar nicht, dass wir die brauchen hab sie jetzt aber mal dazugeschrieben. Eigenschaften: effektiv basis start (der Startwert) max maxmod ( sktSpalte sktMod ) Gruss, tilmann |
From: Matthias W. <Mat...@gm...> - 2002-05-09 10:16:04
|
Wer Lust und Laune hat, kann sich mal in dsaman/data/gui die guielemente.txt anschauen, sie ist noch nicht ganz fertig, aber was schon drin ist, kann man ja mal bereden. Falls Holger mitliest, der ja schonmal was zu dem einen GUI-Vorschlag gelesen hat. Kannst du das Zeug auschecken ? Wenn nicht, klick dich einfach bei unserem CVS-Browser auf dsaman.sf.net durch zu der Datei. Gruß Matthias |
From: Oliver S. <os...@ep...> - 2002-05-09 02:10:46
|
Hallo Matthias! > Also, wenn ich die Diskussionen hier so verfolge, hab ich das Gefühl, > das vergessen wird, das wir eigentlich XML als Datenhaltung verwenden Ich denke schon, daß das allen klar ist. Ich hatte nie vor, mit dem Scripting Dinge zu machen, die wir mit XML gut machen können. Es ging mir darum, auch bei vertrackten Problemen und Sonderregeln nicht plötzlich hart coden zu müssen, weil's Design zu kurz gegriffen war. > Unser Ansatz zielt konkret auf eine "Kastrierung" der Ausdrucks-Sprache, > da die Verbindungen und Strukturen ja in XML festgehalten werden > sollten. Soviel dazu. Groß diskutieren brauchen wir eigentlich nicht > mehr, wenn es darum geht, seinen eigenen Standpunkt zu verfechten. Es geht nicht darum, irgendeinen Standpunkt durchzufechten. Es geht darum, gemeinsam zu entscheiden, wieviel Scripting muß möglich sein, um langfristig sicherzustellen, daß wir nicht in Probleme geraten. > Und Olli, es tut mir leid, aber wenn du ständig sagst, wir > berücksichtigen dich nicht... Mal ganz unabhängig davon, das wir sachen Nun, dann prüfe doch bitte mal, inwieweit Dein CC mit meinen Produktionsregeln für Ausdrücke (ohne Zuweisungen natürlich) zurechtkommt. Falls das geht, spricht dann etwas dagegen, sie zu benutzen? Ich hatte ja schon begründet, warum ich eine einheitliche Grammatik für wichtig halte. Dazu hast Du dich nichts geantwortet - ist das als Zustimmung zu verstehen? > schon teilweise implementiert haben ( mit den 80% habe ich gemeint, 80% > bis eine geringe Demo-Funktionalität gegeben ist, und auch nur was das > Modell betrifft), so steckt unser Vorschlag ja trotzdem noch in den > Implementierungsanfängen, und ist nicht viel mehr als ein Vorschlag. Tut mir leid, dann hatte ich Dich mißverstanden. Nach Deinen Aussagen "So, ich hoffe, ich konnte euch unseren Ansatz etwas näherbringen. Er ist auch schon zu 80% implementiert" und "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" hatte ich nicht Dein Eindruck, daß das es sich lediglich um einen Vorschlag handelt, und Du auch für andere Ideen offen bist. Meine Fehlinterpretation, sorry. > Wenn du aber ständig kommst mit wir hintergehen dich, dann können wir Bitte. Ich habe mich nicht über ein "Hintergehen" beschwert, sondern über mangelnde Kommunikation. Und genau das habe ich auch gemeint. Ich will hier keinen persönlichen Auseinandersetzungen, ich will im Gegenteil mehr Zusammenarbeit. > anderen auftreten. Du sagst wir würden nicht anweisungsorientiert > arbeiten. Naja, eigentlich tun wir das doch. Nur ist der Linkswert der > Zuweisung quasi in XML notiert: <Modi auf "EIG_LE" wert="(EIG_KO*2 + > EIG_KK)/2"> Äh, nein, da hab ich nicht gesagt. Im Gegenteil. Ich hab doch am 6.5. hier selbst gepostet: "ob man schreibt ziel='x', quelle='y', oder 'x=y' ist semantisch identisch". Den Begriff "anweisungsorientiert" hast Du in die Diskussion eingebracht. > Jetzt fragst du vielleicht: Warum einigen wir uns nicht auf deinen > Vorschlag ? ganz einfach: das hier oben lässt sich einfach besser parsen Vielleicht? Das hab ich hier in dem obigen Zusammanhang schon öfter hier gefragt. Und auch begründet, warum sich beides gleich gut parsen läßt. > Aber bevor wir hier groß weiterreden, müssen wir uns wohl andere > Meinungen holen. Ingbert und Alex müssten mal ihre Meinungen dazu > beitragen, sonst wird das hier eine einzige endlose Diskussion. Jau. Mittlerweile hat sich Alex ja auch dazu geäußert. Da sich auch Alex für Quelle und Ziel getrennt ausgesprochen hat, scheint sich wohl eine Mehrheit für dieses Konzept zu finden. So soll es denn sein - hoffen wir, das damit alles zu machen ist, was wir brauchen. Jetzt wäre der Zeitpunkt gekommen, eine gemeinsame Grammatik zu erstellen und danach dann zu implementieren. Nun wirst Du wohl schreiben: "aber wir haben ja schon was gebastelt, das läuft, also bleiben wir dabei" ... Beim nächsten Mal, wenn sowas ist: Schau Dir an, was andere Leute machen. Kritisiere ihren Entwurf, aber ignoriere ihn nicht (Stichwort: Produktionsregeln). Stell Konzepte frühzeitig ins CVS, und nicht erst mit der fast fertigen Testimplementierung. Mach Dateistrukturkonzepte in einem sprachneutralen Format, und lad sie ins /data Verzeichnis. Halt Leute, die im selben Bereich arbeiten wie Du, auf dem Laufenden (Stichwort: Wir arbeiten jetzt auch mit einem Parsergenerator, den hat bloß noch keiner gesehen, haben wir bloß noch keinem gesagt). Vielleicht kann Alex sich als Mit-Projektleiter hierzu auch nochmal äußern. cu Oliver |
From: Tilmann K. <ds...@tk...> - 2002-05-08 23:07:41
|
Hi! Matthias Wurm wrote: > Jetzt klappts, die ausführbaren, testbaren .java's sind: > > net\sf\dsaman\model\arithmetic\TestArithmetic.java > net\sf\dsaman\ModelTest.java ^^^^^^^^^^^^^^ Das und auch die Personen-Klassen habe ich gerade fuer den neuen Parser angepasst und noch einen Test zur Erkennung von rekursiven Formeln eingebaut. Gruss, tilmann |
From: Alexander N. <lists@AlexNofftz.de> - 2002-05-08 20:28:13
|
Hi! Am Mit, 2002-05-08 um 09.15 schrieb Matthias Wurm: > Und falls hier noch *IRGEND EIN ANDERER* mitliest, der diese Problematik=20 > in etwa erfassen kann, dann soll er sich bitte auch melden Wollte mich nur mal kurz zu Wort melden, um zu zeigen, dass ich noch lebe. Hab in den letzten Wochen massivst mit Umz=FCgen, Keller ausr=E4umen, Renovierungen etc. zu tun gehabt und daher ehrlich gesagt momentan nicht die Mu=DFe, mich hier gro=DFartig rein zu knien, hoffe aber, dass sich das bald wieder =E4ndert. Generell teile ich Mathias' Ansicht, wie ja auch schon aus meinem urspr=FCnglichen Modifikator-Vorschlag hervor geht. Ich bin daf=FCr, dass wir die XML-Strukturierung so weit wie m=F6glich ausnutzen. Dass Sachen wie mathematische Ausdr=FCcke nicht als Tag-Struktur erfasst werden, hat eher einen Aspekt, der mehr zur =DCbesicht beitr=E4gt (nicht ohne Grund wir= d das bei XSLT genau so gemacht). Aber ich bin auf jeden Fall daf=FCr, das Ziel und auch die Bedingung als eigene Attribute festzulegen. Man k=F6nnte erlauben, die Modis zu schachteln, um eine h=F6here =DCbersicht und Flexibilit=E4t zu erreichen: <Modifikator auf=3D"KK"> <Modifikator add=3D"7" wenn=3D"MU > 15"/> <Modifikator add=3D"5" wenn=3D"(MU > 10) and (MU < 15)"/> </Modifikator> oder <Modifikator wenn=3D"Rasse=3DElf"> <Modifikator auf=3D"Schwimmen" add=3D"1"/> <Modifikator auf=3D"Schwerter" sub=3D"3"/> </Modifikator> Ich hoffe, dass dies selbst erkl=E4rend ist. Man sollte auch beachten, dass dies mit der Implementierung und Darstellung im Programm wenig bis nichts zu tun hat. Bis dann, Alex --=20 Alexander Nofftz, Leverkusen, Germany Ale...@em... http://www.AlexNofftz.de=20 Jabber: ale...@am... (Jabber?! http://amessage.de) |
From: Matthias W. <Mat...@gm...> - 2002-05-08 19:07:47
|
Die Beispiele funktionieren jetzt sogar ! *g* Falls ihr es schon zuvor probiert haben solltet... Die lexer.dat und die parser.dat wurden nicht im binär-Modus hochgeladen, darum ging nix. Jetzt klappts, die ausführbaren, testbaren .java's sind: net\sf\dsaman\model\arithmetic\TestArithmetic.java net\sf\dsaman\ModelTest.java Gruß Matthias |
From: Ingbert <bus...@in...> - 2002-05-08 15:02:23
|
Hallo zusammen, Matthias Wurm wrote: > Aber bevor wir hier groß weiterreden, müssen wir uns wohl andere > Meinungen holen. Ingbert und Alex müssten mal ihre Meinungen dazu > beitragen, sonst wird das hier eine einzige endlose Diskussion. Ich werde mich mal am morgigen Feiertag richtig in die Diskussion einlesen; im Augenblick verfolge ich die Sache bloß oberflächlich. Ansonsten freut es mich, daß hier mal wieder richtig Traffic ist! :-) Viele Grüße Ingbert |
From: Matthias W. <Mat...@gm...> - 2002-05-08 07:17:04
|
Also, wenn ich die Diskussionen hier so verfolge, hab ich das Gefühl, das vergessen wird, das wir eigentlich XML als Datenhaltung verwenden wollen. Unser Ansatz zielt konkret auf eine "Kastrierung" der Ausdrucks-Sprache, da die Verbindungen und Strukturen ja in XML festgehalten werden sollten. Soviel dazu. Groß diskutieren brauchen wir eigentlich nicht mehr, wenn es darum geht, seinen eigenen Standpunkt zu verfechten. Und Olli, es tut mir leid, aber wenn du ständig sagst, wir berücksichtigen dich nicht... Mal ganz unabhängig davon, das wir sachen schon teilweise implementiert haben ( mit den 80% habe ich gemeint, 80% bis eine geringe Demo-Funktionalität gegeben ist, und auch nur was das Modell betrifft), so steckt unser Vorschlag ja trotzdem noch in den Implementierungsanfängen, und ist nicht viel mehr als ein Vorschlag. Wenn du aber ständig kommst mit wir hintergehen dich, dann können wir auch sagen, dass du dich stur gegen unseren Vorschlag wehrst, und du deinen Vorschlag auf Teufel komm raus durchsetzen willst. Differenzen mögen auch aus Mangel an Kenntnis der Denkweisen des jeweils anderen auftreten. Du sagst wir würden nicht anweisungsorientiert arbeiten. Naja, eigentlich tun wir das doch. Nur ist der Linkswert der Zuweisung quasi in XML notiert: <Modi auf "EIG_LE" wert="(EIG_KO*2 + EIG_KK)/2"> Jetzt fragst du vielleicht: Warum einigen wir uns nicht auf deinen Vorschlag ? ganz einfach: das hier oben lässt sich einfach besser parsen , die Relation zwischen den Objekten wird nämlich durch das auf-Attribute dargestellt, und sollte eigentlich schon bekannt sein, wenn wir Objekte aus den XML-Daten erstellen wollen. Und da ist es ganz einfach geschickter, wenn wir das auf XML-Ebene trennen, und nicht schon beim parsen des XML unseren eigenen Parser anschmeißen müssen. Aber bevor wir hier groß weiterreden, müssen wir uns wohl andere Meinungen holen. Ingbert und Alex müssten mal ihre Meinungen dazu beitragen, sonst wird das hier eine einzige endlose Diskussion. Und falls hier noch *IRGEND EIN ANDERER* mitliest, der diese Problematik in etwa erfassen kann, dann soll er sich bitte auch melden Gruß Matthias |
From: Oliver S. <wh...@us...> - 2002-05-08 00:34:31
|
Hallo Tilmann! > Machen wir. Matthias hat das etwas verfaelscht widergegeben. Normalerweise > wird auf dem Syntaxbaum gearbeitet und nur wenn sich was geaendert hat wird > neu geparst. Es wird nicht der Text eingesetzt oder so, sondern an Stelle > von EIG_MR wird dann quasi zum Berechnen kurzzeitig der Syntaxbaum von MR > eingehaengt. Ah! Dann nimm nehme ich meine Einwände gegen die Stringoperationen alle zurück. :-) Hm - wenn ihr komplett auf Syntaxbäumen arbeitet, könntet ihr aber doch auch mit einem "=" Operator statt Quelle/Ziel locker umgehen, oder? >> Das läuft aber irgendwie doch auf "wir haben da schonmal was vorbereitet" >> hinaus. :-( >Im Grunde habe ich nicht viel gemacht ich habe wie im Modell von dsaman.argo >beschrieben mal Huellen(Objekte) fuer die einzelnen Features eines Charakter Hm, Zitat Matthias: "So, ich hoffe, ich konnte euch unseren Ansatz etwas näherbringen. Er ist auch schon zu 80% implementiert" > > - Mangelnde Leistungsfähigkeit -> es muß viel hart gecodet werden. > > Nicht wirklich glaube ich. Beispiele? Du hattest doch geschrieben, daß Du hart coden mußtest? > > - Rundbezüge lassen sich nur recht brutal auflösen, in dem ein Modi ganz rausfällt. > 1. Werfen sie eine exception, wie man darauf reagiert liegt nacher am Programm > 2. Ist das Problem beim Scripting das Gleiche. Nein, man kann die Scripte wie von mir beschrieben sortieren, und dann alle nacheinander einmal ausführen. Dann fällt kein Modifikator aus, und das Ergebnis dürfte im Allgemeinen dem entsprechen, das der Regelauthor im Sinn hatte. Es kann auch leicht festgelegt werden, welcher Modi im Zweifelsfall erst anzuwenden ist. Bei eurer rekursiven Berechnung wird ein Exception-Handling, das das leistet, sehr problematisch zu machen sein. > Der war von Ingbert. Matthias hat mit SableCC inzwischen 'nen neuen > generiert ;-) Sorry, wußte ich nicht ... Frage: Ist der schon im CVS? Auf welcher Grammatik beruht der? Irgendwie hat sich niemand zu der geäußert, die ich ins CVS gestellt hab, aber ich hab auch keine andere gefunden. Ich fände es schön, wenn wir solche Dinge ein bischen mehr koordinieren. > > noch einiges an Debugging, z.B. führt folgende Eingabe: "-2" zu dem > > Ergebnis: "-2 = 2.0". > > Welcher? Wie aufgerufen? Aktuelle CVS-Version, dsaman/java/net/sf/dsaman/dsamath/ArithmeticParser. Ist die Klasse aktuell? Btw: Was genau ist denn nun gegen meinen Vorschlag einzuwenden? Er läßt zu, daß man sehr komplexe Scripte schreiben kann (aber nicht muß), die Modifikatoren sehen sehr "natürlich" aus (MU+=2), und wenn mann mal ein kniffliges Regelproblem hat, hat man deutlich mehr Möglichkeiten. Zudem läßt sich das Scripting auch über den Anwendungsbereich Modifikatoren hinaus einsetzen. Und man braucht nicht mehr als einen Zuweisungsoperator, und mehrere Anweisungen pro Script. Das ist, wenn ihr jetzt auch einen Parsergenerator nutzt, doch wirklich nicht wild ... cu Oli |
From: Oliver S. <wh...@us...> - 2002-05-07 23:45:24
|
Hallo Matthias! > die Funktionen, die ich verwendet habe, nicht ganz abwegig sind, und du > wohl auch diese Bezeichner verwendet hättest. Wenn nicht, ist es ein > Klacks, das zu ändern, aus genau diesem Grund verwenden wir ja nen > Parsergenerator. Nicht unbedingt, wenn man schon Backend-Code hat (und da bin ich mittlerweile auch recht weit). Unsere Grammatik-Ansätze sind grundverschieden, auch wenn die beschriebenen Ausdrücke (glaube ich) fast identisch sind. > Meine Entscheidungen sind hauptsächlich aus einer bereits vorhandenen > Kenntnis der Eigenschaften von SableCC getroffen worden. Aber wie Ich kenne SableCC nicht, gehe aber mal davon aus, daß es sich um einen vollwertigen LALR(1)-Parsergenerator handelt. Insofern sollte sein Einsatz das Design einer kontextfreien LALR(1)-Sprache in keiner Weise beeinflussen. > akzeptieren. Und von mathematischen Ausdrücken haben wir wohl beide in > etwa die selben Vorstellungen. Also, wo ist dann das Problem, wenn meine > Grammatik dieselben Ausdrücke akzeptiert, aber die Produktionen anders > aussehen ? Wohl nirgends, will ich meinen. Da liegt ein ganz entscheidendes Problem: Da wir Ausdrücke/Scripting später haufenweise anwenden werden, muß ganz klar definiert sein, in welcher Sprache man das macht. Und nichts leistet dies besser und einfacher, als eine formale Definition in Form einer Grammatik. Natürlich kann man einen Nachweis führen, daß verschiedene Produktionssysteme die selbe Sprache erzeugen. Aber man kann's sich besser sparen, indem man identische Grammatiken nutzt, und die dann in die verschiedenen CC's steckt ... :-) > Da ich selber einige Zeit abwesend war, weiß ich außerdem ja nicht, wie > die Vorstellungen des Projekts auseinanderlaufen, und wie "Ernst" > Tilmanns Entwurf auch für die C-Leute wahrgenommen wird. Die Grammatik und ihre Semantik - sehr ernst. Da darf es später keine Unterschiede geben, damit die selben Datenfiles gleich funktionieren. Die Implementierung dagegen kann natürlich völlig verschieden sein. Aber wir müssen mit der selben Grammatik leben. Daher mein stetes Bitten, sowas erst abzusprechen, und in /data zu dokumentieren, und dann in /java/net/... zu implementieren ... ;-) > Anforderungen erfüllt, habe ich halt meinen Beitrag dazu beigefügt. Wäre > ich deinem Vorschlag auf anweisungsorientiertes Skripting gefolgt, hätte > ich keine Chance gehabt, das in Tilmanns bestehendes Modell zu Nur ein geringer Teil meiner Grammatik befaßt sich mit Zuweisungen, der Rest tut genau das, was Deine auch macht. Da hättest Du doch gut drauf aufbauen können, bzw. es verbessern können, wenn es nicht gut ist. > integrieren, dann hätte ich ein - momentan - vollkommen nutzloses > Code-Fragment erstellt. Es geht doch gar nicht um Code, es geht um Sprachdesign, oder nicht? > Und wenn man das so betrachtet, dann hätten weder Tilmann noch Ingbert > noch du noch ich mit dem Modell / der Grammatik anfangen dürfen, solange > wir nicht das Auswertungsmodell für die Ausdrücke entwickelt haben. Denn > dieses Modell ist mindestens genauso wichtig wie die Datenstruktur, Nein, eben nicht. Man hat Fakten gegeben (DSA4-Modis, ...). Diese möchte man, sowohl für Menschen, wie auch für Software, gut lesbar in einer Dateistruktur darstellen. Diese soll von (mindestens) zwei grundverschiedenen Programmen verwendet werden. Dies ist unsere Problemstellung. Notwendigerweise definiert man erst eine elegante, zweckdienliche Sprache, die das leisten kann, und dann macht man ein Auswertemodell. Denn die Sprache muß für beide Implementierungen identisch sein, das Auswertemodell aber nicht notwendigerweise (die Semantik natürlich schon). Genau in dieser Reihenfolge bin ich beim Entwurf meiner Grammatik denn auch vorgeganen. Meine Ausdrucksweise "MU += 2" ist ja nichts anderes als eine saubere Schreibweise für das im Regelwerk benutzte "MU+2" - bzw. "erhöht Mut um 2". Ich habe auch ein Auswertemodell dafür vorgestellt (weil es hieß, diese Sprache sei schwierig implementierbar), aber es ist sicher nicht das einzig mögliche. > arithmetic.grammar ist SableCC-spezifisch, SableCC ist Java-spezifisch, > und darum hat das eigentlich nix in /data zu suchen. Wenn du mir sagst, > dass dein CC die datei auch lesen kann, dann vollführe ich gerne den > gewaltigen Akt, und kopiere die paar kB in /data... Die generierten Nein, kann er nicht lesen - und SableCC kann nicht lesen, was ich brauche. Das ist genau der Grund, warum ich meine Grammatik in BNF hochgeladen habe, und nicht als Bison-Input File. Weil die Diskussion über Script/Math - eine Java/C++-unabhängige Design- und keine Coding-Diskussion sein muß. cu Oli |
From: Oliver S. <wh...@us...> - 2002-05-07 22:51:25
|
Hi Tilmann! > > Ok, auf die Weise gibt's keine Reihenfolgeprobleme, aber dafür > > wird ein Haufen Werte mehrfach, evtl. sogar sehr oft berechnet. > Berechnet ja, siehe andere Mail. Jau, das ist jetzt klar. > Das er das tut moechte ich nicht leugnen die Frage ist nur ob wir das > wollen. Auch ich moechte auch moeglichst viel von der Programmierung her Ich auch - darum rede ich ja immer wieder davon, beim Design nicht so sehr auf die Implementierung zu schauen. > offen lassen. Ich finde aber auch dass zuweisungsorientiertes Scripting zu > Undurchsichtigkeit fuehrt und es hat noch weitere Nachteile: > > - es ist extrem schwer zu debuggen > - es koennen durch Fehleranfaelligkeit wirklich chaotische Effekte auftreten Warum genau? Ich halte zuweisungsorientiertes Scripting für wesentlich fehlerunanfälliger. Auch weiß ich nicht, wo das Problem beim Debuggen sein soll. Zuweisungsorientiertes Scripting bedeutet, die Charakter(effektiv)werte einzeln und nacheinander jeweils einmal zu berechnen. Da das genau das ist, was man mit Pen&Paper auch macht, halte ich es im Gegenteil für sehr intuitiv, übersichtlich und leicht zu debuggen. Man könnte sich im Zweifelsfall den ganzen Berechnungsprozeß linear anzeigen lassen, ohne daß das sehr lang wird. Das wird bei euren tiefen und mehrfachen Rekursionen sehe ich genau da viel eher Probleme. > Finde ich nicht es gibt entweder einen Modifikator auf MU oder einen anderen > auf GE nicht einen auf beides. Aber darueber koennten wir warscheinlich noch > ewig diskutieren ;-) Jau ... :-) > Ausserdem muss man da arg aufpassen ein Modifikator auf eine Eigenschaft ist > z.B. nicht wirklich trivial mit "MU.effektiv = MU.effektiv + 3" ist's da > nicht getan. Warum kann sich mal jeder selbst ueberlegen. Warum ist das ein Problem? Wenn sichergestellt ist, daß bei Berechnung des Effektivwertes jeder Modi nur einmal angewendet wird (und das war in meinem Konzept ja drin), geht das doch einwandfrei, oder? > Ok ich mach mal ein beispiel fuer die Berechnung der Steigerungskosten am > Talent schwimmen. [...] > Code ich das hart habe ich es genau einmal fuer alle Talente. Werden die Da sind wir uns sicher einig. Dinge wie Steigerungskosten, also tiefste DSA4-Grundkonzepte, die wirklich für alles gleich sind, werden hart gecodet. Ich hatte gedacht, Du hättest auch viele Sonderregeln und so hart gecodet, weil's mit den Modis allein nicht ging. cu Oli |
From: Tilmann K. <ds...@tk...> - 2002-05-07 21:35:19
|
Hi Oliver! Oliver Schulz wrote: > Ah, jetzt hab ich verstanden, warum Du dieses Problem nicht hast. > Ok, auf die Weise gibt's keine Reihenfolgeprobleme, aber dafür > wird ein Haufen Werte mehrfach, evtl. sogar sehr oft berechnet. > Berechnet ja, siehe andere Mail. >>>Nein, je nach Implementierung entweder >>> Modifikatoren-im-Regelwerk-Anzahl x 1 >> >>So hab ichs im Moment. > > > Das ist mir jetzt nicht ganz klar. Du kannst doch erst parsen, > wenn Du konkateniert hast? Und das kannst mußt Du doch für > jeden Char einzeln machen, oder? Ja, die Anzahl der Modifikatoren ist aber die obige, da es im Moment keine Personenwrapper gibt. Baue ich aber noch Personenwrapper ein, so habe ich die andere von dir genannte Anzahl und ich muss jeden Modifikator nur einmal parsen. Das werde ich bei gelegenheit einbauen aendert aber an der Funktion nichts, nur an der Geschwindigkeit und Uebersichtlichketi. > Ich will verhindern, daß viel hart gecodet wird (womit Du ja schon > angefangen hast). Ursprünglich war vorgesehen, daß DSAMan mit möglichst > wenig Hardcoding auskommen soll, und meines Erachtens nach ist diese > diese Anforderung nach wie vor aktuell. Hinzu kommt, daß es nicht > wirklich aufwendig ist, neben den ganzen mathematischen Op's noch > einen Zuweisungsoperator zu implementieren, der einem dann aber > eine Menge Möglichkeiten eröffnet. Das er das tut moechte ich nicht leugnen die Frage ist nur ob wir das wollen. Auch ich moechte auch moeglichst viel von der Programmierung her offen lassen. Ich finde aber auch dass zuweisungsorientiertes Scripting zu Undurchsichtigkeit fuehrt und es hat noch weitere Nachteile: - es ist extrem schwer zu debuggen - es koennen durch Fehleranfaelligkeit wirklich chaotische Effekte auftreten > >>Geht bei meiner doch auch: >>1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0] >>2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5] > > > Ja, ist mir schon klar. Aber dann sind's halt zwei Modis, wo > einer vielleicht von der Regellogik her eine Einheit gebildet > hätte. Finde ich nicht es gibt entweder einen Modifikator auf MU oder einen anderen auf GE nicht einen auf beides. Aber darueber koennten wir warscheinlich noch ewig diskutieren ;-) Ausserdem muss man da arg aufpassen ein Modifikator auf eine Eigenschaft ist z.B. nicht wirklich trivial mit "MU.effektiv = MU.effektiv + 3" ist's da nicht getan. Warum kann sich mal jeder selbst ueberlegen. > Was heißt komplette Programmiersprache? Schleifen kommen meines > Erachtens nicht in Frage, desgl. Funktionsdefinitionen, etc. > Aber: Arithmetik, Boolarithmetik, Schachtelung und bedingte > Ausdrücke sind eh schon eine nette Grundlage, und die hast Du doch > auch vorgesehen. > Wenn man da lediglich Zuweisungen und die Möglichkeit mehrer Anweisungen > (Script) hinzufügt, gewinnt man sehr "kostengünstig" die Möglichkeit, > so manches Regelproblem elegant lösen zu können. Ok ich mach mal ein beispiel fuer die Berechnung der Steigerungskosten am Talent schwimmen. Schwimmen.SteigerungsKosten = (Schwimmen.effektiv < 0 ? skt(Stufe.effektiv,Schwimmen.sktSpalte) : (Schwimmen.effektiv == 0 ? (Schwimmen.kategorie == "Basis-Talent" ? skt(Schwimmen.effektiv + 1,Schwimmen.sktSpalte) : (Charakter.inGenerierung ? Schwimmen.sktSpalte : skt(Stufe.effektiv,Schwimmen.sktSpalte)))) : skt(Schwimmen.effektiv + 1,Schwimmen.sktSpalte)) Zugegebenermassen kann man das auch beim Scripting in mehrere Zeilen aufspalten um die Uebersichtlichkeit zu erhoehen. Dann hab ich das aber nochmal fuer das Talent Schleichen, wobei ich jeweils Schwimmen durch Schleichen ersetzen muss, dann noch fuer Klettern, Etikette,.... (Moechte gar nicht wissen wie lange man den Fehler suchen muss, wenn einmal irgendwo Schwimmen nicht ersetzt wurde, vorrausgesetzt es wurde ueberhaupt bemerkt, dass irgendwo ein Fehler vorliegt) > In solchen Fällen hart zu coden, und erst mal wieder eine neue Programmversion > unter die Leute bringen zu müssen, ist keine akzeptable Alternative. > Und sicherzustellen, daß in Java und C++ hart gecodete Regeln das Gleiche tun, > ist auch ein Riesenproblem. Code ich das hart habe ich es genau einmal fuer alle Talente. Werden die Regeln geaendert (gilt nicht fuer Aenderung der Skt) muss ichs halt im Code aendern. Aber hier sollten die Regeln eigenltich festgelegt sein, kommt also beim einen Programm was anderes raus als beim anderen, so ist eines schlicht und ergreifend falsch. Bis dann, tilmann |
From: Matthias W. <Mat...@gm...> - 2002-05-07 20:56:25
|
Oliver Schulz wrote: > Hallo Matthias! > > >>ich mal das Zeug hochgeladen. Noch nicht alles ist implementiert und >>dokumentiert, aber in net.sf.dsaman.model.arithmetic.grammar ist die >>Grammatik zu finden, die man sich mal anschauen kann, die hab ich auch >>ausdokumentiert. > > > Jetzt hab ich aber mal eine Frage: Am 29.4. hattest Du gefragt, > ob's schon eine Grammatik gibt (gab's ja noch nicht). Darauf hin > hab ich am 30.4., also vor gut einer Woche, eine Grammatik ins CVS > gestellt und hier in der Liste Bescheid gesagt, in der Hoffnung, > daß wir daraus _gemeinsam_ etwas machen, das allgemeine Zustimmung > findet. > Wieso hast Du die Grammatik völlig ignoriert, und stellst jetzt, > schon teilweise implementiert, eine komplett andere vor? So stell > ich mir Zusammenarbeit ehrlich gesagt nicht vor! Zu meinem Entwurf > gab's (bis auf die Beispiele) weder Zustimmung, noch Kritik. > Du hast auch nicht angekündigt, an einem komplett Verschiedenen zu > arbeiten. > Sorry, falls mir hier irgendetwas in der Liste zu dem > Thema entgangen sein sollte - falls nicht, gab es jedenfalls > noch keinen Konsens, wie Scripting bzw. Ausdrücke endgültig aussehen > sollen. > Willst Du jetzt plötzlich vollendete Tatsachen schaffen?! Hierzu kann ich nur eines sagen: Die Grammatik mag ja eine andere sein. Die Sprache allerdings unterscheidet sich nicht sonderlich von der deinen, bis auf die nicht vorhandenen Ausdrücke. Ich nehme mal an, dass die Funktionen, die ich verwendet habe, nicht ganz abwegig sind, und du wohl auch diese Bezeichner verwendet hättest. Wenn nicht, ist es ein Klacks, das zu ändern, aus genau diesem Grund verwenden wir ja nen Parsergenerator. Meine Entscheidungen sind hauptsächlich aus einer bereits vorhandenen Kenntnis der Eigenschaften von SableCC getroffen worden. Aber wie gesagt, wir wollen mit unserer Grammatik ja mathematische Ausdrücke akzeptieren. Und von mathematischen Ausdrücken haben wir wohl beide in etwa die selben Vorstellungen. Also, wo ist dann das Problem, wenn meine Grammatik dieselben Ausdrücke akzeptiert, aber die Produktionen anders aussehen ? Wohl nirgends, will ich meinen. Da ich selber einige Zeit abwesend war, weiß ich außerdem ja nicht, wie die Vorstellungen des Projekts auseinanderlaufen, und wie "Ernst" Tilmanns Entwurf auch für die C-Leute wahrgenommen wird. So, wie die Diskussionen laufen, hab ich eher nicht so das Gefühl, als wäre dies der Fall. Und wenn die Diskussionen so weiter laufen, würden wir wohl noch Monate über unsere Grammatik schwatzen. Ich hab jetzt halt mal was gemacht, das an Tilmanns und Ingberts Arbeit anknüpft. Es war nicht sehr viel Aufwand für mich, aus dem Grund hab ichs getan. Und Tilmann sowie Ingbert haben sicher schon mehr Zeit darin investiert. Da ich der Ansicht bin, dass diese vorgeschlagene Implementierung die Anforderungen erfüllt, habe ich halt meinen Beitrag dazu beigefügt. Wäre ich deinem Vorschlag auf anweisungsorientiertes Skripting gefolgt, hätte ich keine Chance gehabt, das in Tilmanns bestehendes Modell zu integrieren, dann hätte ich ein - momentan - vollkommen nutzloses Code-Fragment erstellt. Und wenn man das so betrachtet, dann hätten weder Tilmann noch Ingbert noch du noch ich mit dem Modell / der Grammatik anfangen dürfen, solange wir nicht das Auswertungsmodell für die Ausdrücke entwickelt haben. Denn dieses Modell ist mindestens genauso wichtig wie die Datenstruktur, sogar noch näher am Modell als an der Datenstruktur. Da aber die Grammatik ja immer noch in der Datenstruktur mit drinhängt, kann ich deinen Ärger natürlich verstehen. Aber ich seh das so: Till und Ingbert haben schon viel arbeit investiert, an die ich anknüpfen konnte. Ich sehe, das ihr Modell in den von dir genannte Konflikten funktioniert. Bei deinem Vorschlag sehe ich das momentan leider nicht. Mag sein, dass uns nach einiger Zeit ein Licht aufgeht, und wir sehen, dass man deinen Vorschlag wunderbar realisieren kann. Aber momentan sehe ich den anderen Vorschlag, und sehe, dass man in zumindest mal recht GUT realisieren kann. > Mittlerweile hab ich natürlich für meine Grammatik > auch einiges an Code - es gab ja keine andere, bis zu Deinem > Upload gerade. Ich bin daher davon ausgegangen, daß bis > auf die hier diskutierten Fragen "Ausdrücke oder Scripte" bzw. > "Zuweisungsoperator oder Quelle/Ziel" die vorgeschlagene > Grundstruktur der Ausdrücke bestehen bleibt. Ich bin von der > jetzt entstandenen Situation wirklich nicht begeistert ... Wie gesagt, Grammatik hin oder her. Die Sprache ist die wichtige. Und da mag es sein, dass für deinen CC eine andere Grammatik geeigneter ist (für die Implementierung, meine ich) als für mich bei SableCC. Es besteht also eigentlich echt kein Grund, sich aufzuregen. > P.S. :Ich möchte auch nochmal daran erinnern, daß es neben Java-DSAMan > auch ein C++-DSAMan gibt. Dinge, die Java und C++ gemeinsam > betreffen (insbesondere XML-Design, Grammatiken und Daten) > gehören in /data/... , nicht in /java/... arithmetic.grammar ist SableCC-spezifisch, SableCC ist Java-spezifisch, und darum hat das eigentlich nix in /data zu suchen. Wenn du mir sagst, dass dein CC die datei auch lesen kann, dann vollführe ich gerne den gewaltigen Akt, und kopiere die paar kB in /data... Die generierten .java-Dateien willst du aber wohl nicht haben, oder ? ;-) Gruß Matthias |
From: Oliver S. <os...@ep...> - 2002-05-07 20:21:55
|
Hallo Matthias! > ich mal das Zeug hochgeladen. Noch nicht alles ist implementiert und > dokumentiert, aber in net.sf.dsaman.model.arithmetic.grammar ist die > Grammatik zu finden, die man sich mal anschauen kann, die hab ich auch > ausdokumentiert. Jetzt hab ich aber mal eine Frage: Am 29.4. hattest Du gefragt, ob's schon eine Grammatik gibt (gab's ja noch nicht). Darauf hin hab ich am 30.4., also vor gut einer Woche, eine Grammatik ins CVS gestellt und hier in der Liste Bescheid gesagt, in der Hoffnung, daß wir daraus _gemeinsam_ etwas machen, das allgemeine Zustimmung findet. Wieso hast Du die Grammatik völlig ignoriert, und stellst jetzt, schon teilweise implementiert, eine komplett andere vor? So stell ich mir Zusammenarbeit ehrlich gesagt nicht vor! Zu meinem Entwurf gab's (bis auf die Beispiele) weder Zustimmung, noch Kritik. Du hast auch nicht angekündigt, an einem komplett Verschiedenen zu arbeiten. Sorry, falls mir hier irgendetwas in der Liste zu dem Thema entgangen sein sollte - falls nicht, gab es jedenfalls noch keinen Konsens, wie Scripting bzw. Ausdrücke endgültig aussehen sollen. Willst Du jetzt plötzlich vollendete Tatsachen schaffen?! Mittlerweile hab ich natürlich für meine Grammatik auch einiges an Code - es gab ja keine andere, bis zu Deinem Upload gerade. Ich bin daher davon ausgegangen, daß bis auf die hier diskutierten Fragen "Ausdrücke oder Scripte" bzw. "Zuweisungsoperator oder Quelle/Ziel" die vorgeschlagene Grundstruktur der Ausdrücke bestehen bleibt. Ich bin von der jetzt entstandenen Situation wirklich nicht begeistert ... Verwirrt, Oliver P.S. :Ich möchte auch nochmal daran erinnern, daß es neben Java-DSAMan auch ein C++-DSAMan gibt. Dinge, die Java und C++ gemeinsam betreffen (insbesondere XML-Design, Grammatiken und Daten) gehören in /data/... , nicht in /java/... |
Oliver Schulz wrote: > Hallo Matthias! > > >>Irgendwie wußte ich, dass dieses Argument kommen wird *ggg* > > > ;-) Aber zu dem Argument... Ok, die beiden gehören logisch zueinander und sind bei dir in einer Formel. Aber bei der anderen Variante sieht man auch, dass die zusammengehören, da sie ja letzten Endes in XML als Modifikatoren unter das selbe Element gehören, also z.B. als 2 Modifikatoren-Elemente unter einem Artefakt-Element. Die Übersicht wird zwar nicht in der Formel bewahrt, aber in der Datenstruktur. > > >>Was redest du da eigentlich ständig von hart coden ? Nur weil wir >>schonmal mit einem Implementierung des Charaktermodells angefangen >>haben, codieren wir noch lange nix 'hart'. Die Modi-Ausdrück holen wir > > > Tillmann schrieb, er sei zum hart coden gezwungen gewesen ... achso... Naja, ich hab den riesig langen Thread nicht ganz verfolgt. Gruß Matthias |
From: Oliver S. <wh...@us...> - 2002-05-07 19:21:57
|
Hallo Matthias! > Irgendwie wußte ich, dass dieses Argument kommen wird *ggg* ;-) > Was redest du da eigentlich ständig von hart coden ? Nur weil wir > schonmal mit einem Implementierung des Charaktermodells angefangen > haben, codieren wir noch lange nix 'hart'. Die Modi-Ausdrück holen wir Tillmann schrieb, er sei zum hart coden gezwungen gewesen ... cu Oli |
From: Matthias W. <Mat...@gm...> - 2002-05-07 19:18:47
|
So, da ich mich jetzt meinem Zahlentheorie-Übungsblatt widmen muss, hab ich mal das Zeug hochgeladen. Noch nicht alles ist implementiert und dokumentiert, aber in net.sf.dsaman.model.arithmetic.grammar ist die Grammatik zu finden, die man sich mal anschauen kann, die hab ich auch ausdokumentiert. unter ...model.arithmetic ist eine TestArithmetic.java, wo ihr das etwas austesten könnt, (da übergebe ich aber nur eine leere HashMap, d.h. ihr könnt eigentlich nur mit Zahlenwerten hantieren). In dsaman funktioniert jetzt auch die ModelTest mit den neuen ArithmeticExpressions, bei Bedarf können auch dort die Ausdrücke ausgetestet werden. Und bei der GUI hab ich das MainFrame noch etwas erweitert. Die Tabelle zeigt an, wie man mit den Plus und Minus z.B. das steigern von Talenten dem Benutzer ermöglicht (das "-" hat quasi eine undo-Funktion). Richtiges Rückgängig-machen wird wohl bei dem Regelwerk ziemlich übel, wenn nicht gar fast unmöglich. Ob wir das wirklich in dem Maße umsetzen sollen ? Gruß Matthias |
From: Matthias W. <Mat...@gm...> - 2002-05-07 19:08:31
|
Oliver Schulz wrote: > Hallo Tilmann! > > > Ich will verhindern, daß viel hart gecodet wird (womit Du ja schon > angefangen hast). Ursprünglich war vorgesehen, daß DSAMan mit möglichst > wenig Hardcoding auskommen soll, und meines Erachtens nach ist diese > diese Anforderung nach wie vor aktuell. Hinzu kommt, daß es nicht > wirklich aufwendig ist, neben den ganzen mathematischen Op's noch > einen Zuweisungsoperator zu implementieren, der einem dann aber > eine Menge Möglichkeiten eröffnet. > > > >>Geht bei meiner doch auch: >>1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0] >>2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5] > > > Ja, ist mir schon klar. Aber dann sind's halt zwei Modis, wo > einer vielleicht von der Regellogik her eine Einheit gebildet > hätte. Irgendwie wußte ich, dass dieses Argument kommen wird *ggg* > In solchen Fällen hart zu coden, und erst mal wieder eine neue Programmversion > unter die Leute bringen zu müssen, ist keine akzeptable Alternative. > Und sicherzustellen, daß in Java und C++ hart gecodete Regeln das Gleiche tun, > ist auch ein Riesenproblem. Was redest du da eigentlich ständig von hart coden ? Nur weil wir schonmal mit einem Implementierung des Charaktermodells angefangen haben, codieren wir noch lange nix 'hart'. Die Modi-Ausdrück holen wir aus XML. Die Ziele holen wir aus XML. Das ganze wird auf Objekte gemappt. Die Objekte stehen in Verbindung anhand der in XML beschriebenen Relationen. Wo, bitte, ist da die Hartkodierung ??? Wenn du Performance-Problem befürchtest, dann ist das ok. Das müssten wir in unserer Implementierung mal abschätzen. Aber wenn du die ganze Zeit von hartkodieren redest, dann ist das schlichtweg Humbug. Gruß Matthias |
From: Matthias W. <Mat...@gm...> - 2002-05-07 18:51:29
|
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 |
From: Tilmann K. <ds...@tk...> - 2002-05-07 17:46:37
|
Nochmals Hallo! Oliver Schulz wrote: > >>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? Machen wir. Matthias hat das etwas verfaelscht widergegeben. Normalerweise wird auf dem Syntaxbaum gearbeitet und nur wenn sich was geaendert hat wird neu geparst. Es wird nicht der Text eingesetzt oder so, sondern an Stelle von EIG_MR wird dann quasi zum Berechnen kurzzeitig der Syntaxbaum von MR eingehaengt. > 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?). Ja auf dem Syntaxbaum, das macht von der Rechenzeit nur sehr wenig aus, wenn man davon ausgeht dass Arithmetik in O(1) laeuft :-) > >>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. :-( Im Grunde habe ich nicht viel gemacht ich habe wie im Modell von dsaman.argo beschrieben mal Huellen(Objekte) fuer die einzelnen Features eines Charakter entwickelt mit den noetigen Grundstrukturen. Mit der neuen Parser werden die sich nochmal erheblich vereinfachen so dass hier auch ein Maximum im xml festgelegt werden kann. > > 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. Geparst halt nicht s.o. Die paar Rechnungen sind so billig, dass sie eigentlich nicht ins Gewicht fallen. > - Mangelnde Leistungsfähigkeit -> es muß viel hart gecodet werden. Nicht wirklich glaube ich. Beispiele? > - Sprachoperationen auf string-Ebene sind ein Hack, keine elegante Implementierung. Stimmt, die kann man aber auch entfernen in dem Modell. Siehe andere Mail. > - Rundbezüge lassen sich nur recht brutal auflösen, in dem ein Modi ganz rausfällt. 1. Werfen sie eine exception, wie man darauf reagiert liegt nacher am Programm 2. Ist das Problem beim Scripting das Gleiche. > > > Bitte versteht mich nicht falsch, ich respektiere eure Leistung, > per Hand diesen Parser auf die Beine gestellt zu haben. Der war von Ingbert. Matthias hat mit SableCC inzwischen 'nen neuen generiert ;-) > Ich weiß auch, daß ihr für mehr Funktionalität darin einen nicht > unerheblichen Aufwand treiben müßtet. > Aber: Mit einer sauber definierten Grammatik und einem Parsergenerator > spart man sich wirklich viel Arbeit, und muß für zusätzliche Fähigkeiten > der definierten Sprache muß man nicht viel Aufwand treiben. > 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". Welcher? Wie aufgerufen? > Es gibt für Java mehrere entsprechende Lösungen, wollt ihr nicht > doch überlegen, auf sowas umzusteigen? s.o. Gruss, tilmann |
From: Oliver S. <wh...@us...> - 2002-05-07 15:11:54
|
Hallo Matthias und Tilmann! > Da wir uns ja letzten Endes auf einen Entwurf einigen müssen > (schließlich müssen die Ausdrücke in XML rein), will ich mal versuchen, Genau, das Script/Auswurfs-Design sollte schließlich von der Implementierung unabhängig sein. Und - bitte verzeiht mir die Anmerkung: Ich halte es für falsch, beim Design schon viel über eine einfache Implementierung nachzudenken. Implementierungs- orientiertes Design führt im meist zu Ergebnissen, die sich langfristig als unflexibel erweisen. Wir haben ein Regelwerk gegeben, wir wissen ungefähr, wie wir's mit der XML-Stuktur halten wollen. Bislang war die Anforderung an DSAMan immer, leistungsfähig und leicht erweiterbar zu sein. Es war auch immer die Rede davon, möglichst wenig hart zu coden. Nach diesen Rahmenbedingungen sollten wir entscheiden, ob wir Scripting brauchen, oder ob Ausdrücke reichen. Und es kann nicht schaden, ein bischen Luft einzuplanen. > den Vorschlag von Tilmann und mir etwas näher zu beleuchten. Vielen Dank für die Ausführungen, ich hatte vorher ein etwas falsches Bild im Kopf ... :-) > 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?). > 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". Ich würde mir zu dieser Grammatik ein paar Kommentare wünschen. Passt die nun zu euren Ausdrücken, oder nicht (von Zuweisungen und durch ";" getrennten Anweisungen mal abgesehen)? > Worauf ich hinauswill: Rundbezüge können mit dem einführen von > Artefakten in unsere System durchaus entstehen. Sie müssen halt nur > abgefangen werden, bei der Berechnung also z.B. die resolve() Methode, > die einen Rundbezug auslösen lassen würde, eine Exception werfen zu > lassen, oder 0 zurückzugeben, damit dieser Modifikator "deaktiviert" Das ist aber nicht sehr userfreundlich, einfach sein Artefakt abzuschalten ... ;-) > 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. - Mangelnde Leistungsfähigkeit -> es muß viel hart gecodet werden. - 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. Bitte versteht mich nicht falsch, ich respektiere eure Leistung, per Hand diesen Parser auf die Beine gestellt zu haben. Ich weiß auch, daß ihr für mehr Funktionalität darin einen nicht unerheblichen Aufwand treiben müßtet. Aber: Mit einer sauber definierten Grammatik und einem Parsergenerator spart man sich wirklich viel Arbeit, und muß für zusätzliche Fähigkeiten der definierten Sprache muß man nicht viel Aufwand treiben. 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". Es gibt für Java mehrere entsprechende Lösungen, wollt ihr nicht doch überlegen, auf sowas umzusteigen? cu Oli |
From: Oliver S. <os...@ep...> - 2002-05-07 13:47:37
|
Hallo Tilmann! > > Modi 2 aus "Tausend und ein Ding". Offensichtlich sollte erst > > Modi 1, dann Modi 2 angewendet werden. [...] > Ja, aber das tuts bei der java-Implementierung schon von ganz alleine ohne > Ordnung und sortieren, weil der Aufruf von MR in der Berrechnung von 2. > seinerseits eine Berechnung von MR anstoesst. Das Problem mit dem Sortieren > der Reihenfolge gibt es da nicht wenn man nicht zuweisungsorientiert arbeitet. Ah, jetzt hab ich verstanden, warum Du dieses Problem nicht hast. Ok, auf die Weise gibt's keine Reihenfolgeprobleme, aber dafür wird ein Haufen Werte mehrfach, evtl. sogar sehr oft berechnet. > > Nein, je nach Implementierung entweder > > Modifikatoren-im-Regelwerk-Anzahl x 1 > > So hab ichs im Moment. Das ist mir jetzt nicht ganz klar. Du kannst doch erst parsen, wenn Du konkateniert hast? Und das kannst mußt Du doch für jeden Char einzeln machen, oder? > Ich frage mich wirklich was du mit dem ganzen script-Zeug machen willst. Ich > fuer meinen Teil will keine DSA-Programmiersprache schreiben. Ich will verhindern, daß viel hart gecodet wird (womit Du ja schon angefangen hast). Ursprünglich war vorgesehen, daß DSAMan mit möglichst wenig Hardcoding auskommen soll, und meines Erachtens nach ist diese diese Anforderung nach wie vor aktuell. Hinzu kommt, daß es nicht wirklich aufwendig ist, neben den ganzen mathematischen Op's noch einen Zuweisungsoperator zu implementieren, der einem dann aber eine Menge Möglichkeiten eröffnet. > Geht bei meiner doch auch: > 1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0] > 2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5] Ja, ist mir schon klar. Aber dann sind's halt zwei Modis, wo einer vielleicht von der Regellogik her eine Einheit gebildet hätte. > > Dabei wird der erste Modifikator sauber bei seinem Ziel dem MU-Objekt > registriert und der Zweite beim GE-Objekt. Und diese beiden wissen nacher > sogar noch welche Modifikationen von wo gekommen sind ;-) > > > > ... wenn uns Flexibilität keinen (oder nicht viel) Aufwand kostet, > > sollten wir sie wählen. > > Ich muss dazu mal folgendes Vermutung aeussern: > Ich hab jetzt die Grundregeln in java implementiert es fehlen noch > (Sonderfertigeiten, Zauber, SchlechteEigenschaften, Gaben und Vorteile zuer > Haelfte). Dabei habe ich einige Regelteile hart codiert. Und die waren zum > teil so Umfangreich, dass ich glaube, dass du eine Script-Sprache fuer DSA > zu einer fast kompletten Programmiersprache ausbauen musst, wenn du schon Was heißt komplette Programmiersprache? Schleifen kommen meines Erachtens nicht in Frage, desgl. Funktionsdefinitionen, etc. Aber: Arithmetik, Boolarithmetik, Schachtelung und bedingte Ausdrücke sind eh schon eine nette Grundlage, und die hast Du doch auch vorgesehen. Wenn man da lediglich Zuweisungen und die Möglichkeit mehrer Anweisungen (Script) hinzufügt, gewinnt man sehr "kostengünstig" die Möglichkeit, so manches Regelproblem elegant lösen zu können. In solchen Fällen hart zu coden, und erst mal wieder eine neue Programmversion unter die Leute bringen zu müssen, ist keine akzeptable Alternative. Und sicherzustellen, daß in Java und C++ hart gecodete Regeln das Gleiche tun, ist auch ein Riesenproblem. cu Oliver |
From: Tilmann K. <ds...@tk...> - 2002-05-06 22:48:54
|
Hallo Oliver! Oliver Schulz wrote: > Man stelle sich folgenden Fall vor: > > 1. Talent "Meditieren" gibt +1 auf MR, wenn TaW.basis > 10. > 2. Artefakt "Mighty Alrik" gibt +5 auf KK, aber > wirkt nur, wenn MR(.effektiv!)<=4. > > Nehmen wir an, Modi 1 kommt aus der Regelbox "Mohas in der Wüste", > Modi 2 aus "Tausend und ein Ding". Offensichtlich sollte erst > Modi 1, dann Modi 2 angewendet werden. Ja. > Aber das kann unmöglich > schon in den Modulen drin stehen, die gar nix voneinander wissen. > Ergo muß das Programm das schon selbst rausfinden. Ja, aber das tuts bei der java-Implementierung schon von ganz alleine ohne Ordnung und sortieren, weil der Aufruf von MR in der Berrechnung von 2. seinerseits eine Berechnung von MR anstoesst. Das Problem mit dem Sortieren der Reihenfolge gibt es da nicht wenn man nicht zuweisungsorientiert arbeitet. > >>Wie gesagt, dass kann man machen, man braucht dann aber wieder fuer jeden >>Modifikator einen Wrapper im Charakter. Und das sind wirklich sehr viele > > > Na und? So groß sind die Syntaxbäume nicht. Es ist ja auch für jede > Eigenschaft, jedes Talent, jedes XYZ ein Wrapper geladen. Ich hab mir diese Moeglichkeit auf jeden Fall mal offen gehalten. > Nein, je nach Implementierung entweder > Modifikatoren-im-Regelwerk-Anzahl x 1 So hab ichs im Moment. > oder > Im-Charakter-benutzte-Modis x Geladene-Charakter-Anzahl. Das meinte ich eigentlich. > > > >>Nein! Beim Auswerten wird direkt auf dem Syntaxbaum gearbeitet. > > > Nun, dann mußt Du eh den gesamten Syntaxbaum im Speicher halten. > Und ein großer Syntaxbaum ist auch nicht viel kleiner als mehrere > einzelne kleine (wenn überhaupt). Im Prinzip schon nur wird der Syntaxbaum vom Parser erstellt, der seinerseits von Matthias mit SableCC erstellt wurde und wir wollen eigentlich nicht in diesem Code rumpfuschen. > Und die Scripte auf (Script-)Quellcodeebene zusammenzukleben - > das fühlt sich wie ein Hack an ... :-) Jep, bei der Java-version gibts aber keine Scripte in dem Sinne es gibt nur Arithmetische und Boolsche Ausdruecke. > > > >>>Hier bietet sich auch eine schöne Möglichkeit an, mit geringem Aufwand >>>die Reihenfolge-Problematik zu erledigen. Die Syntaxklassen bekommen >> > [...] > >>auch keine Reihenfogekonflikte. Ausserdem widerspricht die Vorgehensweise >>mit den Zuweisungen dem "Relationen als Nachrichten"-Konzept und macht das > > > Ist ja nur ein Implementierungsvorschlag, das kann in Java ja völlig > anders gemacht werden, als in C++. sicher > Das mit dem "Relationen als Nachrichten" hat nix damit zu tun, > ob man schreibt ziel="x", quelle="y", oder "x=y" ist semantisch > identisch. Es ist auch kein Problem, im zweiten Fall das Ziel > zu ermitteln, das steht im Syntaxbaum ja deutlich drin. Ok ich kann es dann mittels Vorverarbeitung trennen durch Substring before/after "=", im Syntaxbaum hat es bei uns nix verloren geparst wird dann nur der zweite Teil. > Ich will auch gar nicht mit dem Scriptdesign eine Implementierung > festlegen, ich möchte, daß das Scriptdesign kompakt, elegant, > leistungsfähig und leicht zu handhaben ist (v.a. in der Anwendung). Ich frage mich wirklich was du mit dem ganzen script-Zeug machen willst. Ich fuer meinen Teil will keine DSA-Programmiersprache schreiben. > Ein Modifikator ist eine logische Einheit (Quelle und Ziel), warum > soll man ihn auseinanderreißen? Genauer gesagt Quelle(Rasse), Wirkung(+2), Ziel(Talent Schwimmen) > Zudem hält man sich mit meinem Ansatz einfach mehr Möglichkeiten offen, > z.B. Modifikatoren mit mehrenen, oder sogar variablen Zielen > ("a<b ? MU+=5 : GE+=5"). Geht bei meiner doch auch: 1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0] 2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5] Dabei wird der erste Modifikator sauber bei seinem Ziel dem MU-Objekt registriert und der Zweite beim GE-Objekt. Und diese beiden wissen nacher sogar noch welche Modifikationen von wo gekommen sind ;-) > ... wenn uns Flexibilität keinen (oder nicht viel) Aufwand kostet, > sollten wir sie wählen. Ich muss dazu mal folgendes Vermutung aeussern: Ich hab jetzt die Grundregeln in java implementiert es fehlen noch (Sonderfertigeiten, Zauber, SchlechteEigenschaften, Gaben und Vorteile zuer Haelfte). Dabei habe ich einige Regelteile hart codiert. Und die waren zum teil so Umfangreich, dass ich glaube, dass du eine Script-Sprache fuer DSA zu einer fast kompletten Programmiersprache ausbauen musst, wenn du schon die im Standardregelheft vorkommenden Faelle damit abdecken willst. > >>>Sollten Wiedersprüche der Form ScriptA < ScriptB < [...] < ScriptA auftreten, >> > [...] > >>Die stellen in der Aktuellen java-Version sicher ein Problem dar, das >>allerdings nur dann auftritt, wenn jemand in den Regeldefinitionen rumpfuscht. > > > Wir bauen einen modularen Charaktergenerator. "Rumpfuschen" wird > hoffentlich keiner, aber es werden von unterschiedlichen Leuten > gebaute Regelmodule zusammenkommen, dann noch die Sonderregeln und > Gegenstände der User, usw. Das kann und wird nicht alles genau > aufeinander abgestimmt sein. > Das hat sich erledigt ich hab eine simple Loesung fuer solche Schleifen gefunden. Viele Gruesse, tilmann |
From: Matthias W. <Mat...@gm...> - 2002-05-06 20:21:34
|
Da wir uns ja letzten Endes auf einen Entwurf einigen müssen (schließlich müssen die Ausdrücke in XML rein), will ich mal versuchen, den Vorschlag von Tilmann und mir etwas näher zu beleuchten. Es wurden ja schon ein paar Konflikte erläutert, die unsere Implementierung ohne größeren Aufwand bewältigt. Unser Ansatz ist so: Es geht letzten Endes nur um Modifikatoren, die auf irgendwelche steigerbaren oder nicht-steigerbaren Basiswerte addiert werden. Diese Modifikatoren haben einen Wert, der ganz simpel sein kann ("-2", "5"), aber auch eine Formel enthalten kann ("(EIG_KO+EIG_KO+EIG_KK)/2" für die LE) Wie man sieht, enthalten diese Formeln keine Zuweisungen, sondern nur Ausdrücke, die einen Zahlenwert (double) zurückliefern. Nun zu den Konflikten, derer es ja 2 gibt: I Rundbezüge: Diese dürfen einfach nicht auftreten, da sie mathematisch nicht berechenbar sind. In unserem Modell ist es sehr einfach, einen solchen Rundbezug zu lokalisieren und abzufangen. II Abhängigkeit von der Berechnungsreihenfolge: Nehmen wir gleich mal das konkrete Beispiel aus der anderen Mail: 1. Talent "Meditieren" gibt +1 auf MR, wenn TaW.basis > 10. 2. Artefakt "Mighty Alrik" gibt +5 auf KK, aber wirkt nur, wenn MR(.effektiv!)<=4. Tilmanns Relationsmodell sammelt zunächst mal alle Modifikatoren: Die wäre hier: - ein Modifikator auf "EIG_MR" mit dem Wert "[TAL_Meditieren > 10 ?1 :0]" Also ein Modifikator, der den Wert 0 oder 1 hat - und 1 nur dann, wenn Meditieren > 10 ist. - ein Modifikator auf "EIG_KK" mit dem Wert "[EIG_MR <= 4 ? 5 : 0]", also ein Modi, der die +5 nur bewirkt, wenn die MR <= 5 ist (das .effektiv wurde hier weggelassen, da EIG_MR standardmässig den effektiv-Wert zurückliefert. Es ist in unseren Ausdrück auch möglich auf Basiswerte zuzugreifen, dies sei hier nur angemerkt (durch z.B. EIG_MU.basis)) ok, das wären also die beiden Ausdrücke in unserer Form. Was passiert nun also, wenn man die KK haben will ? Wir haben dazu folgedes Modell: ArithmeticExpression kk = alrik.getFeature("EIG_KK"); // alrik ist hierbei eine Instanz der Klasse Charakter double kk_wert = kk.resolve(); was passiert bei kk.resolve() ? kk.resolve() erstellt zunächst mal einen neuen String, der so aussieht: "<Basiswert=10> + <ModiXYZ = 2> + [EIG_MR <= 4 ? 5 : 0]" 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]" der durch unseren Parser gejagt wird. Es passiert folgendes: Es sind in dem Ausdruck eigentlich nur Zahlen, bis auf EIG_MR. Der Ausdruck wird interpretiert, und wenn auf den Identifikator "EIG_MR" gestoßen wird, kommt der Gag bei unserer Implementierung: Dem Parser wird nicht nur der String übergeben, sondern auch eine Map, die alle Eigenschaften, Talente, etc, also 'Features' enthält. Über ArithmeticExpression arithExp = Map.getid("EIG_MR"); erhalte ich diese Eigenschaft. Um jetzt den eigentlichen Wert zu erhalten, wird hier wiederum die .resolve() Methode aufgerufen. Damit komme ich zu einem Term, der den Effektiv-Wert der MR darstellt und der als Unterterm den 1. Modifikator enthält: "[TAL_Meditieren > 10 ?1 :0]" Hier kann das TAL_Meditieren wiederum aus der mitgelieferten Map gewonnen werden und mittels resolve() ausgewertet werden. irgendwann haben wir dann nur noch Zahlenwerte in unserem kk-Term, da alle Identifikatoren ausgewertet wurden. Das interpretieren dieses Ausdrucks ist dann kein Kunststück mehr und wir haben unseren EIG_KK Wert mit allen möglichen Modifikatoren, also auch den +5 aus dem 'Mighty Alrik', wenn denn unser Held die nötigen Bedingungen erfüllt. Und nochmal zu den Rundbezügen: Ich erinnere mich gerade, dass es schon in Diablo Items gab, die man nur ab bestimmten Bedingungen anziehen konnte. Ich erinner mich an einen Kumpel von mir, der zwei solche Items hatte, die er nur anziehen konnte, wenn er *BEIDE* anhatte. War er zuvor "nackt" und wollte sie anziehen, ging das nicht, da er den einen nicht ohne den anderen tragen konnte, und man in Diablo Items ja nur nacheinander anziehen konnte. Mein Kumpel hatte dan einfach ein drittes Hilfsitem, das er anzog, um das eine Item anzuziehen. Dann zog er noch das zweite Item an, und zog danach das Hilfsitem wieder aus. Und schon hats geklappt. Worauf ich hinauswill: Rundbezüge können mit dem einführen von Artefakten in unsere System durchaus entstehen. Sie müssen halt nur abgefangen werden, bei der Berechnung also z.B. die resolve() Methode, die einen Rundbezug auslösen lassen würde, eine Exception werfen zu lassen, oder 0 zurückzugeben, damit dieser Modifikator "deaktiviert" wird. Ein drittes "Hilfsitem" wie oben beschrieben, wird es wohl nicht geben. Wir müssen dem Benutzer halt mitteilen "das geht nicht, weil du das haben musst, um ... ". Damit er weiß, wo der Haken ist, und die Items, die sie bewirken, deaktivieren kann. Im Standardregelwerk wird es solche Bezüge allerdings nicht geben. Falls doch, haben wir: a) das Regelwerk falsch in XML übertragen b) einen Fehler im Regelwerk entdeckt In beiden Fällen ist dieser Fehler im Regelwerk sofort zu beheben, und kann eigentlich als Bug unseres Programms aufgefasst werden. Der Benutzer kann hier nicht mehr korrigierend eingreifen (es sei denn, wir lassen ihm die Möglichkeit, das Basisisregelwerk zu ändern, wovon ich mal NICHT ausgehe). So, ich hoffe, ich konnte euch unseren Ansatz etwas näherbringen. Er ist auch schon zu 80% implementiert, und ich werde in den nächsten Tagen auch das nötige uploaden, damit ihr es euch mal betrachten bzw. testen könnt. 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. Gruß Matthias |