Diskussion:Operatorrangfolge

message: Welche Priorität haben einstellige Operatoren wie sin oder log? Konkret: \log a^b, ist das als (\log a)^b oder als \log (a^b) zu lesen? Ich denke, das zweite ist richtig, habe dafür aber keinen Beleg. 
: Dieses hängt von der Programmiersprache oder der definierte Operatorrangfolge ab (man kann unterschiedliche definieren, hängt nicht unbedinge mit ein- oder zweistellige Operatoren zusammen). Im konkreten Fall bindet der Potenz stärker als log, also das zweite. --WiseWoman 00:07, 27. Mär. 2008 (CET)
thread_title:  log, sin etc. 

message: "Von den genannten arithmetischen Operatoren ist die Potenzierung rechtsassoziativ, d. h.:
: a^{b^{c^{d}}} \  = \ a^{\left(b^{\left(c^{d}\right)} \right)}\ \neq \ \left(\left(a^b\right)^c\right)^d."
Für mathematische Formeln gilt das, aber auch für Programmiersprachen? Zumindest wenn man in MATLAB den Ausdruck "2^3^2" eingibt und anschließend die Eingabetaste betätigt, erhält man 64 als Ergebnis. Nach der Rechtsassoziativität der Potenzierung müsste aber 512 dabei herauskommen.
Dasselbe gilt für das Microsoft-Tabellenkalkulationsprogramm "Excel".
Das Windows-Zubehör-Taschenrechnerprogramm hält sich im Standardmodus nicht an irgendwelche Operatorprioritäten, im wissenschaftlichen Modus doch.
Wenn also auch schon bei der Vorzeichenpriorität ein Compiler eine Formel eingegebene anders liest, als sie als mathematische Formel gelesen werden müsste, könnte das bei der Assoziativität der Potenzierung ähnlich sein?--Slow Phil 14:18, 18. Mär. 2008 (CET)
replies: text: Sowohl der **-Operator in Python als auch der ^-Operator im POSIX-bc (Basic Calculator) sind rechtsassoziativ. -- memset 17:42, 27. Mär. 2008 (CET)

text: "Rechtsassoziativ" (auf deutsch: "von rechts zusammenfassend") bei infix-Operatoren heißt, dass a • b • c wie a • (b • c) ausgewertet wird. Ein linksassoziativer Operator dagegen würde den Ausdruck wie (a • b) • c auswerten. Die meisten arithmetischen Operatoren sind sowohl in der Mathematik als auch in den üblichen Programmiersprachen linksassoziativ. Da die Potenzierung in der Mathematik aber rechtsassoziativ ist, folgen manche Programmiersprachen dieser Konvention. Andere Programmiersprachen sind eher auf Einfachheit im Parser designt, dort sind dann alle Operatoren linksassoziativ. Die beiden alten Sprachen Fortran und Algol, von denen viele heutige Programmiersprachen mehr oder weniger "abstammen" unterschieden sich da zum Beispiel, wobei ich jetzt nicht weiß, welche Sprache diesen Operator auf welche Weise geklammert hat. :-/ --RokerHRO 01:02, 28. Jul. 2008 (CEST)
thread_title:  Rechtsassoziativität der Potenzierung 

message: Eine Frage: Wie würde Folgendes ausgewertet werden: "a*b*c/d"? Habe ich den Artikel dahingehend richtig verstanden, dass es gemeinhin als (a*b*c)/d definiert ist? Vielleicht könnte das noch als Beispiel in den Artikel aufgenommen werden, da es ein häufiger vorkommender Fall ist. 92.116.166.168 18:09, 27. Jul. 2008 (CEST)
replies: text: Ich wüsste nicht, wieso. Bei Programmiersprachen wie C, C++ oder Java ist es so definiert, wie du es beschreibst. In der Mathematik tritt das Problem seltener auf, da Divisionen dort üblicherweise mit einem Bruchstrich geschrieben werden, der "implizit" klammert: \tfrac{a\cdot b\cdot c}{d}. Problematisch sind dann nur gestapelte Brüche wie \frac{\frac a b}{\frac c d} im Vergleich etwa zu \frac{\frac{a}{\frac b c}}{d}, wo die "Klammerung" an der vertikalen Ausrichtung der Formel, der Größe des Bruchstriches und ggf. der Größe der Zeichen zu erkennen sein sollte \left( x = \frac{\frac a b}{\frac c d} \neq \frac{\frac{a}{\frac b c}}{d} \right). --RokerHRO 00:49, 28. Jul. 2008 (CEST)
replies: text: Bei diesem Beispiel, wo die Division ganz am Schluss auftritt, ist es völlig egal, wie da geklammert wird. (a*b*c)/d ist dasselbe wie a*b*(c/d) usw. --Digamma (Diskussion) 16:46, 6. Mär. 2018 (CET)
thread_title:  Assoziativität von Multiplikation / Division 

message: Es ist in der Mathematik doch strikt festgelegt, welche Rechenzeichen/ Operatoren in welcher Reihenfolge/ Rangfolge ausgewertet werden. Gibt es dazu eine Seite in Wikipedia? Ich fände das sehr nützlich, da ich ab und zu durcheinander komme und dann gern schnell nachschlagen könnte. Hier ist doch ein guter Platz dafür oder? Und es könnte auch gesagt werden, dass es allgemein gilt, dass es egal ist, wie man Operatoren auswertet, wenn sie keine Rangfolge haben. Somit hätte man glaube ich alles abgedeckt, fände ich super. Ich will deswegen fragen, ob es da Einwände gibt. -- Lexischemen 18:27, 19. Mär. 2010 (CET)
thread_title:  Rangfolge alle Operatoren/ Zeichen 

message: Mich lässt im Augenblick die Frage nicht mehr los, ob es sich bei der Operatorrangfolge letztendlich "nur" um eine Konvention handelt oder ob es eine normative Autorität gibt, die solche Regelungen verwaltet, Empfehlungen ausspricht o.ä.? Das schließt natürlich andere Regelungen der "Sprache" Mathematik mit ein. -- 2003:D1:2BC0:D100:5D3B:5ED1:9D9D:69CC 15:29, 12. Sep. 2016 (CEST)
replies: text: Nein, so eine Autorität gibt es nicht. Wird auch nicht benötigt, da sich Mathematiker ja nicht nach Autoritäten richten, sondern sich ihre Formelsprache so zurechtlegen, wie es zweckmäßig und praktisch ist. Und bei "Punktrechnung vor Strichrechnung" usw. ist die im Artikel genannte Rangfolge halt für alle Mathematiker am praktischsten. Es gibt Bereiche, wo mal diese, mal jene Definition zweckmäßiger ist und es somit keinen Konsens unter den Mathematikern gibt (z.b. "Ist 0 eine natürliche Zahl?"). In jenen Fällen starten mathematische Abhandlungen oft mit einer Reihe von Festlegungen, die dann in diesem Buch/Kapitel/Beweis/Paper gelten sollen, oder aber man verwendet Notationen, die in jedem Falle eindeutig sind. Also: nur geklammerte Terme bei Boolescher Algebra, oder Formulierungen wie "natürliche Zahlen ohne Null" oder "Natürliche Zahlen und Null" usw. --RokerHRO (Diskussion) 11:11, 13. Sep. 2016 (CEST)
thread_title:  Konvention oder Norm? 

message: Man sollte mal von den Erklärungen über "Auswertungsreihenfolgen" wegkommen. Wenn ich den Term 0\cdot 3^{17} auswerten will, rechne ich doch nicht zuerst 3^{17} aus. In dem C-Ausdruck X || Y && Z darf Y && Z überhaupt nicht zuerst ausgewertet werden, sondern, es wird zuerst X ausgewertet, und je nach Ergebnis dessen, Y && Z erst hinterher oder eben überhaupt nicht. Auch wenn man den Ausdruck (völlig äquivalent!) als X || (Y && Z) schreibt, wird nicht zuerst Y && Z ausgewertet.
Vielmehr geht es um eine Äquivalenz von (in linearer Syntax geschriebenen) Termen: a \cdot b^c ist (bei üblicher Rangfolge) einfach eine klammersparende Variante von a\cdot (b^c), aber nicht von (a \cdot b)^c. Die ersten beiden haben denselben Syntaxbaum.
Wenn man nicht über Syntaxbäume oder Parsen sprechen will, obwohl es bei einer Festlegung von Operatorrangfolgen ja genau darum geht, kann man sich sicherlich auch recht direkt mit einem "steht für" behelfen: "\cdot hat eine höhere Priorität als +, deshalb steht a+b\cdot c für a + (b\cdot c)." etc.
Desweiteren, und das wird auch hier auf der Diskussionsseite deutlich, scheinen viele zu denken (und der Artikel tut gegenwärtig eigentlich nichts gegen dieses Missverständnis), dass verschiedene Operatoren, die für dieselbe Operation stehen, syntaktisch bzgl. Rangfolge und Links-/Rechtsassoziativität dieselben Eigenschaften haben müssen. Dabei spricht ja gar nichts dagegen, z.B. der Multiplikation dargestellt durch Juxtaposition eine höhere Priorität zu geben als Muliplikation dargestellt mit \cdot und Division mit :, und Division mit / eine niedrigere Priorität als \cdot,:, und dann Juxtaposition, \cdot,:,/ in derselben Sprache koexistieren zu lassen. Am Ende ist es eine Frage des Sprachdesigns. --Daniel5Ko (Diskussion) 23:20, 10. Jun. 2023 (CEST)
thread_title:  Auswertungsreihenfolge, Syntax und Semantik