Syntxdiagramm der Arithmetischen Schreibweise

[Tom]

Hello,

könnt Ihr mir weiterhelfen, das Syntaxdiagramm der Arithmetischen Schreibweise zu finden oder wenigstens sagen, ob diese Art der Schreibweise zulässig ist:

[13+10*(17.2+2.1*(4--101))*-{(22+7*-30-2^4)+3}-2]/12 = x

Mir geht es hier im Wesentlichen um die Minuszeichen als Vorzeichen. Müssen die extra geklammert werden, odr darf man sie einfach so einfügen (wie z.B. bei (4--101) )?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

Mir geht es hier im Wesentlichen um die Minuszeichen als Vorzeichen. Müssen die extra geklammert werden, odr darf man sie einfach so einfügen (wie z.B. bei (4--101) )?

zwei Rechenzeichen dürfen sich bei Infixnotation nicht direkt berühren, also (4-(-101)) wäre richtig.

mfg
Woodfighter

[Tom]

Hello,

Mir geht es hier im Wesentlichen um die Minuszeichen als Vorzeichen. Müssen die extra geklammert werden, odr darf man sie einfach so einfügen (wie z.B. bei (4--101) )?

zwei Rechenzeichen dürfen sich bei Infixnotation nicht direkt berühren, also (4-(-101)) wäre richtig.

Danke.
Das macht das Auswerten eines Strings mit der rechenanweisung ja schon einfacher.
Bevor ich nur "Recher, die Vierte" starte, wollte ich das doch wenigstens nochmal wissen.

Nun nach Pascal, Java und CSharp also nun in C/C++...

Dabei fällt mir wieder ein:
---------------------------

Fragt sich jetzt, ob sich da eine Berechtigung für die Objektorientierung finden lässt, oder ob das Programm dann in klassischer Programmierung schneller ist.

Allerdings müsste man dann ja auch Streams herauslassen und alles mit alten char- oder Stringfunktionen lösen oder sich eben eigene erstellen.

Leider ist C schon eine Bastelsprache, die viele Dinge wegen "Kompatibilität mit vielen Plattformen" (vornehmleich leider solchen, die es fast gar nicht mehr gibt), einfach weglässt. Leider lassen sich diese Dinge in höhern Schichten dann nur noch sehr umständlich oder gar nicht mehr sauber implementieren.

Ich bin mir daher nicht mehr sicher, ob ich auf die mNn oft falsch eingesetzte OOP oder auf deren wesentliche Basis in der heutigen Programmwelt, nämlich C/C++, herumhacken soll.

Das Rennen ist für meine eigene Meinungsbildung noch lange nicht entschieden.

Eine übertriebene Plattformferne scheint also die Ursache für die Leistungsdefizite von OOP zu sein.  Wenn es vernünftige (optionale) Libraries geben würde für die unterschiedlichen Plattformen, könnten die meisten Programme vermutlich 3 bis 10mal so schnell sein.

Wenn ich die Aussagen von Bjarne Stroustrup in Interviews richtig verstehe, würde er bei einem Redesign von C/C++ soviel ändern wollen, dass leider viele bestehende Programme mit der dann entstehenden Sprache nicht mehr gepflegt werden könnten. Aber müssen sie das denn?

Wenn nun ein C++0x das letzte Glied in der Kette der stetigen C-Entwicklungen wäre und sich langsam ein Sprung auf ein C² (C-Quadrat) herausbilden würde, als vollkommen neue Sprache, die auch die Leistungsstärken unterschiedlicher Plattformen berücksichtigte, dann fände ich das nach über 40 Jahren angemessen. Man könnte ja auch durch partielle Cross-Compiler bzw. Transformatoren dafür sorgen, dass abgesicherte Code Teile übernommen werden können (die Plattformen werden wegen einer neuen Sprache ja nicht ausgetauscht) und fehlende, nicht übertragbare Elemente, kenntlich gemacht werden, dann wäre die Portierung in eine neue, durch optionalen aber optimalen Plattformbezug wesentlich schnelleren Sprache, leicht gemacht. Es muss ja nicht Alles auf Allem laufen!

Man müste sicherlich ein paar Informatiker einstellen dafür, aber es gibt ja genug. Und die Programmwelt einmal zu durchforsten, auszurümpeln, aber auch vergessene Glanzstücke wieder aufleben zu lassen und auf einen moderen, bugarmen Stand zu bringen, wäre doch einen Zehnjahresplan unseres Staates wert.

Ich bin dafür, dass man die Dinge so benutzt, wie sie zusammen passen. Ich bin auch gegen Schnittstellen sondern für definierte Verbindungsstellen.

tbc

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

Das macht das Auswerten eines Strings mit der rechenanweisung ja schon einfacher.

wenn ich es einfach haben wollte, würde ich eine polnische Notation voraussetzen, Infix hat einfach zu viele komplizierte Regeln um einen String vernünftig parsen zu können.

mfg
Woodfighter

[Tom]

Hello,

Das macht das Auswerten eines Strings mit der rechenanweisung ja schon einfacher.

wenn ich es einfach haben wollte, würde ich eine polnische Notation voraussetzen, Infix hat einfach zu viele komplizierte Regeln um einen String vernünftig parsen zu können.

Das mit dem Umbau auf polnische Notation sollte gerade vermieden werden.

Welche Schwierigkeiten, außer Fakultät, sind denn noch zu erwarten, wenn nicht noch solche Dinge, wie sin(), cos(), usw. eingebaut werden?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

Welche Schwierigkeiten, außer Fakultät, sind denn noch zu erwarten, wenn nicht noch solche Dinge, wie sin(), cos(), usw. eingebaut werden?

allein das Parsen von Potenzen (von rechts nach links), Punkt vor Strichrechnung, Punkt bzw. Strichrechnung wird natürlich von links nach rechts geparst, ist schon widersprüchlich genug.

mfg
Woodfighter

[Tom]

Hello,

Welche Schwierigkeiten, außer Fakultät, sind denn noch zu erwarten, wenn nicht noch solche Dinge, wie sin(), cos(), usw. eingebaut werden?

allein das Parsen von Potenzen (von rechts nach links), Punkt vor Strichrechnung, Punkt bzw. Strichrechnung wird natürlich von links nach rechts geparst, ist schon widersprüchlich genug.

Jau, das habe ich gemerkt.
Es wurden erst die Klammern isoliert
Das war noch sehr einfach.
Nun werden die verbleibenden Ausdrücke in den Klammern aufgelöst.
Dazu müssen sie erst in Tokens aufgeteilt werden. Das geht mit Stream sehr bequem, aber ich glaube, dass es sehr teuer ist.
Di Tokens werden dann abgecannt und nach bestimmten Regeln zu Ojekten mit

grob:
  - Ausdruck        // zur Kontrolle
  - minusflag
  - Operator
  - leftOperand
  - rightOperand

zusammengesetzt, deren Operanden dann solange weiter zerlegt werden, bis es nicht weiter geht.
Es wird mit dem niedrigsten Operator begonnen, sodass der hächste nachher auf dem Blatt landet.

Wenn auf einem Zweig keine weitere Zerlegung mehr möglich ist, wird der Baum abgewickelt.

Ob das nun geschickt ist, weiß ich noch nicht. Aber Umbau von Infix zu Postfix sollte vorher nicht erst stattfinden.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Beat]

Welche Schwierigkeiten, außer Fakultät, sind denn noch zu erwarten, wenn nicht noch solche Dinge, wie sin(), cos(), usw. eingebaut werden?

1.25e-3 ?

mfg Beat

[Tom]

Hello,

Welche Schwierigkeiten, außer Fakultät, sind denn noch zu erwarten, wenn nicht noch solche Dinge, wie sin(), cos(), usw. eingebaut werden?

1.25e-3 ?

Ok, 1.25^3 und 1,25^(-3) kann das Ding. Die Notation ist hier noch sehr beschränkt
Man kann die Aufghabe natürlich bis "ich baue mir einen Parser" aufblasen. Aber dann ist es kaum noch in der vorgegebenen Zeit (1 Unterrichtstag) zu schaffen.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Der Martin]

Hi,

1.25e-3 ?
Ok, 1.25^3 und 1,25^(-3) kann das Ding.

das ist aber nicht dasselbe wie 1.25e-3 = 1.25 * 10^-3

Man kann die Aufghabe natürlich bis "ich baue mir einen Parser" aufblasen. Aber dann ist es kaum noch in der vorgegebenen Zeit (1 Unterrichtstag) zu schaffen.

Das kommt drauf an, ob man eine komplette Implementierung durcharbeiten oder nur das Prinzip vermitteln will. Ein Parser für arithmetische Ausdrücke ist nun wirklich nicht schwer zu realisieren; man muss nur den Stack ein bisschen strapazieren und die Rangfolge von Operatoren beachten.

Schönes Wochenende,
 Martin

[Tom]

Hello,

1.25e-3 ?
Ok, 1.25^3 und 1,25^(-3) kann das Ding.

das ist aber nicht dasselbe wie 1.25e-3 = 1.25 * 10^-3

Das ist mir klar.
Aber mit der Syntax 1,25e-3 kann der Parser des Mini-Rechners nichts anfangen .
Er kann nur mit

1.25*10^(-3)

etwas anfangen

Das kommt drauf an, ob man eine komplette Implementierung durcharbeiten oder nur das Prinzip vermitteln will. Ein Parser für arithmetische Ausdrücke ist nun wirklich nicht schwer zu realisieren; man muss nur den Stack ein bisschen strapazieren und die Rangfolge von Operatoren beachten.

Jau, das hatten wir doch schon mal. Solltest Du da Beispiele haben, wär ich dankbar für eine Einblicknahme.

Ich denke, dass es eher um die Einsatzmöglichkeiten von Streams (und die von Baumstrukturen) gehen soll.
Das bedeutet zwar im Hintergund sicherlich dasselbe und ich halte Streams hier für vollkommen oversized, aber meine Meinung zählt da nicht.

Aber ich muss zugeben, dass man die Methoden und Flags von Streams so gut kennenlernen kann.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg