Parser für mathematische Formeln

Parser für mathematische Formeln:

Nachdem ich in letzter Zeit in diversen Forumsbeiträgen Anfragen zu Parsern für mathematische Formeln gesehen habe, habe ich mich an meinen (vor ca. 10 Jahren) in C++ geschriebenen Parser erinnert und mir gedacht, den könnte ich doch mal nach C# umsetzen.

Mir geht es insbesondere darum, auch ein bißchen die Theorie verständlich zu machen. Da oftmals als Ansätze die Stringersetzung (egal ob per Hand oder per Regex) gewählt wurde, welche jedoch im Detail dann oftmals Probleme mit den Operatorprioritäten sowie Klammererkennung haben, möchte ich meinen generischen Parser vorstellen, welcher auch nur aus ca. 200 Zeilen besteht.

Ich weiß, daß man in C# bzw. generell mit allen .NET-Sprachen auch per CodeDOM sich den Ausdrucksinterpreter zunutze machen kann.

Mein Parser kann jedoch als Vorlage für unterschiedliche Bereiche benutzt werden, da er flexibel angepaßt werden kann.

1. Theorie

Nach der Einteilung von Chomsky ( http://de.wikipedia.org/wiki/Chomsky-Hierarchie) ist eine mathematische Formel eine kontextfreie Sprache (bzw. Grammatik). Und diese lassen sich formal mithilfe der (E)BNF-Notation ( http://de.wikipedia.org/wiki/EBNF) beschreiben.

Code: 1: 2: 3: 4: 5: 6: Expression = Term | Term ('+' | '-') Expression Term = Factor | Factor ('*' | '/') Term Factor = Terminal | Terminal '^' Factor Terminal = ['+' | '-'] (Number | Variable | Constant | Function | '(' Expression ')') Function = identifier '(' Expression ')'

"Expression" stellt hierbei der Einstiegspunkt für die mathematischen Formeln dar. Die einzelnen Operatorprioritäten sind mittels der verschiedenen Hierarchie-Ebenen abgebildet, d.h. das binäre Plus (+) sowie das Minus (-) bilden die schwächste Priorität, während die Potenz '^' die höchste bildet. Innerhalb einer Priorität werden hierbei die Operatoren von links nach rechts abgearbeitet.
Auf der untersten Ebene werden die Terminalsymbole sowie unären Operatoren Plus und Minus als auch die Klammerausdrücke behandelt. Durch den rekursiven Aufruf von 'Expression' auf unterster Ebene können somit alle Formeln beliebiger Komplexität erzeugt werden.

Nun können aus der EBNF-Definition relativ einfach die Parsermethoden erzeugt werden. Benötigt wird hierzu eine Hilfsfunktion 'GetChar', welche das jeweils nächste Zeichen 'parsed', wobei Leerzeichen (Whitespaces) überlesen werden.

C#-Code:

protected char GetChar() {     char c;     do     {         c = GetNextChar();     }     while(c != '\0' && Char.IsWhiteSpace(c));     return c; } protected char GetNextChar() {     return Functionator.MoveNext()? Functionator.Current : '\0'; } IEnumerator<char> Functionator;

Functionator ist dabei ein Enumerator auf die zu parsende Formel (extra als IEnumerator<char> definiert - statt string - um möglichst allgemeingültig zu sein).
Das jeweils nächste zu parsende Zeichen wird per Referenz (ref char c) an die einzelnen Parsermethoden übergeben, so daß nach dem Aufruf in der Variable 'c' das nächste zu parsende Zeichen drin steht.

Dann sieht eine Parsermethode z.B. so aus (Datentyp sei jetzt 'double'):

C#-Code:

double Expression(ref char c) {   double y = Term(ref c);   while(c == '+' || c == '-')   {     switch(c)     {       case '+': c = GetChar(); y += Term(ref c); break;       case '-': c = GetChar(); y -= Term(ref c); break;     }   }   return y; }

Analog würde man die anderen Parsermethoden definieren...

2. MathParser

Bei meinem Parser wollte ich jedoch auch die Operatoren frei definieren können. Somit brauchte ich eine Methode, welche allgemeingültig für alle Operatorprioritäten funktioniert.

Schematisch sieht die Funktionalität dann so aus:

Code: 1: 2: 3: Calculate(pri) = Calculate(pri+1) | Calculate(pri+1) Operator(pri) Calculate(pri) Calculate(MaxPri) = Terminal

Die Priorität 'pri' ist dann von 1..MaxPri definiert.

Die Methode 'Calculate' habe ich dann folgendermaßen umgesetzt (T ist der verwendete Datentyp, d.h. der generische Parameter der Klasse):

C#-Code:

T Calculate(ref char c, OpPriority op_pri) {     T y = Calc(ref c, op_pri);     Operator op;     while((op = GetOperator(c, OpType.Binary, op_pri)) != null)     {         T y2 = Calc(ref c, op_pri);         y = op.op(y, y2);  // Binäre Operation ausführen     }     return y; } T Calc(ref char c, OpPriority op_pri) {     T y;     if(op_pri < MaxOpPriority)         y = Calculate(ref c, (OpPriority)(op_pri + 1));     else         y = GetTerminal(ref c);     return y; }

Die Methode 'Calc' ist eine Hilfsmethode, da diese zweimal innerhalb von Calculate aufgerufen wird. Je nach Operatorpriorität wird entweder rekursiv die Methode 'Calculate' mit der nächsthöheren Priorität aufgerufen oder aber der Wert eines Terminalsymbol bestimmt.

Damit der Parser flexibel angepaßt werden kann, benötigt er diverse Strukturen (bzw. Klassen) für die einzelnen Terminalsymbole:

C#-Code:

using OpPriority = System.SByte; // Function protected delegate T Fct(T x); protected class Function {      public string sFct;      public Fct fct; }; // Operator protected delegate T Op(T x, T y); protected enum OpType {     Unary, Binary } protected class Operator {     public string sOp;     public Op op;     public OpType type;     public OpPriority priority; }; // Constant protected class Constant {     public string sConst;     public T value; };

Zu jeder dieser Klassen gibt es eine Membervariable, welche eine Aufzählung beinhaltet:

C#-Code:

protected IEnumerable<Function> Functions; protected IEnumerable<Operator> Operators; protected IEnumerable<Constant> Constants;

Die komplexeste Methode stellt 'GetTerminal' dar, welche aufgrund des aktuellen Zeichens entscheidet, welches Terminalsymbol ausgewertet wird:
- optional unärer Operator ('+' oder '-')
- öffnende Klammer '(': rekursiver Aufruf von Expression
- Ziffer oder Punkt: Zahl auswerten (GetNumber)
- Buchstabe: Variable, Konstante oder Funktion
- bei Funktion noch Klammern sowie Parameter (Expression) auswerten


Da die Parser-Klasse selber generisch bzgl. des verwendeten Datentyps ist, lassen sich mittels Ableitung von dieser Klasse diverse Parser entwickeln.

C#-Code:

public class FctParser<T> {     public T Parse(IEnumerable<char> function, T x); }; public class FormulaParser : FctParser<double> {     public FormulaParser()     {         base.Functions = Functions;         base.Operators = Operators;         base.Constants = Constants;         base.MaxOpPriority = 3;     }     static new Function[] Functions =     {         new Function("abs",   Math.Abs),         new Function("acos",  Math.Acos),         // ...     }     static double Add(double x, double y)     {         return x + y;     }     // weitere Operatormethoden ...     static new Operator[] Operators =     {         new Operator('+', Add,      OpType.Unary,  0),         new Operator('-', Sub,      OpType.Unary,  0),         new Operator('^', Math.Pow, OpType.Binary, 3),         new Operator('#', Root,     OpType.Binary, 3),         new Operator('*', Mul,      OpType.Binary, 2),         new Operator('/', Div,      OpType.Binary, 2),         new Operator('%', Mod,      OpType.Binary, 2),         new Operator('+', Add,      OpType.Binary, 1),         new Operator('-', Sub,      OpType.Binary, 1)     };     static new Constant[] Constants =     {         new Constant("E", Math.E),         new Constant("PI", Math.PI)     }; };

Der Aufruf des Formelparsers ist dann ganz einfach:

C#-Code:

FormulaParser fp = new FormulaParser(); try {     string sFct = "14 * 3^2 * (sin(x)^2 + cos(x)^2) / (30.0e-1 * ln(E))";     double x = 10.42;     double y = fp.Parse(sFct, x); } catch(FctException ex) {     MessageBox.Show(ex.Message, "Error"); }

Sollte die Formel nicht korrekt sein, so wird eine 'FctException' geworfen.

Analog lassen sich somit auch Parser (bzw. Interpreter) auf der Grundlage anderer Datentypen (z.B. decimal, int, long, Complex, ...) erstellen.
Im angehängten Projekt ist außerdem noch ein Beispiel für einen Parser basierend auf logischen Ausdrücken (LogicParser).
Desweiteren ist dort ein Testprojekt für den FormulaParser: FctParser.

Außerdem verfügt der Parser noch über einige weitere Einstellungsmöglichkeiten:
- Culture: verwendete CulturInfo für die Zahlen (Standard: invariant, d.h. Punkt '.' als Trennzeichen bei "Kommazahlen" -)
- IgnoreCase: gibt an, ob die Groß-/Kleinschreibung ignoriert wird (Standard: true)
- FunctionBracket, OperatorBracket: Struktur für die öffnende und schließende Klammer (Standard: jeweils '(' und ')' )
- ParseNumber: virtuelle Methode zum Überschreiben, falls nicht die Standardzahlen (ParseDouble) verwendet werden

Edit:
- IsNumberChar: virtuelle Methode, um Zahlen zu erkennen (Standard: Ziffern und Komma-Trennzeichen)
- IsIdentifierChar: virtuelle Methode, um Namen für Variablen, Funktionen und Konstanten zu erkennen (Standard: nur Buchstaben)
- Operatoren aus mehreren Zeichen (z.B. &&, <=, !=, etc.)

Desweiteren habe ich zwei weitere Beispielparser in das Projekt reingepackt:
- ConditionalParser<T, Parser>: Erweiterung eines Parsers (z.B. FormulaParser) um Vergleichsoperatoren
- IntParser: Ganzzahlarithmetik sowie Bitoperationen

Edit #2:
Ich habe nochmals das Projekt erweitert und den Punkt
- Aufbau eines Abstract Syntax Trees (AST), d.h. "Vorkompilierung"
umgesetzt.

Es gibt jetzt zwei weitere Klassen:
- Eval
- ExprTree

Durch die Vorkompilierung habe ich Performanceverbesserungen bei der Auswertung von ca. 20 - 60 mal hinbekommen.
Die Anwendung ist ebenso einfach wie zuvor:

C#-Code:

Eval<double> eval = new Eval<double>(); // bzw. (true) für interne Optimierungen FormulaParser fp = new FormulaParser(); string sFct = "2*x+PI"; eval.Parse(fp, sFct); string sOptFct = eval.ToString(); // Ausgabe der (optimierten) Formel for(double x = 0; x < 1000; x++) {   double y = eval.Evaluate(x);   // ... }

Die Vorberechnung lohnt sich natürlich nur dann, wenn man dieselbe Formel für verschiedene Parameterwerte (x) aufruft.

Um die verschiedenene Formeln besser zu testen, habe ich auch das Textprojekt "FctParser" erweitert. Man kann nun zwischen 6 verschiedenen Parsern wählen und entweder direkt die Formel auswerten oder aber mittels der "StopWatch" Performance-Messungen durchführen. Die CheckBox 'Evaluate' aktiviert dann den Aufbau des ExpressionTrees mittels der Klasse Eval.

Die Basis-Klasse 'FctParser<T>' habe ich um die Interface-Klassen 'IParser<T>' sowie die nicht-generische Klasse 'IParser' erweitert.
Desweiteren gibt es nun 5 virtuelle Execute...-Methoden, welche die Eval-Klasse zum Aubau des ExprTree benötigt (anstatt direkt das Ergebnis auszurechnen).

Als Bonbon kann man sich im Testprojekt nun mit dem Info-Button "?" die verwendeten Funktionen, Operatoren, Konstanten sowie Variablen anzeigen lassen (per MouseHover bzw. bei Klick als MessageBox-Dialog).

Edit #3:
So als vorerst letzte Erweiterung habe ich nun den Punkt
- Funktionen mit mehr als einem Parameter
umgesetzt.

Es gibt nun die zusätzliche generische Klasse FctCaller, welche Delegates mit einer unterschiedlichen Anzahl von Parametern erlaubt. Implementiert habe ich bisher die davon abgeleiteten Klassen für 1, 2 und beliebig viele (-1) Parameter. Als zusätzliche Beispiele dafür habe ich im FormulaParser die Methoden 'max', 'min' sowie 'sum' hinzugefügt.

---------------------------------------------------------------------
So ich hoffe, dieser Parser finden Anklang und Verwendung.

Es gibt sicherlich auch noch einige mögliche Verbesserungen:
- mehrere Variablen (anstatt nur 'x') (wobei dies auch über die Konstantenliste erreicht werden kann)
- Performanceverbesserungen beim Lookup (Dictionary statt List)
- ...

Bei explizitem Interesse kann ich ja auch noch diese einzelnen Punkte umsetzen...

Schlagwörter: Parser, FormelParser, MathParser

Hi, Th69.

Coole Sache!

Mit einer kleinen Anpassung ist ein Hex-Rechner auch machbar.
Mit diesem kann man dann z.B. folgendes rechnen: 0xF0 | 0x0F ergibt 255 [FF]

Zahlen können im dezimalen oder im hexadezimalen (mit Präfix 0x) System eingegeben werden.

Operatoren: And (&), Or (|), Xor (^), Not (~).

In der Klasse FctParser<T> in der Methode T GetTerminal(ref char c) folgendes ändern:

C#-Code:

if (c == OperatorBracket.bra) { ... } else if (IsDigit(c)) // Hier war vorher "Char.IsDigit(c) || c == Dot"     ... else if (Char.IsLetter(c)) { ... }

Und die Methode bool IsDigit(char c) hinzufügen:

C#-Code:

protected virtual bool IsDigit(char c) {     return Char.IsDigit(c) || c == Dot; }

Damit sind die Grundlagen für folgenden Hex-Rechner gelegt:

C#-Code:

using System; using System.Collections.Generic; using System.Text; using System.Text.RegularExpressions; namespace MathParser {     public class HexCalculator : FctParser<Int32>     {         public HexCalculator()         {             base.Functions = Functions;             base.Operators = Operators;             base.Constants = Constants;             base.MaxOpPriority = 3;         }         static new Function[] Functions =         {         };         static Int32 Not(Int32 x, Int32 y)         {             return ~y;         }         static Int32 Or(Int32 x, Int32 y)         {             return x | y;         }         static Int32 And(Int32 x, Int32 y)         {             return x & y;         }         static Int32 Xor(Int32 x, Int32 y)         {             return x ^ y;         }         static new Operator[] Operators =         {             new Operator('~', Not, OpType.Unary,  0),             new Operator('^', Xor, OpType.Binary, 3),             new Operator('|', Or,  OpType.Binary, 2),             new Operator('&', And, OpType.Binary, 1),         };         static new Constant[] Constants =         {         };         private static List<Char> m_HexChars = new List<Char>("0123456789abcdefABCDEFxX".ToCharArray());         protected override Boolean IsDigit(Char c)         {             return m_HexChars.Contains(c);         }         private static Regex m_HexRegex = new Regex(@"0x(?<Digits>[a-f0-9]+)", RegexOptions.Compiled | RegexOptions.IgnoreCase | RegexOptions.ExplicitCapture);         protected override Int32 ParseNumber(ref Char c)         {             StringBuilder sb = new StringBuilder();             while (IsDigit(c))             {                 sb.Append(c);                 c = GetNextChar();             }             var str = sb.ToString();             var match = m_HexRegex.Match(str);             if (match.Success)             {                 return Convert.ToInt32(match.Groups["Digits"].Value, 16);             }             return Convert.ToInt32(str);         }     } }

Gruß, Christian.

Ich habe den Formelparser noch mal (mit einigem Aufwand) erweitert (s. Edit #2 im Hauptbeitrag).

Zum Einsatz dieses Parsers in z.B. Graphprogrammen kann die neue Klasse 'Eval' nun hervorragend eingesetzt werden, um deutliche Performanceverbesserungen zu erzielen: einfach mal selber im Testprojekt ausprobieren...

Die vorherige Version habe ich jetzt hier in diesen Anhang verschoben (insbesondere für Anfänger, denen die aktuelle Version evtl. zu komplex ist).

Als nun vorerst letzte Erweiterung habe ich Funktionen mit einer unterschiedlichen Anzahl von Parametern implementiert (s. Edit #3 im Hauptbeitrag).

Ich wollte mich auch noch für die 18 Leute bedanken, die bisher meinen Parser heruntergeladen haben (leider wird der Counter bei jeder neuen Version wieder zurückgesetzt -). Also auf ein neues...

echt geniales ding - DANKE für deine mühen!!!

Hallo Th69,

erstmal - ein wunderbares Tool hast du da erstellt. Auch die Erklärungen dazu sind schön verständlich und wecken wohlige Erinnerungen ans Studium.

Kleine Anmerkung noch:
Wenn man die Assign Methode und den '=' Operator vom ConditionalAssignmentParser in den FctParser verschiebt funktioniert das ganze so wie es soll.

Ich bin damit allerdings noch nicht so richtig zufrieden und werde das Thema wieder verfolgen, sobald ich etwas mehr Zeit habe.

da scheint noch ein BUG zu sein.

nutze den FormulaParser und wenn ich versuche die folgenden Ausdrücke zu parsen, kommt er auf eine Exception

3*-3
3/-3

zwischen den beiden operatoren ist in meinem fall kein leerzeichen. sobald ein leerzeichen zwischen ist, funktioniert es wiederrum.

ich glaube zu dieser exception wird es immer kommen, wenn zwei operatoren hintereinander eingegeben werden, also auch beim ausdruck 3--3.

lässt sich das problem irgend wie lösen?

nein leider bringt die fallback zeile noch nichts.

Meine erste Idee war das Operatoren Array zu erweitern, mit

C#-Code:

static new Operator[] Operators =         {             ...             new Operator("*-", MulNegativ, OpType.Binary, 2),             new Operator("/-", DivNegativ, OpType.Binary, 2),             new Operator("*+", Mul, OpType.Binary, 2),             new Operator("/+", Div, OpType.Binary, 2)         };

MulNegativ und DivNegativ haben es dann errechnet, in dem Moment hatte ich nur noch nicht gemerkt, dass es noch andere Konstellationen geben könnte :-(

Wenn die Operatoren mit Whitespaces gekapselt sind, klappt es ja, daher meine nächste Idee, den Formula String vor dem Parsen Char für Char durchzugehen und bei jedem operator ein Whitespace vor zu setzen.

Wodurch aus 3*-3 ein 3 * -3 entstehen würde.

Was meinst du dazu?

C#-Code:

public T Parse(Str function, T x) {     function = NormalizeFormula(function);     sFunction = function;     xValue = x;     Functionator = function.GetEnumerator();     char c = '\0';     T y = Expression(ref c);     if(c != '\0')         throw new FctException("Unexpected character at end of expression", c);     return y; }

C#-Code:

public Str NormalizeFormula(Str function) {     Str newFunction = String.Empty;     IEnumerator<char> e = function.GetEnumerator();     while (e.MoveNext())     {         char chr = e.Current;         bool isOp = false;         IEnumerator<Operator> opEnum = Operators.GetEnumerator();         while (opEnum.MoveNext())         {             Operator op = opEnum.Current;             if (op.sOp == chr.ToString())             {                 isOp = true;                 break;             }         }         if (isOp)             newFunction += " " + chr;         else             newFunction += chr.ToString();     }     function = newFunction;     return function; }

Hallo Th69,

ok, so ist es natürlich viel besser. :-)


Thx

Hallo alle zusammen,

habe gerade durch Zufall entdeckt, daß dieser Thread nun zu den "oberen Zehntausend" gehört (hat wirklich lange gedauert sooft zu klicken... - kleiner Scherz ;-) und angesichts des heutigen Datums wünsche ich allen Forumsmitgliedern auch gleich ein Frohes Neues Jahr.

Ich bedanke mich auch recht herzlich, daß an dieser Komponente so ein reges Interesse besteht und schon mehr als 500 mal heruntergeladen wurde.

P.S. Falls Leser sich wundern, warum ich nicht direkt auf den Beitrag von Aratar eingegangen bin - wir haben dies per PM erörtert, aber ich habe noch keine Rückmeldung erhalten, ob die Einbindung (Überschreiben von ParseNumbers) wirklich geklappt hat.

Hallo Claudius,

ich habe keine eigenen Lizenzbedingungen (außer der unter  Lizenzbedingungen für .NET-Komponenten und C#-Snippets auf myCSharp.de ).
Und ich wünsche es mir sogar, daß mein Parser auch in kommerziellen Produkten eingesetzt wird (wobei es schön wäre, wenn ich - Th69 - in den Infos/Credits erwähnt werde bzw. ein Link auf diese Seite. Umgekehrt reicht es mir aber auch, wenn der Name des Produktes bzw. ein Link auf die offizielle WebSite hier oder per PN gepostet wird).

Hallo Th69,

vielen Dank für diesen super Formel-Parser. Vor allem die Performance ist genial!

Ich verwende den Parser in einer Reporting-Lösung, in der bisher nur die Grundrechenarten verwendet werden. Allerdings haben wir jetzt die Anforderung, auch komplexere Formeln auszuwerten, die auch Funktionen unterstützen sollen.

Also zum Beispiel: "If(Bruttoumsatz = 0, 0, Nettoumsatz / Bruttoumsatz)", wobei die beiden Variablen Bruttoumsatz und Nettoumsatz vor der Formelauswertung durch den konkreten Wert ersetzt werden, tatsächlich wäre die auszuwertende Formel also z.B. "If(100 = 0, 0, 75 / 100)".

Meine Frage wäre jetzt also, ob sich dein Formel-Parser mit relativ wenig Aufwand so anpassen ließe, dass er eben auch Funktionen und Vergleichsoperation (größer, gleich, ungleich usw.) unterstützt oder würdest du sagen, dass das dein Formel-Parser einen ganz anderen Ansatz verfolgt und sich das nicht so leicht als Add-On realisieren lässt?

Wäre schön, wenn du dazu kurz deine Einschätzung schreiben könntest.
Falls es gehen würde, könntest du mir einen Anhaltspunkt geben, wo ich eingreifen müsste?

Vielen Dank schon mal vorab! :)

Hallo Andreas,

vielen Dank für das Lob.
Wie pdelvo geschrieben hat, kannst du einfach neue Funktionen definieren. Und die Variablen, z.B. Nettoumsatz und Bruttoumsatz, kannst du einfach der Konstantenliste hinzufügen und vor jedem Parse-Aufruf entsprechend die Werte anpassen.

Und pdelvo: der ConditionalParser war auch eher für Ganzzahlen gedacht. Wegen dem Typparameter T habe ich eben nur die allgemeingültigen Methoden Equals und CompareTo benutzt. Aber ein auf Fließkommazahlen angepasster Parser läßt sich ja leicht erstellen ;-)

Hallo Andreas,

möglich ist alles, jedoch kann ich den Aufwand nicht vorhersagen.
Die Schwierigkeit besteht darin, daß bisher mein Parser nur auf genau einem Datentypen agiert, d.h. auch der ConditionalParser arbeitet nur auf dem zugrundeliegenden Datentypen T und nicht auf 'bool'.

Probiere aber einfach mal den ConditionalParser in Verbindung mit dem FormulaParser aus. Am besten du erzeugst dir aus dem Code vom ConditionalParser einen neuen Parser 'ExcelParser' o.ä. und schmeißt die nicht benötigten Funktionen / Operatoren raus:

C#-Code:

public class ExcelParser : FctParser<double> {    // ...    FormulaParser parser = new FormulaParser();    // ... }

Und bei den benötigten Methoden Less, Equal, Greater, ... änderst du den Datentypen fix auf double und implementierst sie (ähnlich wie pdelvo vorgeschlagen hat), z.B.

C#-Code:

const double Epsilon = 1e-15; static double Equal(double x, double y) {     return (double)(Math.Abs(x - y) < x * Epsilon); }

Und dort fügst du dann noch deine if-Funktion hinzu (auf Grundlage der von pdelvo geschriebenen Methode, aber jetzt nur noch mit 3 Argumenten):

C#-Code:

static double If(double[] arguments) {     if(arguments == null || arguments.Length != 3) throw new ArgumentException("arguments");     return !Equal(arguments[0], 0)? arguments[1] : arguments[2]; } static new Function[] Functions = {   new Function("if", If) }

Viel Erfolg dabei...

Hallo Th69,

das Projekt Excel-Parser habe ich erstmal auf Eis gelegt, da es letztlich nur "nice to have" und kein "must have" war.
Dafür benutze ich deinen FormulaParser sowie den ConditionalParser und alles in allem leistet dein Parser super Arbeit.

Mir sind jetzt aber zwei Probleme aufgefallen, vielleicht könntest du (oder gerne auch jemand anderes) ein wenig Licht auf die Sache werfen.

Ich verwende den ConditionalParser<double, FormulaParser>.
Nehmen wir einmal folgende Formel an: ((1) + (-1)) == 0; hier erhalte ich die Fehlermeldung "Missing bracket: )". Aber eigentlich fehlt ja keine Klammer. Auf die Klammern um die Zahlen herum könnte man zwar verzichten (dann funktioniert die Auswertung der Formel auch), aber dennoch sollte das ja kein Problem darstellen, oder?

Das ist jetzt kein dramatisches Problem, man kann es ja leicht umgehen. Ich wollte es trotzdem erwähnen, weil es sich für mich wie ein Bug darstellt.
Das eigentlich gewichtigere Problem das ich habe ist der Vergleich von double-Werten, wobei die double-Ungenauigkeit ein falsches Ergebnis liefert.

Z.B. habe ich folgende Formel: (5819.03 - 2666 - 3153.03) == 0; der linke Vergleichswert ergibt eigentlich den Wert 0; dadurch müsste die Prüfung auf Gleichheit mit dem rechten Wert true zurückgeben. Tatsächlich liefert in diesem Fall dein Parser das Ergebnis false; was sehr ärgerlich ist, weil das Ergebnis nicht richtig ist (und somit meine Anwendung "falsch" funktioniert).

Ich hab mir die Equal-Methode im Conditional-Parser angeschaut; bei der o.a. Formel kommt für x der Wert -0.00000000000045474735088646412 und für y der Wert 0.0. Die Überprüfung x.Equals(y) ist dementsprechend aus Sicht des Computers richtig.
Ich hab hier auch testweise (im Debugger) die Überprüfung unter Berücksichtigung der Ungenauigkeit durchgeführt, die du und pdelvo in den vorherigen Beiträgen erwähnt habt, mit Epsilon = 1e-15; aber auch hier ist das Ergebnis noch false.

Gibt es für dieses Problem eine einfache und korrekte Lösung?

Danke und Gruß,
Andreas

Hallo Andreas,

bzgl. des ConditionalParsers kommt der Parser mit den zwei Hierarchie-Ebenen (Vergleiche <-> Formeln) bei den Klammern durcheinander. Dazu müßte man stattdessen wohl einen Parser schreiben (der dann aber auch wieder die Unterscheidung zwischen bool und T kennen müßte).

Und bzgl. des double-Vergleichs hätte ich zwei Vorschläge:
- Umstellung auf decimal (anstatt double), da du ja anscheinend mit Geldwerten (Konten) agierst
- In Anlehnung an  The Floating-Point Guide - Comparison die Vergleichsfunktion so schreiben:

C#-Code:

public static bool NearlyEqual(double a, double b, double epsilon) {     if (a == b) // shortcut, handles infinities         return true;     double diff = Math.Abs(a - b);     if (a == 0 || b == 0)     {         // a or b is zero         // relative error is less meaningful here         return diff < epsilon;     }     else     {         double absA = Math.Abs(a);         double absB = Math.Abs(b);         // use relative error         return diff / (absA + absB) < epsilon; // alternativ stattdessen Math.Max(absA, absB)     } }

Es wird also der relative Fehler verglichen, außer einer der beiden Werte ist 0!

Evtl. mußt du dann doch einen anderen (mächtigeren) Parser, wie  muparser - fast math parser library,  NCalc - Mathematical Expressions Evaluator for .NET oder  Mathos Parser benutzen!?

PS: Ich habe gerade gesehen, daß ich genau 2000 Beiträge hier im Forum verfasst habe, dies dann also mein Beitrag #2001 ist, und das nach knapp 6 Jahren (d.h. fast jeden Tag ein Beitrag - ich bin wohl forumssüchtig?).