Muß aber zugeben, daß mir ist kein vernünftiger Grund eingefallen ist, von rechts auswerten zu müssen, was heißt, daß der Term grundsätzlich mehrdeutig ist und Klammern erzwingt bzw. er als nicht zulässig ausgeschlossen werden sollte.
Ja, vielleicht sollte man dieses Minuszeichen einfach mal weglassen. Wenn -(2^2^3) gemeint ist, bleibt es ohnehin da, wo es vorher war und wenn (-2)^2^3 gemeint ist, bleibt der Exponent in jedem Fall gerade. Die Frage ist doch nur, wie man den TR oder das Programm dazu bringt, entgegen seiner Gewohnheit von rechts nach links zu klammern, also
2^2^3 als 2^(2^3) statt als (2^2)^3 zu interpretieren. Maple liefert zu
2^2^3 korrekterweise "Error, `^` unexpected". Das kann doch nicht so schwer sein, da wartet das Programm eben ab, bis man mit der Eingabe fertig ist statt eifrig mit Zwischenergebnissen weiterzurechnen, wenn man das denn unbedingt so haben will.
Und wenn der Benutzer zu blöd zum Klammern ist und nur fröhlich seine Zahlen eintippt, muss man eben den Benutzer wechseln, nicht den TR.
Weil, ohne Klammern geschrieben, die innere Potenz (minus zwei zum Quadrat) die Basis des äußeren Exponenten (drei) ist.
Wenn -2 jedoch die Basis sein soll, und 2 ^ 3 der Exponent, dann muss 2 ^ 3 natürlich in Klammern geschrieben werden.
Sorry, aber für mich mit meinem mathematischen Wissensstand ("Mathematik für Ingenieure") ist der Term -2 ^ 2 ^ 3 eindeutig und das Ergebnis lautet +64.
Gut, ich verstehe Dich so, daß Du eine klammerlose Mehrfachpotenz automatisch linksgeklammert interpretierst und forderst, wenn's anders gemeint ist, solle man explizit rechts klammern.
Aber warum ist es falsch, wenn man's anders macht. Könnte ich doch mit gleichem Recht fordern: "Wir verstehen eine klammerlose Mehrfachpotenz als automatisch rechtsgeklammert und wenn's anders gemeint ist, soll man gefälligst explizit links klammern."?
Außerdem könnte man noch festlegen: "Eine klammerlose Mehrfachpotenz ist nicht zulässig. Es MÜSSEN Klammern gesetzt werden, damit man weiß, was gemeint ist."
Ich habe meine Meinung geändert: das richtige Ergebnis ist das von Maple: "syntax error" oder sowas wie: "expression ambigious, please use brackets".
Sorry, aber das ist wirklich Blödsinn. Für Dich ist -2² = + 4 = 2²??
Und zwar, weil nicht eindeutig ist, was "innere" und "äußere" Potenz ist. Das hängt nämlich gerade davon ab, in welcher Reihenfolge man auswertet.
Die Richtigkeit des automatischen Linksklammern damit zu begründen, was die innere Potenz ist, die wiederum auf der Richtigkeit des automtischen Linksklammerns beruht, liefe also darauf hinaus zu behaupten, daß automatisch Linksklammern richtig ist, weil automatisch Linksklammern richtig ist.
Ja, aber wie Du siehst, beruft sich Harald genau auf diese Regel, um seine Präferenz zu motivieren, und ich sehe nicht, warum das im Ergebnis inkonsistent wäre. Es ist aber IMHO nicht recht, sich auf diese Regel zu berufen, egal welche Präferenz man hat.
Ich denke, es gibt auch keinen. Weil Potenzieren nicht assoziativ ist, ist die Reihenfolge zwingend eine Konvention. Der Text im Link sagt das auch.
Es gibt einen Vorteil in Form einer abgekürzten Notation. Außerdem bleibt man so in der exponentiellen Struktur und fällt nicht in die multiplikative zurück. Bei a^b^c^d^e^f sieht man das evtl. besser als bei nur zwei Exponenten.
ME ist es eine Bereicherung die Potenz rechtsassoziativ zu definieren gegenüber -- zumindest nicht so sehr -- sie linksassoziatiz zu definieren oder gar keine Assoziation anzugeben. Das war wohl auch Grund genug für genügend Autoren, so dass man jetzt rechtsassoziative Potenzen als "den Standard" ansehen kann -- wenn auch nicht überall vorherrschend.
Bei mir kam's richtig an, aber um's für alle lesbar zu machen ...
Ich kann mich dunkel erinnern, als Programmierübung einen Parser schreiben zu wollen und mit dem Wechsel von "Links" nach "Rechts" und wieder zurück ziemliche Probleme gehabt zu haben ... Natürlich hätte ich den Parser metasprachlich definieren (z.B. BNF) und vorher handschriftlich erarbeiten sollen, wie's geht. Aber ich war jung und brauchte die Selbstbestätigung, außerdem: "Kann doch nicht so schwer sein ..."
Immerhin: der Google TR schafft es immerhin, der Rechtsklammer-Konvention zu genügen.
Nee, das tun die meisten auch, d.h. man darf davon ausgehen, daß ein Parser eine komplette Eingabezeile als Input kriegt und nichts zwischendurch rechnet.
Wie gesagt, einen klammerlosen Potenzterm einfach zu verbieten, würde ich für eine konsistente Lösung halten.
Ja, Mathe erzieht echt zur Demut, was? :-) Da hat sich der lustige Ernst aber ein sa(b)uer Spässken erlaubt, und gestandene Terminatoren legen sich elegant uff die Schnüss ...
P.S. ich war selbst peinlich entsetzt, als ich's kürzlich zufällig las.
... was auch den Vorteil hätte, mit -256 von vornherein richtig gelegen zu haben. :-) Ob ich auch "recht" damit hatte, "syntax error" als "richtig" zu bezeichnen, blick' ich jetzt grad nicht ...
Ich glaube, daß es gar nicht so einfach bzw. aufwändig für einen Programmierer ist, Rechtsklammern sauber einzubauen, weswegen sich viele die Mühe gespart haben dürften - und gar nicht mal sehr vorwerfbar.
Ich kann mich gut an das Verhalten meines (nicht programmierbaren) Schultaschenrechner von Casio - den genauen Typ weiß ich nicht mehr - erinnern. Bei dem war es tatsächlich unmöglich 2Hoch2Hoch3 in einem Rutsch einzugeben. Es gab eine xHochy Taste. Nach der Eingabe: 2 xHochy 2 (ohne über = das Ergebnis anzufordern) gab es auf dem Display die 4 Nun hätte man also noch xHochy 3 eingeben können, was dann 4 hoch 3 = 64 als Ergebnis hatte.
Wenn man also eine Zahl mit einer zu potenzierenden Zahl potenzieren wollte, so war man gezwungen in der folgenden Art seine Eingabe zu machen:
A xhochy (B xhochy C)
Es gab eine +/- Taste um einen Vorzeichenwechsel durchzuführen.
Hätte A einen negativen Wert gehabt, so hätte man schreiben müssen, beginnend mit dem positiven Wert A:
A [Display A]
+/- [Display -A] xhochy [Display -A] ( [Display ( ] B [Display B ] xhochy [Display B ] C [Display Ergebnis von BhochC] ) [Display ) ] = [Display Ergebnis von (-A)hoch(BhochC)]
Deswegen mag ich LL(1) als Parse-Methode nicht: es sieht so aus, als wärs ganz einfach und ist es dann doch ganz und gar nicht. Bei Verfahren aus der LR-Ecke sieht man gleich, dass Mist herauskommt, wenn man es nicht stur planmäßig anfängt: erst die Grammatik, dann systematisch den Parser schreiben.
In einem Compiler gibts nichts zu rechnen. In einem Interpreter (in diesem Sinn ist auch ein Taschenrechner einer) darf er aber gerne losrechnen, sobald eine Phrase erkannt und reduziert ist.
Das erste sieht für mich viel logischer aus. Beim zweiten wird die _vorletzte_ Zahl genommen und dann die letzte als Operation angewandt, die eigentliche "Basis" kommt erstmal gar nicht vor ... irgendwie seltsam.
Logisch wird die umgekehrte Reihenfolge erst, wenn man statt der Potenzfunktion die Exponentialfunktion als Grundoperation heranzieht:
Allerdings fällt mir hier keine geklammerte Darstellung für das Endergebnis ein, die in (II) die Rechnung wie in (I) so schön wiederspiegelt.
Explizite Klammern finde ich hier (wie auch in 2/3*4/7/2) jedenfalls besser, als juristische Lösungen.
Die mir natürlicher erscheinende Abarbeitung der Potenzen scheint ja gegen die übliche Konvention zu sein (nicht das ich derlei Ausdrücke ohne Klammern benutzen würde).
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.