AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Projekte Mathem. Parser -- bitte testen
Thema durchsuchen
Ansicht
Themen-Optionen

Mathem. Parser -- bitte testen

Ein Thema von dizzy · begonnen am 23. Mai 2004 · letzter Beitrag vom 2. Okt 2013
Antwort Antwort
Seite 8 von 11   « Erste     678 910     Letzte »    
Benutzerbild von dizzy
dizzy
Registriert seit: 26. Nov 2003
Hi DPler!

Ich habe noch so einiges an meinem Parser (hier schon mal vorgestellt) verbessert/geändert.

Habe jetzt auch ein Testprogramm geschrieben. Es führt einige Rechnungen durch, und gibt eine kleine Statistik dazu aus. Folgende Infos von euch würden mich brennend interesieren:
  • 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...)
    (in CQParser.pas bzw. der QMath(2).pas - nicht das Testprog. Das ist fix zusammengeschustert )
  • hälst du den Parser für sinnvoll/einsetzbar?
  • Verbesserungs- und/oder Verschönerungs- und/oder Verschnellerungsvorschläge?
Wer Lust hat, der kann ihn sehr gerne komplett auseinandernehmen und kaputttesten. Ich will alles wissen *g*.

Ich erwarte sicherlich nicht von jedem alles beantwortet. Mir geht es hauptsächlich darum zu sehen mit welchen D-Versionen und CPUs der Parser korrekt arbeitet, und wie schnell er es tut (im Vergleich zu einer hardgecodeten Rechnung).

Tipp für die D8-User: Es gibt die Units "QMath" und "QMath2". Ändert im QT des Parsers und des Testprogramms in der uses-Klausel "QMath" auf "QMath2", weil "QMath" verwendet z.T. Assembler. Ich hoffe dass D8 die ganzen Casts zulässt . Wenn nicht, dann schreit!

Ihr würdet mir einen Riesen-Gefallen tun!

Danke euch schonmal im Voraus,
MfG - dizzy


\\div. Edits: Ein paar Umformulierungen - nix wildes...
Angehängte Dateien
Dateityp: zip cqparser.zip (17,9 KB, 584x aufgerufen)
INSERT INTO HandVonFreundin SELECT * FROM Himmel
 
Benutzerbild von dizzy
dizzy

 
Delphi 7 Enterprise
 
#71
  Alt 9. Nov 2004, 01:02
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... 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 ) für das Teil interessieren *froi*.

Herzlichen Gruss,
Fabian
Fabian K.
  Mit Zitat antworten Zitat
mrsiemens
 
#72
  Alt 9. Nov 2004, 01:48
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
  Mit Zitat antworten Zitat
Benutzerbild von dizzy
dizzy

 
Delphi 7 Enterprise
 
#73
  Alt 9. Nov 2004, 04:25
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

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

Danke dir!

Gruss,
Fabian
Fabian K.
  Mit Zitat antworten Zitat
mrsiemens
 
#74
  Alt 9. Jan 2005, 21:04
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
  Mit Zitat antworten Zitat
Benutzerbild von mr47
mr47

 
Delphi 2005 Personal
 
#75
  Alt 9. Jan 2005, 21:12
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
  Mit Zitat antworten Zitat
Benutzerbild von dizzy
dizzy

 
Delphi 7 Enterprise
 
#76
  Alt 10. Jan 2005, 04:07
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!?
Fabian K.
  Mit Zitat antworten Zitat
Benutzerbild von mirage228
mirage228

 
Delphi 2010 Professional
 
#77
  Alt 10. Jan 2005, 06:46
Zitat von dizzy:
@mr47: Dangeschön! Gut zu hören dass er auch unter D2005 tut - aber wahrscheinlich mit 1001 "unsicherer Code"-Hinweisen, gell!?
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
David F.
  Mit Zitat antworten Zitat
mrsiemens
 
#78
  Alt 10. Jan 2005, 10:12
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
  Mit Zitat antworten Zitat
Benutzerbild von mr47
mr47

 
Delphi 2005 Personal
 
#79
  Alt 10. Jan 2005, 13:07
Irgend ne Meldung kam am Anfang, die ich aber nicht weiter beachtet habe
  Mit Zitat antworten Zitat
Benutzerbild von dizzy
dizzy

 
Delphi 7 Enterprise
 
#80
  Alt 10. Jan 2005, 13:17
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 () am besten eine PN.

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 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.
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
Fabian K.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 8 von 11   « Erste     678 910     Letzte »    


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:27 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz