Einzelnen Beitrag anzeigen

Benutzerbild von sirius
sirius

Registriert seit: 3. Jan 2007
Ort: Dresden
3.443 Beiträge
 
Delphi 7 Enterprise
 
#5

Re: Formelinterpreter, Programmierbarer Tabellenrwchner

  Alt 29. Apr 2009, 13:10
Geschwindigkeit ist ja nicht alles. Hauptsache ein Algorithmus ist nicht unnötig zu langsam. Das ist hier nicht der Fall. Natürlich kann dieser Parser nicht mit HAM (soweit ich es von der Beschreibung kenne, getestet habe ich es nicht) mithalten. Wie Dax schon sagte, HAM produziert nach dem einmaligen Parsen direkt Bytecode bzw (ich nenne ihn) Opcode. Da dauert zwar das Parsen ein wenig länger, aber wenn man die Formel mehrmals verwendet macht sich da ein enormer Geschwindigkeitsunterschied bemerkbar. Durch den Bytecode steht die Formel nach dem Parsen nun einmal so im Programm, als hätte man die Formel direkt in Delphi vorm Compilieren eingetragen. Da kann kein anders gearteter Parser mithalten.

Ich habe mal kurz ein Vergleichsprogramm geschrieben. Allerdings ohne HAM sondern mit meinem eigenen Parser, der auch Opcode erstellt und mit diesem Parser hier ohne OpCode. Ich nenne meinen mal kurzerhand OpCode-Parser und den anderen TTR-Parser. Den von Herrn Winter nenne ich Formel-Parser (weil die Unit so heißt).
Meiner soll allerdings nicht in die CodeLib sondern ist hier nur zum Vergleich.

Bedienung:
Links ist das Bedienfeld. Dort kann man oben die Formel eingeben .Ich habe mal nur die Abhängigkeit von x als Laufvariable eingebracht. Darunter kommt dann das Intervall von wo bis wo und in welchen Schritten die y Werte berechnet werden sollen.
Dann kommen drei Pushbutton, welche den jeweiligen Parser starten (OpCode=>Meiner ; Formel=>H. Winter; TTR->aus verlinktem Tutorial)
Darunter sind zwei Radiobuttons. Da kann man auswählen, ob die Funktion im gegebenen Intervall gezeichnet werden soll oder nur eine Zeitmessung der Funktionsberechnung im gegebenen Intervall mit n Wiederholungen erfolgen soll. Die Wiederholungen sind nur dafür da, um die Streuung zu verringern. Die Zeitangabe im gelben Feld wird immer für den gesamten Vorgang angegeben. Das Zeichnen ist eigentlich nur zur Kontrolle, ob der Parser auch richtig rechnet.

Hier sieht man, dass mein Parser ab 5 Werten besser wird als der hier vorgestellte. Also wenn man die gleiche Formel für 5 verschiedene x verwendet liegt der OpCode vorn.
Das ist auch das, was Dax erwähnte.
Ansonsten kann ja jeder mal selber nachsehen. Der TTR liegt immer deutlich hinten. Das ist allerdings noch eine Frage des Funktionenumfangs.
------------------------------------------------------------- Soweit dazu. ..

Deswegen ist der hier vorgestellte Code nicht unbedingt schlecht. "GoTo-s" sind allerdings doch etwas veraltet. Naja, und die Einschränkungen bezüglich Exponentialrechnung sind auch eher ungewöhnlich. Ich weis jetzt nicht, was noch so fehlt.
Miniaturansicht angehängter Grafiken
bildchen_204.jpg  
Angehängte Dateien
Dateityp: zip parser_342.zip (18,6 KB, 27x aufgerufen)
Dateityp: exe ptestparser_150.exe (611,0 KB, 38x aufgerufen)
Dieser Beitrag ist für Jugendliche unter 18 Jahren nicht geeignet.
  Mit Zitat antworten Zitat