Wahrscheinlichkeitsrechnung und Physik - Simulation

Tom Berger <[Only registered users see links. ]> writes:


Daran vermag ich nicht zu glauben. Man nehme ein Perlscript das die
'>' durch eine ')' ersetzt und solange um eine weitere Klammer
ergänzt, bis der Syntaxchecker keinen Fehler mehr auswirft.

Das mag nicht dann nicht das Programm sein, das man haben wollte, aber
das ist ja bei solchen Dingen nichts ungewöhnliches.

--
Space - The final frontier

On Sat, 18 Feb 2006 22:36:11 +0100, Tom Berger wrote:


Versuchs erst gar nicht heute, das I-Wort wird mir
nicht über die Lippen fahren Aber vielleicht
tuts ja auch das:

[Only registered users see links. ]


...............
/ begin quoting

8. Die syntaktische�Superklammer“:

ist ein Block mit einer Marke A (label) versehen, soschließt die Anweisung
END A alle in der Zwischenzeit außerdem noch geoffneten Blocke.Hoare (1973)
bemerkt dazu:Als Beispiel dafur, was passiert, wenn eine Sprache von der am
besten bekannten Technikabweicht, namlich derjenigen der kontextfreien
Syntax, betrachte den Fall des markierten END.Das ist eine Konvention in
PL/I, wodurch ein Bezeichner zwischen END und dem Semikolonautomatisch das
Ende der Prozedur mit diesem Namen signalisiert und das jeder
eingeschlosse-nen Programmstruktur, auch wenn diese kein eigenes END hat.
Zuerst sieht das wie eine harm-lose notationelle Erleichterung aus, die
Peter Landin vielleicht�syntaktischen Zucker“ nennenwurde, aber in der
Praxis sind die Folgen verheerend. Wenn der Programmierer zufallig
irgend-wo im Programm ein END vergißt, dann wird es automatisch und ohne
Warnung genau vor demnachsten markierten END eingefugt, was hochst
unwahrscheinlich die Stelle ist, wo es erwunschtwar. Landins Bezeichnung
dafur ware�syntaktisches Rattengift“. Weise Programmierer habendeshalb
gelernt, das markierte END ganz zu vermeiden, was eigentlich schade ist,
denn wenndas markierte END nur dazu verwendet worden ware, um die korrekte
Schachtelung von Anwei-sungen zu prufen, dann ware das sehr nutzlich
gewesen und hatte eine fruhere und sauberereBeseitigung von Fehlern erlaubt
und ware trotzdem innerhalb der Disziplin der kontextfreienSprachen
geblieben. Dies ist ein klassisches Beispiel fur eine Vorrichtung, die
Gefahr fur denProgrammierer mit Schwierigkeiten fur den Implementierer
verbindet.Jean Sammet (1969), die selbst bei IBM beschaftigt war, windet
sich wie ein Aal in dem Be-streben, negative Eigenschaften von PL/I mit
positiven zu kompensieren:Sie [die Sprache] ist nicht sonderlich konsistent
in dem Sinne, daß es eine große Zahl von Spezi-alfallen und Ausnahmen gibt.
Sie ist nicht sonderlich effizient zu implementieren wegen ihrer Großeund
der Tatsache, daß gute Implementierungstechniken hinter der Entwicklung von
Sprachen dieserKomplexitat zuruckgeblieben sind. Sie ist ziemlich leicht zu
lesen und schreiben, mit keiner großen Ten-denz zu fehlertrachtiger
Verwendung, abgesehen von Fehlern aufgrund ihrer Starke und Komplexitat.Zur
Beurteilung der Leichtigkeit ihres Erlernens muß man den zu lehrenden
Umfang und die Erfah-rung des Lernenden spezifizieren. Eine Person ohne
jede Erfahrung in einer Programmiersprache wirdes sehr schwer finden, das
ganze PL/I zu lernen. Andererseits wird ein FORTRAN-Programmierer esleicht
finden, die Teilmenge von PL/I zu lernen, die zu den Fahigkeiten von
FORTRANaquivalent ist.[...]Es gibt relativ wenige Konzepte, die fur diese
konzeptuelle Linie von Sprachen relevant sind, dienicht schon in PL/I
enthalten sind oder nicht mogliche oder offensichtliche Erweiterungen davon
sind.[...]Weil (und obwohl) PL/I eine so machtige Sprache ist, gibt es fur
jedermann eine große Tendenz,darin Moglichkeiten einbauen zu wollen fur
Gebiete, die anfangs nicht eingeschlossen waren.Das wird auch von E. W.
Dijkstra (1987) kritisch kommentiert, der sagt:PL/I zu verwenden ist wie
ein Flugzeug zu fliegen, das 7000 Knopfe, Schalter und Hebel im Cock-pit zu
bedienen hat. Ich kann absolut nicht einsehen, wie wir unsere wachsenden
Programme fest inunserem intellektuellen Griff halten konnen, wenn durch
ihre schiere Barockheit schon die Program-miersprache — unser grundlegendes
Werkzeug, nicht zu vergessen! — unserer intellektuellen Kon-trolle
entkommt. Und wenn ich den Einfluß beschreiben soll, den PL/I auf seine
Benutzer haben kann,dann ist die nachste Metapher, die mir einfallt, die
einer Droge. Ich erinnere mich an eine Tagung uber hohere
Programmiersprachen und einen Vortrag zur Verteidigung von PL/I durch einen
Mann,der sich selbst als einen ergebenen Benutzer der Sprache beschrieb.
Aber innerhalb eines einstundigenVortrags schaffte er es, die Zufugung von
rund 50 neuen�features“ zu verlangen, ohne zu merken, daßdie Hauptursache
seiner Probleme sehr gut die sein konnte, daß die Sprache schon viel zu
viele die-ser�features“ besaß. Der Vortragende zeigte alle deprimierenden
Symptome der Sucht, wie er so aufeinen Zustand geistigen Stillstands
reduziert war, in dem er nur noch nach mehr, mehr, mehr
verlangenkonnte...D.6 APLAPL ist eine Programmiersprache, die sich zunachst
einmal dadurch auszeichnet, daß sie einenganz eigenen Zeichensatz von mehr
oder weniger hieroglyphenartigen Operatoren verwen-det. Fur die
Anbieterfirma (IBM) hatte das zunachst einmal den Vorteil, daß sich eigene
APL-Terminals verkaufen ließen. Die Programme werden allerdings sehr schwer
lesbar und durchdie eingebauten Matrixoperationen und die einbuchstabigen
Spezial-Operatoren in der Regelsehr kurz, haufig gar einzeilig. Es fehlt
dabei praktisch jede Art von Redundanz, die sich sonstzur Aufdeckung von
Fehlern eignen wurde; jeder binare Operator ist außerdem gleichzeitigein
einstelliger Operator, wahrend dies in der Mathematik praktisch nur fur das
Minuszeichengilt. So bedeutet etwa x÷ ydie Division von x durch y; wird
aber das x versehentlich wegge-lassen, so ist dies kein Fehler,
sondern÷ybezeichnet einfach den Kehrwert von y.Dijkstra (1987) sagt:Im Fall
einer wohlbekannten Dialog-Programmiersprache ist mir von verschiedenen
Seiten erzahltworden, daß, sobald eine Programmiergemeinde mit einem
Terminal dafur ausgerustet ist, ein spe-zifisches Phanomen eintritt, das
sogar einen etablierten Namen hat: Die�One-liners“. Es nimmt einevon zwei
verschiedenen Formen an: Ein Programmierer schreibt ein einzeiliges
Programm und legt esauf den Schreibtisch eines anderen, und entweder
erzahlt er stolz, was es tut, und fugt die Frage an:�Kannst du das mit
weniger Symbolen schreiben?– als ob das von irgendeiner konzeptuellen
Bedeu-tung ware! — oder er sagt einfach:�Rat mal, was es tut!“ Aus dieser
Beobachtung mussen wir schließen,daß diese Sprache als Werkzeug eine offene
Einladung fur clevere Tricks ist; und wenn auch gerade diesdie Erklarung
fur einen Teil ihrer Attraktivitat sein mag, namlich fur diejenigen, die
gerne zeigen, wieclever sie sind, tut es mir leid, sagen zu mussen, daß ich
das als eine der verdammungswurdigstenSachen betrachte, die sichuber eine
Programmiersprache sagen lassen.Siehe auch (Ghezzi und Jazayeri 1987, sec.
7.4.2.4), wo ein One-liner fur die Primzahlen zwi-schen 1 und N abgeleitet
wird.Copyright © Herbert Klaeren

/ end quoting
...............


Tatsächlich...

feierlicher <g> Gruss

--
'Bachs Unvollendete' heisst BWV 562

Am Sat, 18 Feb 2006 22:48:47 +0100 schrieb Oliver Jennrich:


Du wirst damit lediglich die korrekte Anzahl von Klammern setzen können -
die Syntax ist damit aber noch lange nicht fehlerfrei :-)


Eben. Das ist dasselbe wie das wahllose Setzen von Klammern in
mathematischen Formeln.

Es mag dem Lisp-Unerfahrenen vielleicht merkwürdig vorkommen, aber
tatsächlich spielen Klammerfehler bei der Entwicklung von LISP-Programmen
absolut keine Rolle. Ganz im Gegenteil helfen die Klammern zusammen mit
entsprechender Formatierung, die Übersicht zu behalten.

Ich kenne eine ganze Menge Programmiersprachen, und LISP ist sicher nicht
nur die eleganteste Sprache, sondern auch die, deren Programme man meist
ohne jeden Kommentar sofort verstehen kann, und in der man Programme am
schnellsten schreibt.

Tom Berger

--
CAD ahoi - LISP, AutoLISP und VisualLISP Seminare
für AutoCAD (TM), AutoCAD LT (TM) und IntelliCAD
in Ihrer Nähe: Wien, München, Dresden, Berlin, Köln, Stuttgart ...
2 Tage nur 128 Euro - mehr unter [Only registered users see links. ]

Am Sat, 18 Feb 2006 22:52:14 +0100 schrieb Rudi Menter:


Ich vermute, Du hast den von Dir zitierten Text gar nicht gelesen. Ich aber
schon :-)


Oha. 'tschuldigung, Du hast ihn wohl doch gelesen und Deinen Irrtum erst
recht spät erkannt. Lustigerweise ist die einzige andere Fundstelle von
Google eine Antwort von Dir auf einen Beitrag von mir hier, in dem Du das
schon mal behauptet hast :-)

Tom Berger

--
ArchTools: Architektur-Werkzeuge für AutoCAD (TM)
ArchDIM - Architekturbemaßung und Höhenkoten
ArchAREA - Flächenermittlung und Raumbuch nach DIN 277
Info und Demo unter [Only registered users see links. ]

On Sat, 18 Feb 2006 23:26:24 +0100, Tom Berger wrote:


Eben, in diesem Sinne ist die Superklammer eben
k e i n Teufelszeug, sondern nur eine weitere Art
Turingmaschine, wie alles ander auch?


Finde ich auch, aber das war lange her...

gruss
--
(1) 'Bachs Unvollendete' heisst BWV 562
(2) Bach komponiert freien Willen (Norbert Dragon in de.sci.physik)

On Sat, 18 Feb 2006 23:31:34 +0100, Tom Berger wrote:


Ach Tommy, wir sind ja im Prinzip einig...
--

Hendrik van Hees wrote:
Sicher nicht nur weil es so viel alten Code wiederzuverwenden gibt.
Der Sprachumfang ist deutlich kleiner und die Sprache leichter
zu erlernen. Die Flexibilit"at ist gegen"uber C ebenfalls deutlich
kleiner, was die Programmierung m.E. 'sicherer' macht.

warum nicht? Meine ersten Programme habe ich f"ur eine Parsytech
und f"ur eine Fujitsu S600 geschrieben. Da sagten alle, dass
Fortran Asbach ist und es mittelfristig stirbt. Heute werden die
Rechenkerne der meisten Simulationsprogramme immer noch in
Fortran geschrieben. Mit neueren Maschinen kamen einfach keine
besseren C und C++ Compiler und die angepassten Fortran Compiler
sind einfach da.

Nein, leider nicht. Ausserdem wird sehr viel Optimierarbeit auf
den Programmierer abgew"alzt. Schon alleine der unterschiedliche
Funktions/Subroutine Aufruf kann eine Performance-Falle sein.
Wegen der Flexibilit"at die C bietet, kann die vom Compiler
durchgef"uhrte Optimierung auch nicht so effizient sein wie
in Fortran. Man kann in Fortran recht schlampig (Performance
technisch gesehen) schreiben und dann mit einem -O3 alles wieder
richten. In C ist ein -O3 noch lange keine Garantie f"ur ein
schnelles Programm.

Sehr finster, aber auch sehr elegant und wiederverwendbar (wenn
der Code nicht von ehemaligen C oder Fortran Programmierern
stammt).

Allgemein liegt die Entwicklungszeit f"ur einen optimierenden
Fortran Compiler weit unter der Lebenszeit der CPU f"ur die er
gebaut wurde. Wie lange haben dagen alle auf einen entsprechenden
C bzw. C++ Compiler gewartet?

Basic ist eine prima Grundlage, um Programmieren zu lernen
(vom H"orensagen). Ich hab' mit F77 angefangen, bin jetzt bei
C/C++ und freu mich jedes mal, wenn mich jemand bittet in
Fortran zu Schreiben.

Viele Gr"usse, H. W.

Hans Wurst wrote:


Bei mir ist es in erster Linie Faulheit und mangelnde Notwendigkeit,
etwas neues zu lernen. Die umfangreichen frei verfügbaren
Numerikbibliotheken sind nur ein Teil, und meine Programmieraufgaben
sind relativ bescheiden. Man muß halt mal Integrale ausrechnen,
nichtlineare Integralgleichungen aufiterieren oder einen Langevinprozeß
simulieren, aber das sind keine Riesencodes, für die es sich lohnte,
etwas moderneres zu erlernen.


Ich habe mit BASIC angefangen, weil das beim C64 einfach dabei war.
Programmiertechnisch ist das von Fortran ja so verschieden nicht, wenn
ich mich recht entsinne. In der Schule gab's dann
"Informatikunterricht", wo wir den Lehrern beigebracht haben, wie man
programmiert. Das mußten wir in Pascal tun. Spielt das eigentlich
irgendwo noch eine Rolle? Ich habe das als ziemlich qualvoll unflexibel
in Erinnerung, und schneller als BASIC war's trotz Compiler vs.
Interpreter auch nicht.

--
Hendrik van Hees Texas A&M University
Phone: +1 979/845-1411 Cyclotron Institute, MS-3366
Fax: +1 979/845-1899 College Station, TX 77843-3366
[Only registered users see links. ] mailto:[Only registered users see links. ].edu

On Sat, 18 Feb 2006 18:17:50 -0600, Hendrik van Hees wrote:



Hihi...


Naja, der 64 war eine vollständige Maschine, mit
unabänderlichen "Routinen", die natürlich alle in
Maschine waren (wahrhaftig intern gewissermassen),
aber durch alles, Lisp, Basic, oder sonstwas
abbildbar waren, sonst nichts, alles war auf
dem ROM im Gerät eingebrannt und man konnte nur
Bilder in Form von Dualzahlen an die Eingänge
des x65 anlegen. Das wiederum hat durchaus
funktioniert, ich denke nur an das Spiel
Scramble System, oder an dieses wahrhaftige
3D-Spiel ZAXXON (exon), meine Herren und ladies
sowie gentlemen...

Naja, lassen wir das eben besser wieder

Bitte langsam tippen, bin Beamter...
-----
'Bachs Unvollendete' heisst BWV 562
Bach komponiert freien Willen
(Norbert Dragon in de.sci.physik)

Hendrik van Hees wrote:
Genauso ist es. Ein Navier-Stokes L"oser, eine einfache
Monte-Carlo Demonstration oder ein Gitter-Gas Automat sind
bescheidene Programmieraufgaben. Zumindest wenn es darum
geht, zu demonstrieren (wie bei mir der Fall), dass ein
neues numerisches Verfahren funktioniert oder mal im
Projektrahmen ein Problem zu l"osen, das mit
Standartl"osern nicht zu haben ist. Ich sehe die Verwendung
von Programmiersprachen (und Betriebssystemen) sehr
Pragmatisch, so dass hier der Sch"uller die Sprache
verwenden sollte, die er gerade beherscht.
Ich bin schon froh, wenn mir Studenten begegnen, die
"uberhaupt eine Vorstellung davon haben, wie ein numerisches
Verfahren in Pseudo-Code umzusetzen ist. Wenn das geht, kann
man anschliessend beliebige Sprachen verwenden - was halt
gerade angemessen oder oportun ist.

Gr"usse, H.W.