Einfachheit bei der Implementierung/Algorithmus.
Es muß '(3, 4)+' heißen.
Einfachheit bei der Implementierung/Algorithmus.
Es muß '(3, 4)+' heißen.
Axel schrieb von PN nicht RPN!
Und ich muß beides nicht haben. Aber vielleicht bin ich ein völlig untypischer Informatiker, ich finde auch Tex Sche#@!* und kann Linux nicht viel abgewinnen - Masochismus ist nicht meine Welt.
RPN/UPN finde ich sinnvoll.
Operand speichern, Operand speichern, Operation ausführen, Reset, Und erneut, ...
Es waren nicht Taschenrechner, sondern Tischrechner, insbesondere der HP 9100A und seine Nachfahren, die HP auf die RPN-Schiene brachte. Der 9100 hatte *wirklich* enge technische Grenzen: keine ICs, alles mit diskreten Transistoren, Ferritkernspeicher, Bildröhre statt Siebensegmentanzeige. Das ROM war eine ganz eigenständige Lösung, die meines Wissens vorher und nachher nie wieder verwendet wurde: ein mehrlagiges PCB mit serpentinenförmigen Leiterbahnen. Die eine Serpentinenform bedeutete "0", die andere "1", welche Form bei einer bestimmten Koordinate vorlag, konnte induktiv ausgelesen werden.
Unix hatte zuerst dc ("desktop calculator"), mit polnischer Notation. Dann bc mit algebraischer Notation, das war ursprünglich nur ein Frontend, das die algebraische Notation in polnische umwandelte und dc als Backend verwendete.
- Andi
Es sei Dir unbenommen...
Genau. Man müßte natürlich erst einmal die erste Fremdheit überwinden, aber im Prinzip scheint sie mir bei längeren Ausdrücken leichter überblickbar, was u.a. Klammerebenen angeht.
Ich will niemanden missionieren, höchstens überreden, sich selbst ein (nicht zu oberflächliches) Bild zu machen, was Du wohl schon getan hast. Aber für /mich/ ist der Hauptvorteil bei TeX die ergonomischere Eingabe und das Fehlen unsichtbarer Leichen nach mehrfachem Editieren. (Z.B. ein fett geschriebenes Wort ist nach dem Löschen weg, aber der fett-Tag steht unsichtbar noch da.)
Wenn etwas im Druck nicht so aussieht, wie es soll, kann ich die Quelle leicht komplett überblicken und muß nicht in Dutzenden Menüs rumsuchen. Und das ständige Hin und Her zwischen Tastatur und Maus fällt auch weg.
Am 19.08.2019 um 14:44 schrieb Eric Bruecklmeier:
Nur der kleine Geist braucht Ordnung, der große überblickt das Chaos ;-)
An der Uni waren die meisten Studenten hoffnungslos aufgeschmissen, wenn sie mal statt TI einen HP Taschenrechner benutzen sollten. Umgekert ist mir das nie begegnet. Und wer C für eine brauchbare Programmiersprache hält, kann bessere Entwicklungswerkzeuge sowieso nicht mehr verstehen :-(
DoDi
Nein. +(3,4) ist fast Lisp, und (3,4)+ psiL In FORTH einfach 3 4 + .
DoDi
Ich habe aber einen TI59 mit algebraischer Notation.
In meinem Kontext bezog ich mich auf UPN auch nur im Hinblick auf die einfachere Programmierung. Ich mochte UPN nie als Eingabe-Notation per Hand. Kontexte verschwinden fast immer.
Das weiß ich doch. Ich habe die Klammern des Vorposters übernommen. Notwendig sind die bei Eingaben nicht.
Es ist ja auch ein Vorteil der UPN, daß Klammern fast immer entfallen können. So wird (7+8)*9 auch eingegeben: 7 8 + 9 *
Am 19.08.2019 um 17:15 schrieb Helmut Schellong:
Macht sich auf einem 49g für Aufmaße prima:
15 m³ (Beddong) x 135,77 Euro/m³ 48 m² (Schalung) x 77,89 Euro/m² 15^, 135,77^, * 48^, 77,89^, * ... und zum Schluss +,+,+,+Hightech in Germany :-)
Butzo
Axel Berger snipped-for-privacy@berger-odenthal.de:
Der polnische heißt Jan Lukajewiz, er war tätig als Logiker, hat Anfang der
1930er ein aussagenlogisches Kalkül vorgestellt, womit man ohne Abstriche klammerlos notieren kann. Bis in etwa diese Zeit war das Fach der Logik von Fortschrittseifer beseelt, das Modell des J.L. war eigentlich eher eine Fingerübung im Rahmen des damals aufgeflammten Interesses, das Fach der Logik (das ist nicht die Mathematik) ein Stück weiterzubringen.Zu der Zeit, dass dies bei der Rechnerei plötzlich nutzbar gemacht wurde (hier nannte jemand die Maschinen von Burroughs[?] als Avantgarde in dieser Hinsicht, wenn ich mich recht entsinne), war etwas anderes als Spaghetti-Code nicht vorgesehen.
In doch recht kurzer Zeit fand sich die Einsicht, dass mit den Stapeln strukturiert zu programmieren ist, und das war neu für die Zeit (um oder nach 1960).
Das aussagenlogische Kalkül für klammerlose Notation war dann auch nicht in Vergessenheit geraten. Mit dieser Arbeit eröffnet sich auch, dass diese Notation der klassichen Notation um nichts nachsteht. Was man algebraisch hinschreiben will, kann man auch in dieser Notation hinschreiben.
Vor allem war die Einführung der Stacks ein Riesensprung in der Technik, man kann zudem sagen, dass eben die klammerlose Notation zufällig sehr fein mit dem Maschinenelement Stapel harmoniert.
Das sind Menschen, die Code schreiben, und beim Verfolgen der Windungen in einem Spaghettisalat ist der Horizont der etwas gründlicheren Nachvollziehbarkeit rasch an seinen Grenzen. Erst mit dem Stack, und dem Selbstverständnis, dass auch hier das aussagenlogische Kalkül nicht im Hintertreffen steht, konnte das einen paradigmatischen Sprung bewirken, zum viel übersichtlicheren Modell mit den gespeicherten Rückkehradressen.
Dies ebenso die Daten betreffend - so lässt sich der Code reentrant bedienen, wenn die Daten ebenfalls per Stack gehandhabt werden, woran ja vorher niemand dachte.
Nun, in Forth macht man das im direkten Zugriff, was bei den Riesencompilern erst das Resultat der Übersetzung ist, wo ja das Datenhandling im Geiste immer noch und weiterhin mit der Vorstellung von Spaghetti-Code funktioniert, erst die großen Compiler machen daraus eine Übersetzung, wodurch die Daten in die Schachtelung via Stack hineingenommen werden. Die klassische algebraische Notation kennt so etwas wie Reentranz nicht wirklich, mit ihren benannten Speicherplätzen, und als Hilfskonstrukt sind dann die Modelle zur Daten-Kapselung herumgeworfen worden. Braucht man mit Forth nicht.
Was man da hingegen braucht, ist die Disziplin, dieses Medium zum anonymen Datenhandling zu bändigen, Hirnschmalz einbringen, um das Handling möglichst effizient zu ermöglichen. Nun, das ist dann keine industrielle Kategorie mehr, die Programmierer sind damit nicht so locker als Massenvieh herumzutreiben, wenn gewisses delikates Einfühlungsvermögen auf sehr abstrakter Ebene mit von der Partie ist, jenseits der konkreten Algorithmen (und dann auch noch die Disziplin, das so anzustellen und zu dokumentieren, dass man auch noch ein paar Jahre später nochmal Details ändern könnte, wenn man wollte).
Dafür kann man dann exakt am Metall feilen, als da die Notation zugleich direkt die Ausführungen der CPU darstellt. So etwas kennt die Kundschaft der Riesencopiler schon lange nicht mehr.
Nun ja, wie gerade ausgeführt wurde, sind es dann die CPUs selbst, die zum absurden Theater der Übersetzungen zwischen Notationsarten dann das Theater vom Spiel mit Schrödingers Katze hinzufügen. Da wird Code exekutiert, aber welcher wirklich genau, das weiß man dann nicht mehr so genau, nur dass hinten das herauskommen soll, was in Summe angenommen wurde dass es herauskommen möge. Da ist wohl der Dampfer wieder woanders hin.
Am 19.08.2019 um 22:03 schrieb Ewald Pfau:
Ich sehe keinen großen Vorteil beim Programmieren, wenn jedes einzelne FORTH Wort den Stack ändert, womit sich die Offsets aller darin liegenden temporären Variablen ändern. Dummerweise reicht es meist nicht, nur die obersten zwei Elemente des Stacks zu verarbeiten. Da ist es durchaus hilfreich, wenn der Compiler sich um die Adressrechnung kümmert. Spätestens bei 3 ineinander verschachtelten FOR Schleifen möchte ich kein UPN mehr schreiben, und stattdessen lieber auf benannte lokale Variablen zugreifen. Aber wie bereits erwähnt, number chrunching ist ja nicht die Domäne von FORTH.
DoDi
Ein etwas modernerer Rechner wie der jetzt auch schon lange nicht mehr neue von mir geliebte und immer noch verwendete Sharp PC-140n kann ohne Klammer Punkt- vor Strichrechnung:
15*135.77+48*77.89+ ...Und dazu hat er eine sehr lange scrollende Eingabezeile. Ich muß also nicht wie früher jedes Mal alles zur Sicherheit und Kontrolle zweimal komplett eintippen sondern kann nach der ersten Eingabe einmal komplett korrekturlesen.
Genau, der Mensch richtet sich nach der Maschine.
Ja, Das ist mir hierbei vollkommen egal. *Einer* muß sich *einmal* sehr lange und ausgiebig quälen und schwitzen und wenn's dann läuft, haben es tausende jedes Mal einfacher. Das eben ist das Schöne an Programmen.
Jedes Mal neu, statt nur einmal für den (großen, komplexen, aufwendigen) Compiler. Das ist der Unterschied.
Das will ich auch nicht kennen -- zumindest nicht immer und täglich im simplen, wenig anspruchsvollen Alltagsgeschäft. Mein Programmieren kommt über das Skripten von repetitiven Routineaufgaben nicht weit hinaus.
Ausprobiert und für absolut unbrauchbar empfunden. Mir völlig schleierhaft, wie sich jemand freiwillig sowas antun kann.
Am 20.08.19 um 01:42 schrieb Eric Bruecklmeier:
Warum drängt sich Daniel Düsentrieb hier nur so auf? Der bekommt ja Schnappatmung.
"Das beste Werkzeug wird zum Tand in eines tumben Toren Hand"
Wenn man mal in die englische newsgroup sci.electronics.design rüberschielt (gleich nebenan), kann man mitverfolgen, wie Winfield Hill gerade sein neues Buch schreibt. Mit Latex, klaro.
Aber der hat's halt auch drauf; ich werde es sicher kaufen.
Einzelne Kapitel gibt's schon mal vorab, noch nicht ganz fertig als pdf zum Kommentieren.
Gruß, Gerhard
Danke, für mich war RPN samt FORTH eine Offenbahrung, war allerdings schon durch hp16C angefixt :)
Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang
Am 20.08.2019 um 07:32 schrieb Wolfgang Allinger:
Es ist tatsächlich häufig so, daß irgendeine neue Erkenntnis für den einen Richtungsweisend sein kann, während Andere gar nix damit anfangen können. Ging mir z.B. mit ruby und netlogo so. Aber alles keine Gründe persönlich zu werden - zumal wenn man den professionellen Hintergrund des Gegenüber gar nicht kennen kann...
ACK, aber bei den Anwürfen von Johannes ist mir der Kragen geplatzt, muss auch mal sein :)
Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang
Have something to add? Share your thoughts — no account required.
Ask the community — no account required