Mathem. Parser -- bitte testen

[Robert_G]

@dizzy

Delphi-Quellcode:

function Ticks(Cycles: Int64): Double;
// rechnet Taktzyklen in Millisekunden um
begin
  Result := Cycles * 1000 / CPUFrequency;
end;

Ich denke mal, dass das ziemlich am realen Ergebenis vorbeisaust, wenn der AMD eine angeblich 32-mal höhere Frequenz hat, oder AMD hat es endlich geschafft Intel einzuholen :lol: .

p.s.: der P4 war nach meiner subjektiven Empfindung ca. doppelt so schnell. ;)

Nachtrag:

Zitat:

:?: Warum interessiert es ihn nicht!? Ich dachte immer HT sei sowas wie das AllSchnellMittel...

Weil die Anwendung single threaded läuft. Deshalb kann sie schlecht auf beide Pseudo-Chips verteilt werden. ;)

[dizzy]

Zitat:

Zitat von Luckie

Äh, wie ermittelst du die Zeiten? Mit GetTickCount wird das nichts. Da du dann auch die Zeiten mit misst, die dein Thread im Ruhezustand ist. Und wenn da noch ein paar Prozesse laufen, kann das schon mal etwas länger dauern, bis du wieder dran bist. Besser ist da schon GetThreadTimes. Eventuell wäre es auch sinnvoll die reinen Taktzyklen der CPU zu messemn, dann bist du systemunabhängig.

---> damit
(Und sorry Hagen, du hattest 'nur' den Zusatz geposted. Die Routine ist ja von... ja von Luckie)

[fkerber]

Hi!

Zitat:

Zitat von Luckie

Äh, wie ermittelst du die Zeiten? Mit GetTickCount wird das nichts

Zitat:

Zitat von dizzy

Die Dauer wird mittels des vom BIOS geführten Clock-Counter ermittelt (ich glaube die Routine ist von Hagen hier...).

Ciao fkerber

[Alexander]

Zitat:

Zitat von dizzy

@Alex: :shock: ...uhmm, ich werd's mal versuchen! (Ob ich DA noch durchsteige *g*) Was die Assemblerteile angeht: (Mehr als da benutzt kann ich auch nicht ;) ) und in "QMath2.pas" sind exakt die selben Funktionen nochmal in DL-Klartext.
Aber stimmt... da müssen auf jeden Fall noch ein paar mehr Kommentare rein. Sonst blicke ich das Teil in 1/2 Jahr selber nicht mehr. Sind ein paar Kniffe drin :zwinker:
(Dürfen die Kommentare auch englisch sein? Ich mach's immer lieber glech international *g*)

\\edit: btw:
AMD 2500+ Real: 1833 MHz
AMD 3000+ Real: 2167 MHz (hab ich fast, da FSB auf 195MHz getuned ;) 200 ging net mehr... )

Hi,
die andere Unit QMAth2.pas habe ich doch glatt übersehen, dann ist das ganze mit den Kommentaren nicht so tragisch, aber wenn du es doch noch machst, dann bedanke ich mich an dieser Stelle mal ;-)
Achso wenn du noch Kommentare machst, dann ist mir das vollkommen gleich, ob Englisch oder Deutsch ;-)

PS: Vielleicht sollte ihc mich doch mal mit Assembler beschäftigen :pale: :mrgreen:

[Muetze1]

Moin!

So, ich habe das Ding auch mal getestet. Ich benutze Delphi 5 Prof (Update Pack 1) (mit den vorher gehenden Änderungen im Code) auf einem P4 mit HT auf 3.0 GHz.

Beim aller ersten Lauf braucht er bei der Delphi Rechnung recht lange, bei einem sofortigen 2. Start (ohne das Prog zu beenden) geht's bedeutend schneller.

Die Zeiten (2. Durchlauf, 1. Durchlauf hatte auch nix "positiveres"...):
-189173
-370250
-912305
-1,83168E6

Nochwas allgemeines: im Kommentar im Header sind ein paar Rechtschreibfehler (address mit Doppel-d, I z.T. klein geschrieben, etc).

MfG
Muetze1

[dizzy]

Zitat:

Zitat von Muetze1

So, ich habe das Ding auch mal getestet.

thx!

Zitat:

Zitat von Muetze1

Die Zeiten (2. Durchlauf, 1. Durchlauf hatte auch nix "positiveres"...):
-189173
-370250
-912305
-1,83168E6

Mit scheint, dass die Zeitmessungsmethode ein wenig Probleme mit nem P4 hat :?

Zitat:

Zitat von Muetze1

Nochwas allgemeines: im Kommentar im Header sind ein paar Rechtschreibfehler (address mit Doppel-d, I z.T. klein geschrieben, etc).

:oops: Wird behoben. War schnell hingekritzelt... Und ich mag es irgendwie nicht "I" groß zu schreiben. Sieht so egozentrisch aus ...aber die Regel schreibt's vor - hast ja Recht ;)

Danke dir! Und an der Performancemessung muss ich wohl noch mal was machen... dann wird's weniger akkurat, aber sollte zumindest überall klappen. Schade das.


MfG,
dizzy

[CalganX]

Hi dizzy,
interessieren dich die Ergebnisse immer noch? ;)

• Delphi: Delphi 7 Professional
• Compilieren? Geht wunderbar. :)
• CPU: AMD Athlon XP 2200+ mit 1.85Ghz (ich bekenne mich dazu ihn um 4MHz getaktet zu haben :oops:)
• Ausgabe: Die Zeiten sind: 972,224 | 1730,09 | 4438,15 | 8695,65

War da noch was, was du wissen wolltest? :gruebel:

Chris

[dizzy]

Ja na klar! Ich schraube noch immer an dem Teil rum. Mittlerweile kann er sogar konstante Teile einer Formel vorausberechnen, so dass das Lösen dann noch fixer geht :) (je nach Verwendung der Variablen natürlich)

Was ich noch interessant fände, wäre noch die Sache mit der "Optimalität" des QT. Keine Leaks? (Hab bisher keine gefunden.) Ist er schön? ;) Sind die verwendeten Techniken auch wirklich die performatesten/komfortabelsten? Braucht das überhaupt wer :?: :mrgreen:

Danke dir Chak!

[S2B]

So, ich habs auch mal getestet:

• Delphi 7 PE
  Compilieren geht
  Pentium 4 2,66 GHz
  Von oben nach unten: 915,379 :arrow: 1882,91 :arrow: 4203,26 :arrow: 8365,59

[mschaefer]

Moin, moin,

im Anhnag findet sich die Version für D4,
sollte auch mit D3 laufen. Die Zeiten auf
dem alten Rechner spare ich mir aber.

Grüße // Martin

[Kastor]

Hi,

- Delphi7 Professional (kompiliert ohne Probleme)
- Ergebnisse sind korrekt
- Amd Athlon 2800+, gibt so um die 2 Ghz Realtakt

Ergebnisse (von oben nach unten):
850,968
1478,88
3733,95
6893,12

Gruß, Kastor

[neolithos]

• Delphi 7 Prof
  Celeron 1 GHz
  1633,33
  3007,94
  6480,49
  12938,5

Kritik: Der Parser ist sehr ausprogrammiert und schlecht erweiterbar.

Schau die mal ein paar Seiten zum Thema Compilerbau, Deterministisch Endlicher Automat, Optimierung, ZwischenCode usw. an.

Denn in dem Copy&Paste-Code möchte ich nie etwas ändern.

[dizzy]

Zitat:

Zitat von neolithos

Kritik: Der Parser ist sehr ausprogrammiert und schlecht erweiterbar.

Eigentlich nicht. Zur Erweiterung genügt es zb. einen neuen Operator einzufügen, und dessen Behandlung in den großen "if..then..else"-Zweig einzusetzen. Zwar muss man etwas darauf achten, wo man diese Behandlung einfügt, aber ich hab ihn ja ständig selbst erweitert - z.B. kennt er mittlerweile Konstanten wie pi oder e.
Ihn voll "customizable" zu machen, das wollte ich nicht, da dass erheblich an der Performance gedrückt hätte, und ich wollte das Teil so schnell wie auch nur irgend möglich machen. Das war im Gegensatz zur Erweiterbarkeit oberstes Ziel, daher auch meine Testreihe hier.
Habe das Ding jetzt sogar in eine DLL verpackt, so dass das mit der Erweiterbarkeit ohnehin flach fällt, man ihn aber in beliebigen Sprachen einsetzen kann (die DLLs einbinden können...).

Ein paar kleine Finetunings sind noch nötig, und dann werd ich den nochmal komplett mit Source+DLL hier einstellen. Und es sollte garnicht nötig sein ihn zu erweitern, da ich eigentlich so ziemlich alle Grundoperationen drin hab, incl. der eigentlich nie gebrauchten trigonometrischen Funktionen für Quaternionen :roll: :)

Speed war deshalb oberstes Gebot, da ich mit dem Teil 3D-Fraktale berechne, und da kommen sehr leicht > 10.000.000 Rechendurchläufe pro Formel rum.

Wenn diverse Funktionen fehlen sollten, die ihr vermissen würdet, so bin ich offen für Vorschläge! Das Dingen sollte nachher als Monolit dastehen, d.h. fertig und rund. Zwar OpenSource, aber nicht mit der Notwendigkeit dran rumzufummeln :). Wobei das wie gesagt garnicht so unmöglich ist :cyclops:.

Danke aber für den Tipp, ich hatte diesen Aspekt noch nicht als einzelnes betrachtet.


grüzli,
dizzy

[neolithos]

Genau so könnte man aber Speed rausholen.


Grund: Wenn du die Formel zu einer schnell durchrechenbaren Sprache umcompilierst und opimierst, vermute ich, dass das Teil schneller wird.

Bei Meinem Formel-Parser (der langsamer ist, durch Typenkonvertierungen und OOP) gehe ich wie folgt vor.

(1 + sin(A))^3 * (1+1)

Erster Schritt:

zerlegen in Token (Teile):

"1" "+" "sin" "(" "A" ")" "^" "3" "*" "(" "1" "+" "1" ")"
Dies erledigt eine while Schleife gekoppelt mit einer Matrix.

Baue aus den Tokens einen Parsebaum:

Dazu wird ein vor definierter Syntax-Graph durchlaufen.
-> Wieder nur eine while-Schleife

Optimiere den Code:
in dem Fall wird 1+1 zusammengefasst.

Erzeuge Code:

Code:

push 1
push a
sin
and
push 3
power
push 2
mul

Und die Ausführung dieses Code's könnte man extrem Optimieren.
Array für Stack.
Sprung-Tabelle für Proceduren.

[ripper8472]

@neolithos:

deinen Ansatz mit den bäumen verfolge ich auch gerne, besonders in PHP. Was ich persönlich nicht verstanden habe ist dein erzeugter code mit "pushes", deren verwendung mir nicht klar ist (sieht nicht wie assembler aus).

greets ripper

(sorry für mein gelaber)

[neolithos]

Das ist auch keine Assembler sonder eine eigene Sprache.

Sie basiert auf einem Stack. -> Stackmaschine.

push 1 --> legt 1 auf den Stack
push 4 --> legt 4 auf den Stack
and --> nimmt zwei Werte vom Stack, Addiert sie und legt das Ergebnis auf den Stack.

[ripper8472]

Hi,

ich war noch etwas verwirrt, weil ich bei den Tokens keine Klammern um die 1 und das Sinus gesehen hab. So ein Stacksytem ist echt nicht schlecht!

An solche Bäume lassen sich auch symbolische Umformungen ansetzen: ein Computer Algebra System!!

- ripper

(sorry für meine verwirrten posts)

[dizzy]

Zitat:

Zitat von neolithos

Grund: Wenn du die Formel zu einer schnell durchrechenbaren Sprache umcompilierst und opimierst, vermute ich, dass das Teil schneller wird.

Die Sprache meines Parsers heisst "Baum" :)

Zitat:

Zitat von neolithos

Bei Meinem Formel-Parser (der langsamer ist, durch Typenkonvertierungen und OOP) gehe ich wie folgt vor.

Ist meiner nicht OOP? Und hast du dir mal die ganzen Typecasts angesehen die ich da zwischen drin sitzen hab? :gruebel:

Zitat:

Zitat von neolithos

(1 + sin(A))^3 * (1+1)

Erster Schritt:

zerlegen in Token (Teile):

"1" "+" "sin" "(" "A" ")" "^" "3" "*" "(" "1" "+" "1" ")"
Dies erledigt eine while Schleife gekoppelt mit einer Matrix.

Baue aus den Tokens einen Parsebaum:

Dazu wird ein vor definierter Syntax-Graph durchlaufen.
-> Wieder nur eine while-Schleife

Das mache ich z.B. in nur einer Rekursion (procedure TTF(...)). Die dort enthaltene irre große "if..then..else"-Verzweigung legt in ihrer Struktur und Reihenfolge den "virtuellen" Sytaxgraphen fest, und das Ende dieser einen Rekursion die sich direkt den zu parsenden String vornimmt ist der (fast) fertige Baum.

Zitat:

Zitat von neolithos

Optimiere den Code:
in dem Fall wird 1+1 zusammengefasst.

Deswegen oben das "fast" in Klammern: Das mache ich in 2 rekursiven Schritten. Erst wird von den Blättern anfangend gekennzeichnet welche Knoten überhaupt "zusammenfassungswürdig" sind, also nicht Variablen oder von solchen abhängig sind. Im 2. Durchlauf findet die eigentliche Optimierung statt, die alles was möglich ist zusammen fasst.
(Diese Funktion ist in dem hier eingestellten glaub ich noch nicht vorhanden. Bei mir aber sehr wohl :))

Zitat:

Zitat von neolithos

Erzeuge Code:

Code:

push 1
push a
sin
and
push 3
power
push 2
mul

Und die Ausführung dieses Code's könnte man extrem Optimieren.
Array für Stack.
Sprung-Tabelle für Proceduren.

Und genau das spare ich mir. Dafür müsste man den Baum ein mal rekursiv durchlaufen um den Stack zu bilden, und dann muss man noch mal ran und den Stack lösen. Ich löse direkt den Baum, so dass diese rekursive Funktion als Rückgabewert das fertige Ergebnis liefert.

Ich hatte mal testweise 2 verschiedene Stackprinzipe eingebaut: Ein mal mit nur einem Stack, und mal mit getrennten Operanden- Werte- und Ergebnisstack.
Beide Versuche führten zu einer erheblichen Verlangsamung. (Man muss hierbei beachten, dass die Stärke meines Parsers ist, ein und die selbe, ein einziges Mal geparste Formel, immer und immer wieder zu lösen, mit veränderten Variablen. Also zum Plotten von Funktionen gut geeignet, oder halt für Fraktalrechnungen ;))
Bei der Variante mit einem Stack war das Problem, dass ich für jedes Mal Lösen den gesamten Stack "echt" kopieren musste. Und das hat einfach viel zu lange gedauert.
Bei der Variante mit 3 Stacks fiel der Kopieraufwand weg, aber der Overhead durch die Stackverwaltung in Form von Unterscheidung von Unären und Binären Operatoren, und der Indexverwaltung an sich, war wohl größer als der Overhead einer Rekursion. Zumindest hatten das meine Messungen ergeben.
Von daher bin ich beim Baum geblieben.

Was auch noch mit reinspielt ist, dass ich gerne die 3 Zahlentypen strukturell möglichst gleich abhandeln wollte. Und die Rechnerei mit komplexen Zahlen/Quaternionen gestaltet sich ja noch etwas anders als mit double, da man ja nicht die normalen Operatoren verwenden kann.
Weiteres Schmankerl ist in dieser Hinsicht auch das Variablenhandling. Es gibt 8 Variablen, denen es völlig egal ist ob sie nun ein double-Wert sind, ne komplexe Zahl, oder was auch immer. Daher bleibt die "usability" für den "Endbenutzer" (also Programmierer...) gut. Um mit dem Teil etwas mit double-Werten zu rechnen reicht folgendes:

Delphi-Quellcode:

var p: TCQParser;
    ergebnis: double;
.
.
p := TCQParser.Create;
p.Parse('(1 + sin(A))^3 * (1+1)');
p.SetVariable(A, pi);
p.Solve(ergebnis);

Naja, und ich bin (noch *g*) der Meinung dass ich meine beiden obersten Ziele (Speeeed und einfache Bedienbarkeit) einigermaßen gut erreicht habe.
Wenn du es aber hinbekommen solltest das Dingen noch schneller zu machen, dann bin ich der erste dem die Kinnlade runterfällt *provozier* :mrgreen:.

Ich werde die Tage (in 1-2 Wochen) die neue Version posten. Ich will ein Parser-Battle :twisted:


guts Nächtle,
dizzy

[neolithos]

Erstens:

Die Klammern hatte ich vergessen!

Zweitens:

Meinen Parser habe ich mit C# geschrieben und dort verwende ich verdammt viel in/outboxing. Dies scheint zu lasten der Performance gehen.

Drittens:

Jetzt hast du mich doch neugirig gemacht! Ich will mal wissen wie schnell in einem Win32-Programm ist. Wenn ich mal Zeit habe schreib ich das Teil um. :mrgreen:

Viertens:

Meinem Parser werde ich aber nur Integer und Double beibringen.

[dizzy]

Zitat:

Zitat von neolithos

Meinen Parser habe ich mit C# geschrieben und dort verwende ich verdammt viel in/outboxing. Dies scheint zu lasten der Performance gehen.

Okay, da resignier ich... Ich hab weder Plan von C, noch von .NET
Das entbehrt latürnich nahezu jeder Vergleichbarkeit.

Zitat:

Zitat von neolithos

Jetzt hast du mich doch neugirig gemacht! Ich will mal wissen wie schnell in einem Win32-Programm ist. Wenn ich mal Zeit habe schreib ich das Teil um. :mrgreen:

Also meiner ist bei double rund 0.5 bis 0.65 mal so schnell wie eine Formel in Delphi direkt geschrieben. Mangels Vergleichsmöglichkeiten halte ich das einfach mal für ein recht passables Ergebnis :)
Leider bleibt mir natürlich die Optimierung durch .NET verwehrt :?

Zitat:

Zitat von neolithos

Meinem Parser werde ich aber nur Integer und Double beibringen.

Feigling :mrgreen:

[Dani]

• Delphi 6 Personal
• Compiliert wunderbar und die Ergebnisse stimmen
• AMD Athlon XP 1800+ 1533,333 Mhz

1195,79
1992,97
4718,33
8877,55

:hi:

[neolithos]

Ich habe heute für mal schnell eine Stackmaschine zum Testen geschrieben.

Das Ergebnis sieht wie folgt aus.

Deine Parser brauch ca zwischen 3000 bis 3400 ms.
Meine Stackmaschine brauch ca zwischen 2800 bis 3100 ms.

Dieses Ergebnis kann man als gleichschnell bewerten. :gruebel:
Übrigens: Musste ich alle Tricks in C Anwenden, um native Stack-Operationen zu vermeiden. Sonst würde meine Maschine ein wenig über deinen Werten liegen. Aber das waren auch nicht viele ms. (glaube zw. 3900 und 4200 ms).

Als Anhang gibt es das Saumäßig in der Schnelle getippte C-Programm.

[NicoDE]

Zitat:

Zitat von dizzy

• welche Dephi-Version hast du?
• läufts/compilierts damit?
• sind die Ergebnisse im Testprog korrekt?
• CPU-Typ + Realtakt
• die Ergebnisse der Geschwindigkeitsmessung des Testprogs
• ist die Implementierung hübsch und sauber? (keine Leaks, styleguidekonform, verwendete Techniken...)
• hälst du den Parser für sinnvoll/einsetzbar?
• Verbesserungs- und/oder Verschönerungs- und/oder Verschnellerungsvorschläge?

• Delphi 6 Personal Edition, Update Pack 2, RTL Update 3
• compiliert und läuft damit
• Ergebnisse sind korrekt
• Mobile AMD Athlon 64 Processor 2800+ (x-1800 MHz)

Windows XP x86

848,759
1421,61
3571,95
7007,47

Windows XP x64 (Debug)

-7717,32
-13012,8
-31220
-61769,2

Gruss Nico

[neolithos]

So jetzt wie versprochen (in der PN) die Pascal'sche Variante.

Übrigens sind es zwei Versionen in einer Datei:

Die erste Ausgeklammerte lag bei ca 4000 ms. Also schneller als die gleichwerdige C-Variante. Ein hoch auf den Borland-Compiler-Optimierer.

Die jetztige Variante, die CALL's vermeidet, liegt auch im Limit.
zw. 3000 und 3200 ms.

Also ein Tick langsamer als die C-Makro-Variante. Sind aber auch mehr Call's trinne.

[dizzy]

:shock:

Formel: (1 + sin(pi/2))^3 * 2
Durchläufe: 5.000.000
Messmethode: GetTickCount

Mein Parser als DLL-Version: 1450ms
Als eingebundene Unit: 1530ms :?: DAS wundert mich schon etwas...
Deine Stackmaschine: 1312ms

:cry:
...ich spiele mit Umbaugedanken... *gnarf* ;)

\\edit: Ich hab nen kleinen Fehler gemacht! Mein Parser hat das pi/2 immer wieder neu ausgerechnet - scheinbar klappt die Vorausberechnung von Konstanten noch nicht so ganz :?
Wenn ich mit einer Variablen=pi/2 rechne siehts so aus:

DLL-Version: exakt gleich schnell wie die Stackmaschine: 1312ms
Unit: nur 1455ms


Ich muss aber ganz offensichtlich noch mal an meinen Optimierer ran! Eigentlich ist ja die ganze Formel konstant, und von daher sollte die gesamte Formel zu einem Baum mit nur einem Knoten=16 zusammenschrumpfen. Das tut er ganz offensichtlich nicht! Mist :)

[neolithos]

Bei meinem Optimierer tut er das auch!

Da entsteht nur noch "push 16"!

Ich könnte meine Kenntnisse eventuell mit einfließen lassen!
Hinsichtlich Scanner -> Parser -> Compiler -> Virtuelle Maschine.


Dann könntest du auch den wunsch von beliebigen Variablen erfüllen!

[dizzy]

Zitat:

Zitat von neolithos

Bei meinem Optimierer tut er das auch!

Bei mir jetzt auch :)
Grad noch gefummelt... war, wie eigentlich immer, nur ein ganz kleiner blöder Patzer.

Zitat:

Zitat von neolithos

Ich könnte meine Kenntnisse eventuell mit einfließen lassen!
Hinsichtlich Scanner -> Parser -> Compiler -> Virtuelle Maschine.

Das würde mich glaube ich sehr glücklich machen. Ich habe von Compilerbau im theroetischen Sinne nicht wirklich viel Plan, das kommt noch an der FH. Müsste sogar kommendes Semester was werden.
Das Ding hier hab ich mir über längere Zeit zusammen gebastelt, und ausgebaut, und hab das Thema dabei etwas mit-gelernt. Aber so richtig in die Tiefe kommt man ja doch nicht.

Zitat:

Zitat von neolithos

Dann könntest du auch den wunsch von beliebigen Variablen erfüllen!

Auch mit meinem hübschen Bäumchen? :) Würd's gerne so lassen, da sich ja nun herausgestellt hat, dass beide Verfahren ja nun wirklich gleich schnell sind... Schon erschreckend gleich schnell *g*

Hatte mir da schon was mit arrays überlegt, in die der Benutzer selber Variablennamen eindefinieren könnte, in der Art:

Delphi-Quellcode:

DefineVar('var01', pi);

Da ließe sich auf diesem Wege bestimmt was machen. Bin da aber (noch) für alles offen (ist ja noch keine Zeile zu geschrieben ;)).

Die neue Version mit funktionierendem Pre-Solving schiebe ich in den anderen Thread mit der Final-Version.


Vielen Dank für dein Interesse und Unterstüzung!!
gruss,
dizzy

[neolithos]

Vielleicht hast du es gesehen!

Ich mache mir derzeit eine Rübe wie man die Formel direkt als IA-32 Befehl in den Ram ablegen könnte, und ausführen.

Leider sind meine ersten Test's noch nicht ganz geglückt.

Das wäre aber die schnellste Variante. Und wäre auch eine schöne Übung, welche mich näher an mein Ziel heran bringt.

Einen eigenen Compilier! :spin:

[mrsiemens]

Hallo,

ich habe mal den Parser um die Funktion erweitert, beliebig viele Konstanten in der Formel zu benutzen...
Einfache Zuweisung mittels SetVariable(String, const Value)


Vielleicht brauchts ja jemand :)

[CalganX]

Hi,
ich würde dich bitten diese langen SourceCodes als PAS-Datei anzuhängen.

Danke,
Chris

[dizzy]

:shock: Das ist lieb von dir, aber der Parser hier ist schon etwas überholt :? Mittlerweile bin ich bei Version 1.2, und es hat sich einiges geändert... Unter anderem das Variablensystem, die Konstanten, Precalculation ist drin, etc.
Er ist allerdings noch nicht online, da ich immer noch ein zwei Kleinigkeiten dran schrauben wollte - aber z.Zt. (wie so oft bei halb-fetigen Codes) wieder bei was anderem bin ;).

Gut gemeint, aber nicht mehr aktuell... :oops: hätte ich vllt. hier schreiben sollen dass das nicht mehr so wirklich aktueller Stand ist. Sorry!

Aber schön zu hören, dass sich Leute (ein Leut :mrgreen:) für das Teil interessieren *froi*.

Herzlichen Gruss,
Fabian

[mrsiemens]

Zitat:

Zitat von Chakotay1308

Hi,
ich würde dich bitten diese langen SourceCodes als PAS-Datei anzuhängen.

Danke,
Chris

Die Funktion hatte ich übersehen, habs geändert...

@dizzy
Wenn du noch dran arbeitest, kannst du ja alle Funktionen dynamisch einbinden, d.h. das Ganze so implementieren, dass noch zur Laufzeit Funktionen/ Operatoren eingebunden werden.

Wäre jedenfalls so ne Idee die mir so spontan noch einfällt :)

[dizzy]

Wer volle "Customizability" haben möchte, der sollte sich auch mal den Parser von Dax anschauen - das Teil bringt seine eigene Scriptsprache mit :).

Mir ging es beim CQParser um 2 Dinge:
1. Komplexe Zahlen + Quaternionen
2. Speed Speed und nochmal Speed :D

Ich hatte ihn mal für ein eigenes Projekt entwickelt, in dem es um das volumetrische Rendern von 3D-Fraktalen ging, und dabei wird der Parser irrsinnig oft um eine Lösung gebeten... Naja, und wie so oft sthen sich hier Anpassbarkeit und Performance gegenüber. (In XML kann man jede Form von Daten strukturieren - aber alles basiert auf Strings -> mächtig aber langsamer. Binäre Formate sind fix verarbeitet, aber auf ein spezielles Problem zugeschnitten. Ich wandere da eher auf der binären Seite ;))

Wobei der CQParser sicherlich relativ einfach "fully scaleable" machbar ist. Alles zu seiner Zeit :drunken:

Danke dir!

Gruss,
Fabian

[mrsiemens]

Hallo,

ich habe zur Zeit in meinem Projekt den CqParser benutzt, allerdings um einige Funktionen erweitert.

Vom Speed her gefällt er mir recht gut :)

Ich muss nun allerdings den Parser um eine recht grosse Anzahl an Funktionen erweitern.
U.a. um Funktionen mit mehreren Parametern (max 3 Parameter).

Ich hatte mal irgendwann einen anderen Parser am Wickel, bei dem man Funktionen einfach beim Parser zur Laufzeit "registrieren" konnte.
Dummweise habe ich den Namen vergessen :( und eine Suche bei Google/ DSP/... hat noch nicht viel ergeben.

Habt ihr eine Empfehlung für einen Parser mit einfacher Integration neuer Funktionen und hoher Performance ist?

Danke :)

mr.s

[mr47]

dELPHI 2005 architect
problemlos
1112.48
1766.71
4282,06
7678,19

Amd Athlon 2GHZ

Cool: Da sieht man endlich mal wieder wie wenig 2 GHZ doch sind :mrgreen:

[dizzy]

Zitat:

Zitat von mrsiemens

Habt ihr eine Empfehlung für einen Parser mit einfacher Integration neuer Funktionen und hoher Performance ist?

Da wäre doch der TMathParser von Dax genau dein Ding! Der bringt mal eben eine kleine Scriptsprache mit sich. Allerdings weiss ich grad nicht wie da der Entwicklungsstand ist.

Meinen um >2-parametrige Funktionen zu erweitern, das wäre doch sehr umfangreich - das seh ich ein :?

edit: Wenn du allerdings die komplexen Zahlen bzw. Quaternionen brauchst, dann weiss ich nicht in wie weit Dax's Parser mit macht. U.U. lässt sich das selbst via Script implementieren - wie performant das dann ist weiss ich nicht. (;))

@mr47: Dangeschön! Gut zu hören dass er auch unter D2005 tut - aber wahrscheinlich mit 1001 "unsicherer Code"-Hinweisen, gell!? :D

[mirage228]

Zitat:

Zitat von dizzy

@mr47: Dangeschön! Gut zu hören dass er auch unter D2005 tut - aber wahrscheinlich mit 1001 "unsicherer Code"-Hinweisen, gell!? :D

Naja, wahrscheinlich nicht ;)
In D2005 für Win32 werkelt auch nur ein veränderter D7 Compiler und in den Warnungen sind die .NET Warnungen standardmäßig abgeschaltet ;)

mfG
mirage228

[mrsiemens]

Wo finde ich denn den Parser von Dax?
Die Suche bei google nach TMathParser ergbibt recht viele Parser...
Und im Forum hier finde ich dazu nichts.

Die Frage ist dann aber wie schnell der Parser ist...

Ich habe jetzt als Grundlage den "TParser 10.1 for Borland Delphi" genommen.

Die Variablenzuweisung musste ich ändern und komplexe Zahlen muss ich noch integrieren.

Aber meine ersten Tests haben gezeigt dass der Parser sogar noch schneller als der CQParser ist, wenn viele Variablen in der Formel vorhanden sind.

Bsp:
10+(x1^2-10*cos(2*pi*x1))+(x2^2-10*cos(2*pi*x2))
5.000.000 Durchläufe
CQ => 4,6s
P10 => 2,7s
AMD 2400+

mfg

mr.s

[mr47]

Irgend ne Meldung kam am Anfang, die ich aber nicht weiter beachtet habe :mrgreen:

[dizzy]

Zitat:

Zitat von mrsiemens

Wo finde ich denn den Parser von Dax?

Hmmm, auf die Schnelle hätt ich jetzt keinen Link zur Hand. Schreib Ihm/Ihr/Es (:mrgreen:) am besten eine PN.

Zitat:

Zitat von mrsiemens

Die Variablenzuweisung musste ich ändern und komplexe Zahlen muss ich noch integrieren.

Ui, also doch. Dann weiss ich nicht wie performant der von Dax wird, da komplexe Zahlen auch nicht "nativ" dabei sind. Aber einen Versuch ist das Teil mindestens wert!

Zitat:

Zitat von mrsiemens

Aber meine ersten Tests haben gezeigt dass der Parser sogar noch schneller als der CQParser ist, wenn viele Variablen in der Formel vorhanden sind.

:shock: Darf doch nicht sein! 8)
Kann gut sein, dass die vielen Variablen den Pre-Solver gut ins Schwitzen bringen. Vielleicht hat der P10 sogar einen Formel-Optimierer (hat CQ nicht...).
Das meiste Optimierungspotential beim CQ ist denke ich in der "QMath.pas", in dem man nämlich diverse Fuktionen via Assembler weiter optimiert (die einfachen hab ich schon - zu mehr reichte es nicht ;)), oder halt beim Presolven/Formeloptimieren. Das wäre aber auch einiges an Arbeit - aber interessant!


@mirage228: Ja NOCH besser :D