[Dipl Phys Ernst Winter]

Interpreter für anwenderdefinierte Funktionen
Die Unit Formel exportiert:

markieren

Delphi-Quellcode:

type
  TPar = array[0..9] of extended;
function FWert(FStr: string; const P: TPar): extended; // Formelinterpreter

Verwendung:
Der Anwender übergibt dem Programm eine Formel als Text mit einer Reihe von Parametern vom Typ extended. Mit dem Interpreter berechnet das Programm Werte dieser Funktion.

Die Formel ist wie ein arithmetischer Ausdruck in Objekt-Pascal zu schreiben. In der Formel sind als Operanden zugelassen:
- Die Variable x
- Die Parameter a, b, c, d, w
- u für cos(w), v für sin(w)
- x^n als Potenz von x mit ganzzahligen Exponenten n=0..9.
- Zahlenkonstanten (Dezimalzahlen, Gleitkommazahlen )
- Die Konstante PI = 3.14159265358979
- Geklammerte Ausdrücke: '( Ausdruck )'
- Standardfunktionen mit einem Ausdruck w als Argument
-- ABSw)
-- INT(w)
-- FRAC(w)
-- SQR(w)
-- SQRT(w)
-- EXP(w)
-- LN(w)
-- SIN(w)
-- COS(w)
-- ARCTAN(w)

Zwischen zwei Operanden muß ein Operator stehen:
'*', '/' Multiplikation, Division mit Vorrang vor Addition und Subtraktion ausgeführt.
'+', '-' Addition, Subtraktion

Ein '+' oder '-' kann als monadischer Operator vor einem Ausdruck stehen.

Zwischen Operanden und Operatoren können Leerzeichen stehen.
Kommentare nach einem ';'

Fehlermeldungen:
'Doppelter Operator',
'Fehlender Operator',
'Fehlende Klammer',
'Überzählige Klammer',
'Fehler in Konstante',
'Fehlender Exponent',
'Illegale Funktionsbezeichnung',
'Illegale Variablenbezeichnung',
'Fehlendes Funktionsargument',
'Exponent von x^n keine Ziffer',
'Fehlender Operand',
'Syntaxfehler'.
Laufzeitfehler
'Division durch 0'
'SQRT mit negativem Argument'
'Ln mit negativem Argument'

Der Interpreter ist ein Musterbeispiel für die Leistungsfähigkeit rekursiver Programmierung. Er verwendet Rekursive Aufrufe zur Berechnung geklammerter Ausdrücke und der in Klammern stehenden Argumente von Funktionen.

Programmierbarer Tabellenrechner
Ich zeige die Anwendung des Interpreters am Beispiel eines programmierbaren Tabellenrechners.

Der programmierbare Tabellenrechner gibt nach Vereinbarung der Abszisseneinteilung, Formel und Parameter eine Tabelle mit Funktionswerten der analytischen Funktionen zu den äquidistanten Abszissen aus.


[edit=Matze]Tippefehler im Titel korrigiert ("Tabellenrwchner"), damit das Thema über die Suche leichter gefunden wird. MfG, Matze[/edit]

Hi,

das sieht sehr nach Mathe-Parser aus. Es gibt hier im Forum den HAM-Parser. ich glaube aber, der liegt auf Eis. Auch ein sehr schönens Tool um solche Aufgaben zu implementieren. Vorallem ist er durch den Programmierer recht "einfach" für neue Funktionen erweiterbar.

Gruß oki

Es gibt nicht nur den HAM. Es gibt noch zig andere Matheparser hier und im Netz. Und diese Parser sind i.A. vollständig. Also man muss sich nicht in der Variablenbezeichnung noch in der Anzahl o.ä. einschränken. Man kann da eigene Funktionsaufrufe integrieren.

Das ist ein Mathe-Parser.

Dabei kam es mir auf die Beschränkung der Parameteranzahl und Bezeichner an, um ihn möglichst einfach bei optimaler Laufzeit in die Anwendung einzubinden.

Ich habe noch keine Anwendung geschrieben, die sinnvoll nach weiteren Variablen bzw. andern Bezeichnern gefragt hätte.

Bei Anwendungen, in denen der normale Benutzer selbst Formeln erstellen können soll, sind sinnvolle Bezeichner sicherlich hilfreich. Und HAM hat ein Assembler-Plugin, es würde mich nicht wundern, wenn das deinen Parser schlagen würde

"Dax" schreibt:

Zitat:

Bei Anwendungen, in denen der normale Benutzer selbst Formeln erstellen können soll, sind sinnvolle Bezeichner sicherlich hilfreich.

Ich fühle mich durchaus noch normal, habe aber Mathematik steets nur mit Symbolen betrieben!

Zitat:

Und HAM hat ein Assembler-Plugin, es würde mich nicht wundern, wenn das deinen Parser schlagen würde;

Schlagen in welcher hinsicht? Ganz gewiss nicht in der Geschwingigkeit! Auf die kommts aber an!

40 Jahre Beschäftigung mit Interpretern (von Focal über HP-Language zu verschiedenen Basic-Dialekten) haben mich gelehrt, dass Laufzeitperformance nur durch Einschränkung der syntaktischen Möglichkeiten zu erreichen ist. Daher habe ich absolut keine Angst, dass irgend ein Parser den Formeleditor hinsichtlich der Geschwindigkeit schlägt.
Jeder Parser der sinnvolle Bezeichner für Variable verwendet, muß deren Adressen aus Listen suchen, während Variablen, die nur mit einem fest vergebenen Buchstaben bezeichnet werden, direkt adressierbar sind.

Zitat von Dipl Phys Ernst Winter:

Ich fühle mich durchaus noch normal, habe aber Mathematik steets nur mit Symbolen betrieben!

Ich habe niemals behauptet, dass du nicht normal wärst Aber für jemanden, der keine genauen Kenntnisse deiner Programme hat, sind lange, sinnvolle Bezeichner sehr hilfreich.

Zitat von Dipl Phys Ernst Winter:

Schlagen in welcher hinsicht? Ganz gewiss nicht in der Geschwingigkeit! Auf die kommts aber an!

Los, teste es, wenn du dir so sicher bist Wenn es auf anderen Mitgliederrechnern reproduzierbar ist (ich habe kein Windows mehr, es zu testen), werde ich deine Behauptung akzeptieren. Ansonsten wirst du meine akzeptieren müssen.

Zitat von Dipl Phys Ernst Winter:

40 Jahre Beschäftigung mit Interpretern [...] haben mich gelehrt, dass Laufzeitperformance nur durch Einschränkung der syntaktischen Möglichkeiten zu erreichen ist. Daher habe ich absolut keine Angst, dass irgend ein Parser den Formeleditor hinsichtlich der Geschwindigkeit schlägt.

40 Jahre Erfahrung und noch so viel zu lernen. Respekt Syntaktische Möglichkeiten sind eine Sache, wie man sie nutzt, eine andere. Gut gebaute Interpreter/Compiler parsen die Eingabe nicht bei jedem Durchlauf, sondern einmal am Anfang und erstellen dann auf der Basis Bytecode, der sich als Eingabe für einen tiefer liegenden Interpreter verwenden lässt. Dabei ist _jede_ Variable und _jede_ Funktion nichts weiter als ein Pointer, egal, wie sie vorher hieß, und die Aufrufkosten sind alle exakt gleich (wenn man die Funktionen als leer ansieht), die Zugriffskosten auf den Speicher sowieso. Man kann das Spiel natürlich noch weiter treiben und auf die Bytecode interpretierende Schicht verzichten, stattdessen bastelt man sich einfach direkt Maschinencode und gibt dem Programm, das danach fragt, einen Funktionszeiger. Im konkreten Fall ist natürlich nicht mit Gewissheit auszuschließen, dass dein Parser einen einzelnen Variablenzugriff schneller ausführt als HAM/Assembler, weil in HAM aus verschiedenen Gründen jede Variable eine eigene Klasseninstanz hat und der Zugriff damit eine Pointerindirektion bedingt; allerdings sollte der Nachteil dadurch aufgewogen werden, dass die Indirektion in dein Array letztendlich das selbe kostet - und bei dir ist es eben "nur" Interpretercode, der die Indirektionen ausführt, keine als ganzes ohne Interpreter ausführbare Funktion

Zitat von Dipl Phys Ernst Winter:

Jeder Parser der sinnvolle Bezeichner für Variable verwendet, muß deren Adressen aus Listen suchen, während Variablen, die nur mit einem fest vergebenen Buchstaben bezeichnet werden, direkt adressierbar sind.

Das ist natürlich wahr. Aber wie bereits gesagt sind Parsen und Ausführen getrennte Schritte, und beim parsen geht eine Menge Information verloren, beziehungsweise, die vorhandene Eingabeinformationsmenge wird auf das nötige reduziert. Wenn im (indirekt) ausführbaren Code noch Symbolinformationen stecken, ist das entweder ein Debugfeature und damit ohnehin nicht auf Geschwindigkeit getrimmt oder ein Designfehler.

Guten Morgen Herr Winter,

vielen Dank, dass Sie uns einen Beitrag für die DP reingestellt haben. Ihr Programm/die Unit braucht nichts zu schlagen, dies ist auch nicht der Sinn dieses Forums. Jeder Beitrag ist hier willkommen.

Ich habe mir den Formelparser kurz angesehen, der Sourcecode ist für mich lesbar und zudem kommentiert.

Die Beiträge von Dax sind, sorry, respektlos, unverschämt und dienen dazu andere User davon abzuhalten, hier Beitäge einzustellen und damit uns ihr Wissen vorenthalten. Ich bin in diesem Forum, weil solche Beiträge wie von Dax hier selten vorkommen, und das Lesen von Beiträgen ohne sinnleerer Diskussionen Spass macht und immer wieder lehrreich sind. Und um schon jetzt auf Antworten vorzubeugen: Jeder darft seine Meinung kundtun, aber bitte mit ein Minimum an Respekt und Umgangsformen. Und da ist ein zwischengeschobens "Augenzwinkern" wie von "DAX" zwischen den Zeilen schon recht dreist.

An DAX: Um in Deinem Ton mal zu reflektieren:
Dies ist nun Deine Aufgabe "DAX" heute gefälligst Deine eigenen Zeilen unter den genannten Gesichtpunkten zu betrachten und darüber einmal nachzudenken. Und zwar solange, bis Du verstanden hast, was Du eigentlich hier geschrieben hast. Das wirst "DU" akzeptieren müssen!

Ich hoffe, dass der DP solche Beiträge weiterhin erspart bleiben.

Zum Glück leben wie in keiner Ein-Programm-pro-Problem-Welt, so dass jeder das preverierte Programm verwenden kann. Imho ist ein Programm nicht schlecht, nur weil es möglicherweise ein anderes gibt, welches etwas kann, was dieses nicht kann.

Huch? Was ist denn hier los?

Ich halte Herrn Winter für durchaus in der Lage, den 'Fedehandschuh' aufzuheben und entsprechende Vergleiche anzustreben, wenn ihm danach ist. Denn ab einem gewissen Alter sieht man Wettbewerben dieser Art durchaus gelassen entgegen (es gibt Wichtigeres). Allerdings ist es auch so, das man bei einer 40 jährigen Erfahrung, die gegen einen eventuellen Performancevorteil des HAM-Parsers in die Waagschale geworden wird, mit einer gewissen Diskussionsfreudigkeit rechnen muss.

Wichtig ist der Ton und da unterstelle ich Dax als Ex-Moderator sowohl ein gewisses Fingerspitzengefühl als auch ein bestimmtes Niveau. Soweit ich das beurteilen kann, handelt es sich hier um ein Gefecht der Argumente, das bisher sachlich geführt wird.

Beide Parteien dürften in der Lage sein, die Diskussion entsprechend zu führen.