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

[NicoDE]

Die Integration der DLL in andere Sprachen ist IMHO unnötig schwierig (wer gibt den Speicher bei komplexen Strukturen als Rückgabewert wieder frei? etc.). Hab es bei mir in out-Parameter geändert (und ShortString in PAnsiChar) und es so in einem Watcom-Projekt verwendet.

Gruss Nico

[dizzy]

:thuimb:
Hab noch nie zuvor eine DLL gebastelt. Danke für die Tipps - upgedatete Version im ersten Beitrag.

btw: Hast du ihn jetzt "richtig" im Einsatz, oder nur testweise? Wäre natürlich klasse, wenn das Teil tatsächlich jemand gebrauchen könnte... :stupid:

[NicoDE]

Zitat:

Zitat von dizzy

Hast du ihn jetzt "richtig" im Einsatz, oder nur testweise?

Hab im Moment keine Verwendung dafür und es nur mit Open Watcom C/C++ getestet (brauchte ich gerade für eine 16-Bit DLL), da mich das Projekt interessiert...

Hast Du in dem anderen Thread gesehen, dass die Bestimmnung der Zeitdauer im Performance-Test unter Windows XP x64 (amd64) merkwürdige Werte liefert?
(ich vermute mal es liegt an den Berechnungen mit den RDTSC-Werten)


Gruss Nico

[dizzy]

Zitat:

Zitat von NicoDE

Hast Du in dem anderen Thread gesehen, dass die Bestimmnung der Zeitdauer im Performance-Test unter Windows XP x64 (amd64) merkwürdige Werte liefert?
(ich vermute mal es liegt an den Berechnungen mit den RDTSC-Werten)

Ach ja, ganz vergessen da zu antworten :oops:. Auf der ersten Seite in diesem Thread hatte auch jemand so interessante Ergebnisse. Wieder besseren Wissens hab ich auch das damals auf die Messmethode geschoben, und ich tu's wieder :)
Ich nehme mal an, dass beide OSs auf ein und der selben Maschine laufen? Dann wäre der "Übeltäter" nämlich offensichtlich. Dann haben wir nen Bug in der Debugversion ;)

Danke nochmals für's Testen, insbesondere mit C. Da bin ich aber froh, dass das hin haut! (btw: Bei diesem Test sah man ja recht deutlich, dass ein 64-Bitter mit nem 32-Bit OS so überhaupt gar keine Vorteile bringt. Sollten die Messwerte unter Win64 tatsächlich so stimmen, so muss ich sagen, dass die Dinger mit dem richtigen OS aber mal gut abgehen :mrgreen:)


gruss,
dizzy

[NicoDE]

Zitat:

Zitat von dizzy

Dann wäre der "Übeltäter" nämlich offensichtlich. Dann haben wir nen Bug in der Debugversion ;)

Werd's mir bei Gelegenheit mal im Detail ansehen (sieht aus wie die Mess-Methode von Hagen).

Zitat:

Zitat von dizzy

(btw: Bei diesem Test sah man ja recht deutlich, dass ein 64-Bitter mit nem 32-Bit OS so überhaupt gar keine Vorteile bringt.

Ich finde es schon erstaunlich, dass man mit einem Core-Takt von 1800MHz die Performace eines P4 mit 2800MHz erreicht.
Ansonsten bringt es keine Vorteile, wie auch :D

Zitat:

Zitat von dizzy

Sollten die Messwerte unter Win64 tatsächlich so stimmen, so muss ich sagen, dass die Dinger mit dem richtigen OS aber mal gut abgehen :mrgreen:)

Unter x86-64 ist die Daten-/Code-Ausrichtung wichtig (ist bei ia64 noch schlimmer) da es sonst andauernd zu internen Alignment-Exceptions kommt (bekommt das Programm nichts von mit). Dadurch kann die Performance auf etwa 50% runter gehen.


Gruss Nico

[dizzy]

Zitat:

Zitat von NicoDE

(sieht aus wie die Mess-Methode von Hagen)

Ist sie auch :)

Zitat:

Zitat von NicoDE

Ich finde es schon erstaunlich, dass man mit einem Core-Takt von 1800MHz die Performace eines P4 mit 2800MHz erreicht.

Nuja, aber die 64-Bit spielen da aber scheinbar keine so große Rolle. Mein 2500+ @~3131+ (2.16 GHz real) macht da ja bessere Werte als der neue... Ich stehe was den Desktopeinsatz angeht den 64ern skeptisch gegenüber. Aber das ist nen völlig anderes Thema.

Zitat:

Zitat von NicoDE

Unter x86-64 ist die Daten-/Code-Ausrichtung wichtig (ist bei ia64 noch schlimmer) da es sonst andauernd zu internen Alignment-Exceptions kommt (bekommt das Programm nichts von mit). Dadurch kann die Performance auf etwa 50% runter gehen.

Okay, ich versteh knapp die Hälfte. Aber klingt gut! :lol: (Ich mutmaße mal das hat was mit der "Superskalarität" (was ein Wort) zu tun? *insblauerat*)


n8i,
dizzy

[NicoDE]

Zitat:

Zitat von dizzy

Okay, ich versteh knapp die Hälfte.

x86-64 ist die Architekturbezeichnung (bei Microsoft auch kurz x64 ;)).
(i386, p4 = x86 und amd64 = x86-64)

Der Prozessor löst eine Exception aus, wenn auf nicht ausgerichtete Adressen zugegriffen wird (gibt's beim x86 nicht - siehe SetErrorMode).
Beispiel: Lesen eines Word-Wertes von einer ungeraden Adresse (x86 = zwei Lesezugriffe, x86-64 = Exception).

[SirThornberry]

Find den Parser supi. Am Beispielprogramm stört mich nur das Position = poDesktopCenter ist. Wenn man 2 Bildschirme hat landet das programm zur Hälfte auf dem einen und die andere Hälfte auf dem zweiten bildschirm. Besser wäre da poScreenCenter..

[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.
Leider kann mein D5 den Sourcecode wegen einigen fehlenden Funktionen (Sign, SameValue, Sec, SecH, ...) nicht kompilieren. :cry:

[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:

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:

Zitat von shmia

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

Deswegen u.a. ja auch die DLL-Version :zwinker:
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 :angle2:

[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 :shock: . 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 :wink:

mfg Niels :thuimb:

[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 :thuimb:

[dizzy]

:shock: 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:

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 :D

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 :mrgreen:

[NicoDE]

Zitat:

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

[Khabarakh]

Hm? cos 90 = -0,44807361612917015236547731439964 ist absolut (jedenfalls +-.5e-32 ;) ) richtig.
0 = cos 90°