Mathem. Parser: Endlich "fertig"

[dizzy]

Summdidummdidumm, habe heute mal meinen Parser "releasefertig" gemacht (hoff ich ).

Im Anhang ein Archiv dass 2 Versionen enthält: Die "normale" Version als Delphi-Source, und die DLL-Version. Beide mit nem klitze kleinen Beispielprogramm, und ausführlichen readme's.

Ich betrachte das Teil jetzt als für "fertig genug" um es als Päckchen zu verschnüren und es als Freeware hier einzustellen.

Viel Spaß damit, und wenn Fragen sind... dafür sind wir ja hier


MfG,
dizzy

[dizzy]

@SirT:
1.) Danke
2.) *gnarf* da hab ich mal einen Tag meinen 2. Moni nicht dran, so dass mir das nicht auffiel... aber so schlimm is ja nicht.

Zitat von shmia:

Könnte man nicht die 8 Variablen auf beliebig viele erweitern, in dem man eine Callback-Methode verwendet um die Variablen aufzulösen ?
Also anstatt maximal 8 Variablen von Aussen der Klasse TCQParser reinzugegeben, ruft TCQParser
das Event OnGetVariable auf wenn eine Variable in einen nummerischen Wert verwandelt werden soll.

Das würde ein komplettes rewrite des Variablenhandlings erfordern. Und dann ergäben sich 2 Fragen/Probleme:
1.) Wie sollten die Variablen im String heissen müssen? Jetzt ists 'A' bis 'H'. Würde man bei diesem System bleiben ist bei 26 Variablen wieder Schluss.
2.) Man kann die Variablennamen selber definieren. Deutlich erhöhter Aufwand, aber an sich elegent. Problem: Würde man die Variable 'pi' definieren, würde die implementierte Konstante "überschrieben". Definiert man '6' als Variable könnte es bald echt komisch aussehen
Man müsste also Einschränkungen vornehmen.

Letztes ist aber durchaus nicht uninteressant! Nur habe ich etwas in dieser Art noch NIE gemacht. Würde mich freuen, wenn du mir mit ein paar Schnipselchen helfen könntest. Dann kann ja bald Version 1.1 folgen

Zitat von shmia:

Leider kann mein D5 den Sourcecode wegen einigen fehlenden Funktionen (Sign, SameValue, Sec, SecH, ...) nicht kompilieren.

Deswegen u.a. ja auch die DLL-Version
Habe befürchtet, dass es mit niedrigeren Delphiversionen da zu Problemen kommt, hatte aber nicht wirklich große Lust die eventuell fehlenden Funktionen selbst zu implementieren. Auch daher hatte ich mich für die DLL entschieden. Sorry

[dizzy]

Neues Update im ersten Beitrag.

Das Presolving funktioniert nun endlich wie es soll, und Divisionen bei komplexen Zahlen und Quaternionen führen jetzt nicht mehr zum Absturz wenn die Imaginärteile Null sind.

[Niels]

Hallo,
es ist natürlich möglich, dass ich da was falsch mache, aber irgendwie funktioniert folgendes nicht:

ich geb ein 4^0.5 oder 4^(0.5) ein und er gibt mir immer als Ergebnis 1024 . Noch besser wird's dann bei 4^(1/2), da kommt nämlich 4 raus. Eigentlich sollte das ja imho 2 sein. 4^(2/2) ist eben dann bei dem Parser 16 anstatt 4.
Hoffe, dass sich das einfach beheben lässt oder der Fehler irgendwie an mir liegt

mfg Niels

[Niels]

Das Beispiel berechnet er zwar richtig. Frag ich ihn jedoch einfach nach cos(2A) und lösche den Rest, gibt er mir -0,4161 als Ergebnis. Das Faszinierende daran ist jedoch, dass cos(2A)*2 = 2 ist. Das soll jetzt noch einer verstehen

PS: Tippe ich ein 2 / 2 * cos(2A) kommt 1 raus, wie bei cos(2A) auch rauskommen sollte

mfg Niels

[dizzy]

Das versteh wer will! Das komische ist ja, dass das ausschließlich bei der DLL-Version so ist! Die Unit-Version berechnet alles völlig korrekt.
Das komische nur: Die DLL macht nichts anderes als eine Instanz der exakt gleichen Parserklasse zu erzeugen, die in der Unitversion enthalten ist! Die Funktionen sind lediglich Wrapper um die Funktionen des Parsers selber. Also da komm ich grad nicht mehr ganz mit - das bedarf intensiverer Nachforschungen!!!

Suuuper heissen Dank für die Meldung!

Also ist die DLL-Version z.Zt. noch etwas buggy - es wird ein Update folgen!

[dizzy]

Zitat von NicoDE:

Hab es bei mir in out-Parameter geändert (und ShortString in PAnsiChar)

...und genau DAS sorgt für das Problem. Scheinbar gibt es mit ein paar Zeichen Probleme, so z.B. mit Klammern. Oder irgend etwas anderes ist da komisch. Mit ShortString, wie ich es vorher hatte, geht es völlig problemlos.

@Nico: Wie war das bei dir? Sind die berechneten Werte dann auch so "komisch", oder sind sie korrekt? Wenn letzteres zutrifft, wäre ich an dem Schnipsel aus dem DLL-Source interessiert

Bis zur endgültigen Klärung ob nun ShortString sein muss, oder es doch mit PAnsiChar geht lade ich mal nix neues hoch. Es sei nur darauf hingewiesen, dass die DLL-Version z.Zt. besser nicht verwendet wird

[dizzy]

Sööööö, nun kommt auch schon Version 1.1

Was ist neu?

1.) Die DLL-Version funktioklappt wieder. (Hab dann doch erstmal wieder ShortString genommen...)
2.) Man kann sich jetzt bis zu 1024 Variablen selbst definieren - auch deren Namen (bis 255 Zeichen pro Variable)!

Jetzt sind auch kompilierte Versionen der kleinen Beispiele dabei. (Da ich aber das nonVCL nicht wirklich beherrsche bläht das das Archiv auf 1/2 MB auf )


...jaja, ich bin unermüdlich

[NicoDE]

Zitat von dizzy:

Wie war das bei dir?

Ich hab in der DLL den PAnsiChar nicht direkt benutzt sondern in eine lokale ShortString-Variable kopiert (da alle Deine Funktionen ShortString verwenden und jemand auf die Idee kommen könnte einen PAnsiChar länger als 255 Zeichen zu übergeben...).

ps: ich mag ShortStrings nicht, da sie ohne const/var/out auf dem Stack übergeben werden...

[naudoc]

Hallo,

in deinem Bsp. ist sin(3,14)=0,1411. Warum das?
Und 3,14=3...
Ich versteh das nicht so ganz...

mfG

[fLaSh11]

Noch einen Fehler:

Code:

cos 90

müsste 0 ergeben.
Bei dir: -0,4481