Formelinterpreter, Programmierbarer Tabellenrechner

[Dipl Phys Ernst Winter]

Interpreter für anwenderdefinierte Funktionen
Die Unit Formel exportiert:

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]

[oki]

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

[sirius]

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.

[Dipl Phys Ernst Winter]

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.

[Dax]

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 ;)

[Dipl Phys Ernst Winter]

"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.

[Dax]

Zitat:

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:

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:

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:

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.

[Go2EITS]

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.

[mkinzler]

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.

[alzaimar]

Huch? Was ist denn hier los?

Ich halte Herrn Winter für durchaus in der Lage, den 'Fedehandschuh' :zwinker: 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.

[Dust Signs]

Guten Morgen, Herr Winter!

Ich hätte einige Anregungen zu Ihrem Formelinterpreter. Über die Geschwindigkeit kann ich mir an dieser Stelle kein Urteil bilden - vielleicht hat ja irgendjemand hier Zeit, um einen Geschwindigkeitsvergleich mit Dax' Parser anzustellen. Zu Ihrem Parser:
* Hat es einen besonderen Grund, dass nur Ziffern als Exponenten erlaubt sind? Selbstverständlich lässt sich x^x in exp(x*ln(x)) umschreiben, doch wäre x^x eine weit kürzere Schreibweise - und da der Potenzoperator ja ohnehin vorhanden ist könnte er doch erweitert werden
* Mir scheint als würden die Negation und die Subtraktion (unär und binär) bezüglich ihrer Priorität nicht unterschieden werden, was bei Ausdrücken wie 1/-x oder 1--x zu einem Syntaxfehler führt ("doppelter Operator"). Da das durch entsprechende Klammersetzung umgangen werden kann ist das allerdings kein Problem - es ließe sich vermutlich ohenhin darüber streiten, ob die Ausdrücke überhaupt syntaktisch korrekt sind (ebenso wie -x^-x). Meiner Meinung nach sind sie das, aber ich weiß nicht, wie streng die dem Parser zugrunde liegende Grammatik definiert ist und ob sie derartige Ausdrücke überhaupt erlaubt (e scheint so, als wäre das nicht der Fall)
* Die Euler'sche Zahl als Konstante wäre noch praktisch - so muss man nicht immer exp(1) schreiben, wenn man sie benötigt

Das Programm gefällt mir ansonsten sehr gut :thumb:

Dust Signs

[mschaefer]

Lasst doch den HAM-Parser mal dagegen laufen. Beide Programme sind gut, da bricht sich ehedem keiner einen Zacken aus der Krone.
Vom Programmcode her gefällt mir die Unit gut, da sie dokumentiert ist. Das ist nicht selbverständlich. Also eine runde Sache !

Grüße // Martin

[himitsu]

OK, der Code hier ist zumindestens recht kurz und übersichtlich,
aber bei der Einrückung könnte man noch etwas aufräumen.

PS: bezüglich Geschwindigkeit:

Delphi-Quellcode:

until Pos(Zei,'0123456789')=0;
// entspricht
until not (Zei in ['0'..'9']);
// und enthält keine Char-To-String-Umwandlungen sowie kein großen String-Vergleich

und auch wenn du in der Formel alles kurz halten willst ... die Funktions- und Variablennamen könnte man dennoch etwas länger und aussagekräftiger gestalten (diese werden dann eh vom Compiler rauskompiliert)

[gammatester]

Hier mal eine konstruktive Kritik :wink: (bzw. Fehlerreport/Frage). Beim Progtabrechner liefert y=x^2^3 dieselben Ergebnisse wie y=x^2 ohne Hinweise auf Fehler oder so. Eigentlich wollte ich nur testen ob x^2^3 als (x^2)^3 oder als x^(2^3) geparst wird.

Ich glaube, die Implementation kommt mit x^y^z ohne Klammern nicht klar, liefert aber keinen Fehler.
Gammatester

[sirius]

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.

[Dipl Phys Ernst Winter]

Dust Signs schreibt

Zitat:

Mir scheint als würden die Negation und die Subtraktion (unär und binär) bezüglich ihrer Priorität nicht unterschieden werden, was bei Ausdrücken wie 1/-x oder 1--x zu einem Syntaxfehler führt ("doppelter Operator").

In den Ausdrücken wie 1/-x oder 1--x ist das Vorzeichen von x wie ein Operator eingefügt, das führt natürlich zu einem Syntaxfehler. Richtig ist x mir einem negativen Wert zu belegen.

[Dipl Phys Ernst Winter]

Vielen Dank an Gammatester!

An y=x^2^3 habe ich nicht gedacht.

Es stimmt: Die Implementation kommt mit x^2^3 ohne Klammern nicht klar.

^n mit n 0..9 muß wie ein Operator behandelt werden, damit fehlt bei x^2^3 eine Fehlermeldung.

Nochmals vielen Dank, ich habe die Fehlermeldung 'Fehlender Operand' für aufeinanderfolgende Potenzierungen eingefügt.

[Jakob Ullmann]

Warum nicht lieber den "Bug" fixen?

Zitat:

^n mit n 0..9 muß wie ein Operator behandelt werden, damit fehlt bei x^2^3 eine Fehlermeldung.

Wie meinst du das? Das ^ ist doch genau wie +, -, *, / ein Operator und kann auch entsprechend behandelt werden.

[Dust Signs]

Zwei Anmerkungen hätte ich noch:

* 0^0 ist nicht 1, sondern undefiniert
* 2^(-1) ist nicht erlaubt. Die Fehlermeldung macht zwar insofern Sinn, als dass - keine Ziffer, aber -1 sehr wohl eine Zahl ist. Oder übersehe ich hier etwas?
* -1^2 ist nach meiner Interpretation 1, da das unäre Minus eine höhere Priorität hat als der Potenzoperator, d.h. der Ausdruck äquivalent zu (-1)^2 sein müsste anstatt zu -(1^2)

Dust Signs

[Mithrandir]

Zitat:

Zitat von Dust Signs

* -1^2 ist nach meiner Interpretation 1, da das unäre Minus eine höhere Priorität hat als der Potenzoperator, d.h. der Ausdruck äquivalent zu (-1)^2 sein müsste anstatt zu -(1^2)

Da ist mein Taschenrechner (und ich btw auch) anderer Meinung. ;) -1² ist -1.

[Dust Signs]

Zitat:

Zitat von Daniel G

Zitat:

Zitat von Dust Signs

* -1^2 ist nach meiner Interpretation 1, da das unäre Minus eine höhere Priorität hat als der Potenzoperator, d.h. der Ausdruck äquivalent zu (-1)^2 sein müsste anstatt zu -(1^2)

Da ist mein Taschenrechner (und ich btw auch) anderer Meinung. ;) -1² ist -1.

Wie gesagt: das kommt darauf an, welche Priorität das unäre Minus hat. Wenn es eine niedrigere Priorität hat als der Potenzoperator dann ist das Ergebnis natürlich -1

Dust Signs

[Jakob Ullmann]

So wie ich das sehe ich die ganze Potenzimplementation schlecht. ^ sollte ganz normal wie +, *, -, / behandelt werden. Und wenn man das Rechnen einfach Delphi überlässt, hat man auch mit 0^0 keine Probleme.

Meiner Meinung hat - als Vorzeichen dieselbe Priorität wie der Operator. Lässt sich so eig. auch leichter implementieren. Notfalls sollte man das einstellen können, aber ich denke, -1^2 = -(1^2) ist Standard.

[mkinzler]

Ware das nict so hätten die Elektrotechniker ein Problem

[Dust Signs]

Zitat:

Zitat von mkinzler

Ware das nict so hätten die Elektrotechniker ein Problem

Inwiefern?

Dust Signs

[mkinzler]

Es würden sich die komplexen Terme nicht mehr aufheben

[Dust Signs]

@mkinzler: Nur, damit ich nichts falsch verstehe: beziehst du dich auf die Definition von 0^0 oder die Priorität des unären Minusoperators? Ersterem kann ich nicht zustimmen, da 0^0 ein undefinierter Ausdruck ist (vgl. http://mathworld.wolfram.com/Indeterminate.html). Worauf beziehst du dich konkret, wenn du sagst "die komplexen Terme [würden sich] nicht mehr aufheben" und "die Elektrotechniker [hätten] ein Problem"? Ich hatte selbst einige Etechnik-Vorlesungen während meines Studiums, aber ich kann mir kein Szenario vorstellen, in dem die Definition von 0^0 oder die Priorität des unären Minusoperators ein Problem darstellen könnten. Kannst du mir ein Beispiel geben?

Dust Signs

[mkinzler]

Nein auf den das
1^2 = -(1^2)

[Dust Signs]

Zitat:

Zitat von mkinzler

Nein auf den das
1^2 = -(1^2)

:shock: Das habe ich doch nie behauptet... lediglich -1^2 = -(1^2) sofern die Priorität des unären Minusoperators kleiner ist als die des Potenzoperators

Dust Signs

[Jakob Ullmann]

Möglicherweise hat die [-] Taste geklemmt. :mrgreen:

[Dust Signs]

Dann verstehe ich aber trotzdem nicht, welche komplexen Terme dann keine gültige Lösung mehr liefern würden. Könntest du ein Beispiel liefern, mkinzler? Es würde mich interessieren - vielleicht übersehe ich ja gerade irgendetwas wesentliches.

Dust Signs

[himitsu]

Zitat:

Zitat von Dust Signs

sofern die Priorität des unären Minusoperators kleiner ist als die des Potenzoperators

eigentlich sollte der aber die größte Priorität haben?

[Dust Signs]

Bisher dachte ich immer, dass die Prioritäten folgendermaßen definiert wären (von niedrig zu hoch):

+ binär
- binär
* binär
/ binär
^ binär
+ unär
- unär

Bitte sagt mir, falls ich falsch liege. Die Anmerkung oben zu -1^2 = -(1^2) basierte auf der Annahme, dass die Prioritäten in Herrn Winters Parser nicht den oben aufgeführten entsprechen.

Dust Signs

[himitsu]

offiziell (siehe OH "Ausdrücke")

Zitat:

1. @, not
2. *, /, div, mod, and, shl, shr, as
3. +, -, or, xor
4. =, <>, <, >, <=, >=, in, is

real, da die unären Operatoren direkt zu den Werten gehören

Zitat:

0. + (unär), - (unär), ^ (dereferenzieren)
1. @, not
2. *, /, div, mod, and, shl, shr, as
3. +, -, or, xor
4. =, <>, <, >, <=, >=, in, is

müßte also so sein: -1^2 = (-1)^2

[Dust Signs]

Zitat:

Zitat von himitsu

müßte also so sein: -1^2 = (-1)^2

D.h., meine ursprüngliche Anmerkung war korrekt? @mkinzler: ist dein Kommentar bzgl. der komplexen Zahlen dann noch zutreffend und - falls ja - könntest du ein Beispiel posten?

Dust Signs

[Mithrandir]

:gruebel: Warum verstehe ich hier eigentlich nur Bahnhof? Ich dachte, es handelt sich hier um einen mathematischen Parser? Zumindest mit meinem begrenzten Mathewissensschatz wüsste ich nicht, warum -1^2 = 1 sein sollte.

Ja, ich habe mich im Wiki über das "unäre Minus" informiert. Und da steht:

Zitat:

Diese unterschiedliche Bindungsstärke gilt jedoch nicht in der Mathematik, weswegen dort das unäre Minus meist geklammert werden muss.

Worüber wird also diskutiert? :gruebel:

[Khabarakh]

Hu. Ihr würdet euch also wirklich y = -x² als nach oben geöffnet vorstellen :gruebel: ? Dann sollte man alle Mathelehrer und Taschenrechner sofort auf den Müll schmeißen :drunken: . Und fooplot hat immer recht ;P .

@himi: *hust* Vielleicht solltest du lieber eine Sprache hinzuziehen, die überhaupt einen Power-Operator kennt :zwinker: . Nehmen wir doch mal Python, das dürfte die am weitesten verbreitete sein:

Zitat:

Zitat von http://www.ibiblio.org/g2swap/byteofpython/read/operator-precedence.html

lambda Lambda Expression
or Boolean OR
and Boolean AND
not x Boolean NOT
in, not in Membership tests
is, is not Identity tests
<, <=, >, >=, !=, == Comparisons
| Bitwise OR
^ Bitwise XOR
& Bitwise AND
<<, >> Shifts
+, - Addition and subtraction
*, /, % Multiplication, Division and Remainder
+x, -x Positive, Negative
~x Bitwise NOT
** Exponentiation
x.attribute Attribute reference
x[index] Subscription
x[index:index] Slicing
f(arguments ...) Function call
(expressions, ...) Binding or tuple display
[expressions, ...] List display
{key:datum, ...} Dictionary display
`expressions, ...` String conversion

@Daniel: Ich fühle mich gerade auch im falschen Film ;) .

[Mithrandir]

Zitat:

Zitat von Khabarakh

@Daniel: Ich fühle mich gerade auch im falschen Film ;) .

Na Gott sei Dank. Ich hab schon an meinem Verstand gezweifelt... ;)

[himitsu]

hat wer 'ne Zeitmaschiene?
(vielleicht sollte ich mal statt Delphi meine alte Mathelehrerin besuchen ... aber jetzt wo du's sagst :wall: )

[Dust Signs]

@Daniel, Khabarakh: ihr hattet Recht, -3^2 = -9, auch nach diesem Artikel. Ich hatte also Unrecht, und auch Herr Winters Parser arbeitet in dieser Hinsicht richtig. Wieder was gelernt :)

Dust Signs

[Dipl Phys Ernst Winter]

[quote="Dust Signs"]

Zitat:

Bisher dachte ich immer, dass die Prioritäten folgendermaßen definiert wären (von niedrig zu hoch):

+ binär
- binär
* binär
/ binär
^ binär
+ unär
- unär

Du liegst falsch! Ein Minus bleibt ein Minus, auch wenn es unär vor einem Ausdruck steht. Am einfachsten denkt man sich für einen unären Operator 0- bzw. 0+