| Autor |
Nachricht |
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
 TomS Verfasst am: 15. Dez 2020 21:20 Titel: Programmiersprachen für mathematische Anwendungen |
 |
|
Mich würde einfach mal interessieren, welche Sprachen ihr so kennt und verwendet - sowie natürlich eure Erfahrungen.
Ausgangspunkt für mich war C: schnell, unsicher, und in den 80igern gab's noch keine große Lib für Mathematik; komplexe Zahlen, Vektoren ... musste man vollständig selbst programmieren.
An der Uni dann FORTRAN wg. diverser Bibliotheken und natürlich den Atlasten (*) Immerhin konnte man damit vernünftige Dinge berechnen, z.B. die elektromagnetischen Formfaktoren von Nukleonen ...
Mit Computeralgebra bzw. symbolische Mathematik al la Mathematica, Maple usw. hat sich damals noch kaum jemand befasst; heute ist das nicht mehr wegzudenken.
Da ich jedoch seit ca. 20 Jahren viel mit Software-Entwicklung im industriellen Umfeld zu tun habe (C, C++, C#, Ada, Java) war mir eine zu spezialisierte Programmiersprache eh' nicht so sympathisch. Auf der Suche nach einer universellen Programmiersprache mit dennoch starkem Fokus auf Mathematik bin ich dann über Python und einem kurzen Blick auf R bei Julia gelandet, was sowohl Mathematik als auch moderne Softwarekonzepte verbindet.
https://en.wikipedia.org/wiki/Julia_(programming_language)
https://julialang.org/
https://julialang.org/benchmarks/
Über Weihnachten hab' ich Zeit ...
(*)
Echte Programmierer meiden PASCAL
Vor langer Zeit, in der goldenen Aera der Computer, war es noch
einfach, die Maenner von den Memmen zu trennen (mitunter auch ``Echte
Maenner'' und ``Muesli-Fresser'' genannt). Echte Maenner programmierten
Computer, und Muesli-Fresser liessen es bleiben. Ein echter Computer-
Programmierer sagte Dinge wie ``DO 10 I=0,10'' oder ``ABEND'', und der Rest
der Welt quengelte ``Computer sind mir zu kompliziert'' oder ``Ich kann zu
Computern keine gefuehlsmaessige Bindung aufbauen - sie sind zu
unpersoenlich''. Dabei zeigt schon Remy Eyssen's Buch ``Echte Maenner
moegen kein Muesli'' (Heine TB 6290), dass echte Maenner zu nichts und
niemandem eine ``gefuehlsmaessige Bindung'' aufbauen, und dass sie auch
keine Angst haben, unpersoenlich zu sein.
Aber die Zeiten aendern sich. Heute stehen wir einer Welt gegenueber,
in der kleine alte Damen vollcomputerisierte Mikrowellenherde kaufen
koennen, in der 12 Jahre alte Dreikaesehochs gestandene Maenner bei
ASTEROIDS und PACMAN sattmachen, und in der jeder seinen eigenen
Heimcomputer kaufen und sogar verstehen kann. Der Echte Programmierer
ist gefaehrdet, von Studenten mit einem igITT 2020 (deutsche Version
des ABFALL II, A.d.Ue.) im Gepaeck ersetzt zu werden!
Es gibt allerdings einige Unterschiede zwischen dem typischen PACMAN-
spielenden Gymnasiasten und einem Echten Programmierer. Die Kenntnis
dieser Unterschiede wird den Heranwachsenden ein Ziel geben, nach dem
sie streben koennen - ein Vorbild, eine Vaterfigur. Ausserdem schuetzt
sie die Echten Programmierer vor der Arbeitslosigkeit.
Der einfachste Weg, um einen Echten Programmierer zu erkennen, fuehrt
ueber die von ihm benutzte Programmiersprache. Echte Programmierer
benutzen FORTRAN. Muesli-Fresser benutzen Pascal. Niklaus Wirth, der
Schoepfer von Pascal, wurde einmal gefragt, wie man seinen Namen
ausspreche. ``You can either call me by name, pronouncing it 'Veert', or
call me by value, 'worth''', antwortete er. Diese Bemerkung zeigt
sofort, dass Wirth ein Muesli-Fresser ist. Der einzige
Parameteruebergabemechanismus, den Echte Programmierer akzeptieren, ist
call-by-value-return (call-by-result, A.d.Ue.), wie er in den IBM/370
Fortran-G und -H-Compilern implementiert ist. Echte Programmierer
brauchen schliesslich keine abstrakten Konzepte; sie sind vollkommen
gluecklich mit einem Lochkartenstanzer, einem Fortran-IV-Compiler und
einem Bier. Echte Programmierer erledigen Listenverarbeitung,
Zeichenketten-Manipulationen, Abrechnungswesen (wenn ueberhaupt) und
kuenstliche Intelligenz in FORTRAN. Was sie mit FORTRAN nicht machen
koennen, machen sie mit Assembler; was sie mit Assembler nicht machen
koennen, lassen sie veraechtlich liegen.
Akademische Computerspezialisten sind in den letzten Jahren aufs
Abstellgleis der strukturierten Programmierung geraten. Sie behaupten,
dass Programme verstaendlicher werden, wenn bestimmte Sprachkonstrukte
und Programmiertechniken benutzt werden. Sie koennen sich natuerlich
nicht einigen, welche Konstrukte am besten geeignet sind, und die
Beispiele, an denen sie ihren speziellen Standpunkt aufzeigen wollen,
passen ausnahmslos auf eine einzige Seite irgendeines obskuren
Journales. Als ich aus der Schule kam, dachte ich, ich sei der beste
Programmierer der Welt. Ich konnte ein unschlagbares TIC-TAC-TOE-Spiel
schreiben, beherrschte 5 verschiedene Programmiersprachen und schrieb
fehlerfreie 1000-Zeilen-Programme. Dann kam ich in die Wirklichkeit.
Meine erste Aufgabe bestand darin, ein 200000-Zeilen-FORTRAN-Programm
zu lesen, zu verstehen und um den Faktor 2 zu beschleunigen. Jeder
Echte Programmierer wird einem versichern, dass die gesamte
strukturierte Programmierung der Welt in einem solchen Fall nicht hilft
- hier braucht man wirklich Talent.
Einige Beobachtungen zum Thema ``Echte Programmierer und strukturierte
Programmierung'':
* Echte Programmierer haben keine Angst vor GOTOs.
* Echte Programmierer schreiben 5 Seiten lange DO-Schleifen, ohne
durcheinander zu geraten.
* Echte Programmierer lieben arithmetische IF-Statements (die mit
den 3 Ausgaengen, A.d.Ue.), weil sie den Code interessanter
machen.
* Echte Programmierer schreiben selbstmodifizierende Programme,
speziell wenn sie damit in einer kleinen Schleife 20 Nanosekunden
einsparen koennen.
* Echte Programmierer brauchen keine Kommentare, das Programm ist
selbstdokumentierend.
* Da FORTRAN strukturierte IF-, REPEAT...UNTIL- oder CASE-
Anweisungen nicht kennt, braucht sich der Echte Programmierer
nicht zu sorgen, dass er sie nicht benutzt. Ausserdem kann man
sie noetigenfalls ueber "Assigned GOTOs" (Zuweisung eines Sprung-
labels auf eine Variable, A.d.Ue.) simulieren.
Auch Datenstrukturen waren in der letzten Zeit in der Diskussion.
Abstrakte Datentypen, Records, Pointer, Listen und Zeichenketten sind
in gewissen Kreisen populaer geworden. Wirth, der Muesli-Fresser,
verfasste sogar ein ganzes Buch ("Algorithmen und Datenstrukturen",
Teubner 1975), in dem er behauptete, dass man Programme schreiben
koenne, die auf Datenstrukturen aufbauen, statt es umgekehrt zu machen.
Wie jeder Echte Programmierer weiss, gibt es nur eine wirklich
nuetzliche Datenstruktur, das Array. Zeichenketten, Listen, Records und
Mengen sind allesamt Sonderfaelle von Arrays und koennen auch so
behandelt werden, ohne dadurch die Sprache zu verkomplizieren. Das
Schlimmste an den ganzen schoenen Typen ist ausserdem, dass man sie
deklarieren muss, waehrend Echte Programmiersprachen, wie man weiss,
den Type anhand des ersten Buchstabens eines maximal 6 Zeichen langen
Bezeichners implizit festlegen.
Welches Betriebssystem der Echte Programmierer benutzt? CP/M? Gott
bewahre! Das ist doch im Grunde ein Spielzeug-Betriebssystem. Selbst
kleine alte Damen und Hauptschueler koennen CP/M benutzen und
verstehen.
UNIX ist natuerlich schon viel komplizierter - der typische UNIX-Hacker
weiss nie, wie das PRINT-Kommando diese Woche heisst - aber wenn man es
genau nimmt, ist UNIX auch nur ein verherrlichtes Telespiel. Niemand
arbeitet auf UNIX-Systemen an ernstzunehmenden Dingen - man schickt
kleine Witzchen ueber USENET rund um die Welt, oder schreibt ein neues
Adventure-Spiel oder Forschungsberichte.
Nein, der Echte Programmier benutzt OS/370. Ein guter Programmierer
kann die Beschreibung des Fehlers IJK305I in seinem JCL (Job Control
Language, A.d.Tippers)-Manual finden und verstehen. Ein grossartiger
Programmierer kann JCL schreiben, ohne je das Manual zu sehen. Ein
wahrhaft ausserordentlich guter Programmierer kann Fehler in einem 6-
Megabyte-Hexdump finden, ohne einen Taschenrechner zu benutzen.
OS/370 ist wirklich ein bemerkenswertes Betriebssystem. Mit einem
einzigen falsch plazierten Leerzeichen kann man die gesamte Arbeit
mehrerer Tage zerstoeren, was die Wachsamkeit im Programmierteam
ungemein foerdert. Der beste Weg zum System ist der Kartenstanzer. Zwar
behaupten einige Leute, es gaebe ein Timesharing-System unter OS/370,
aber nach sorgfaeltigen Nachforschungen bin ich zu dem Schluss
gekommen, dass sie sich irren.
Welche Werkzeuge kann ein Echter Programmierer benutzen? Nun,
theoretisch koennte er seine Programme ueber die Maschinenkonsole
eingeben und laufen lassen. In den fruehen Tagen der Computerei, als
Computer noch Maschinenkonsolen hatten, wurde dies auch gelegentlich
getan. Der typische Programmierer wusste den System-Urlader Bit fuer
Bit auswendig und tastete ihn ein, sobald er von seinem Programm
zerstoert worden war. Damals war Speicher auch noch Speicher - der war
nicht einfach leer, wenn der Strom ausfiel. Hauptspeicher von heute
hingegen vergessen entweder Dinge, die sie behalten sollen, oder halten
Informationen, die schon lange weg sein sollten. Aber zurueck zum
Thema. Die Legende sagt, dass Seymour Cray, der Erfinder des Cray-I-
Supercomputers und der meisten anderen Rechner von Control Data, selbst
das erste Betriebssystem fuer die CDC 7600 an der Maschinenkonsole
eingetastet hat, als sie das erste Mal eingeschaltet wurde. Cray ist
selbstverstaendlich ein echter Programmierer.
Einer der Programmierer, die ich am meisten bewundere, arbeitet als
Systemprogrammierer fuer Texas Instruments. Eines Tages erhielt er ein
Ferngespraech von einem Benutzer, dessen System mitten in einer
wichtigen Arbeit abgestuerzt war. Der Typ reparierte dann den Schaden
ueber's Telefon. Er brachte den Benutzer dazu, an der Maschinenkonsole
Disk-I/O-Instruktionen einzutasten, Systemtabellen in Hexadezimal zu
reparieren und Registerinhalte ueber's Telefon durchzugeben. Die Moral
von der Geschichte: Obwohl ein echter Programmierer normalerweise
Kartenlocher und Schnelldrucker benutzt, kommt er im Notfall auch mit
Maschinenkonsole und Telefon aus.
In einigen Firmen besteht die Programmeingabe allerdings nicht mehr aus
10 schlangestehenden Ingenieuren, die auf einen 029-Locher warten. In
meiner Firma zum Beispiel steht kein einziger Kartenlocher. Der Echte
Programmierer muss in diesem Fall seine Arbeit mit einem Texteditor
erledigen. Auf den meisten Rechnern stehen verschiedene Editoren zur
Verfuegung, und der Echte Programmierer muss aufpassen, dass er einen
erwischt, der seinen persoenlichen Stil wiedergibt. Viele Leute
glauben, dass die besten Editoren der Welt im Xerox Palo Alto Research
Center geschrieben wurden und auf Alto- und Dorado-Computern laufen.
Ungluecklicherweise wuerde jedoch kein Echter Programmierer einen
Computer mit einem Betriebssystem benutzen, das Smalltalk (Geplapper,
A.d.Ue.) heisst, und sicherlich auch nicht ueber eine Maus mit einem
Rechner kommunizieren.
Einige Konzepte der Xerox-Editoren sind mittlerweile in Editoren
eingeflossen, die unter sinnvoller benannten Betriebssystemen arbeiten,
so wie EMACS und VI. Das Problem mit diesen Editoren ist, dass Echte
Programmierer das Prinzip "Du kriegst, was du siehst" fuer schlecht
halten. Der Echte Programmierer will einen "Du hast es so gewollt, da
hast du's"-Editor, einen, der kompliziert ist, kryptisch,
leistungsfaehig, gnadenlos und gefaehrlich. TECO, um genau zu sein.
Es wurde beobachtet, dass TECO-Kommandofolgen dem Leitungsrauschen
aehnlicher sind sind als lesbarem Text. Eins der unterhaltsameren
Spiele, die mit TECO moeglich sind, besteht darin, den eigenen Namen
als Kommando einzugeben und zu raten, was dann passiert. So ungefaehr
jeder moegliche Tippfehler kann dank TECO das gerade editierte Programm
zerstoeren, oder schlimmer noch, kann kleine mysterioese Fehler in
einstmals funktionierende Unterprogramme einbringen.
Aus diesem Grund editieren Echte Programmierer nur sehr widerwillig
Programme, die schon fast laufen. Sie finden es viel einfacher, den
binaeren Objektcode direkt zu aendern, fuer gewoehnlich mit einem
wundervollen Programm, das SUPERZAP heisst (auf Nicht-IBM-Rechnern
entsprechend anders). Dies funktioniert so gut, dass viele laufende
Programme auf IBM-Systemen keine Aehnlichkeit mit dem urspruenglichen
FORTRAN-Quellprogramm haben. In einigen Faellen ist nicht einmal mehr
das Quellprogramm vorhanden. Wenn dann der Zeitpunkt gekommen ist, ein
Programm zu aendern, wuerde kein Mananger auch nur daran denken, einem
geringeren als einem Echten Programmierer diese Arbeit zu uebertragen -
kein Muesli-fressender strukturierter Programmierer wuesste auch nur,
wo er mit der Arbeit anfangen sollte. Man nennt das
Arbeitssicherungsmassnahme.
Hier eine Liste der wichtigsten Programmierhilfen, die der Echte
Programmierer nicht benutzt:
* FORTRAN-Praeprozessoren wie MORTRAN oder RATFOR. Diese Haute
Cuisine der Programmierung eignet sich hervorragend, um Muesli zu
produzieren.
* Quellcodeorientierte Debugger. Echte Programmierer lesen Hexdumps.
* Compiler, die Code fuer Array-Indexpruefung zur Laufzeit erzeugen.
Sie ersticken jede Kreativitaet, zerstoeren die meisten der
interessanteren Anwendungen der EQUIVALENCE-Vereinbarung, und
machen Aenderungen des Betriebssystems mittels negativer Indizes
unmoeglich. Und, schlimmer noch, solcher Code ist ineffizient.
* Programm-Pflege-Systeme. Ein Echter Programmierer haelt seine
Software als Kartenstapel unter Verschluss, denn dies zeigt, dass
der Besitzer seine wichtigen Programme nicht unbewacht lassen
kann.
Wo der typische Echte Programmierer arbeitet? Welche Art von Programmen
derart talentierter Individuen wuerdig ist? Nun, man kann sicher sein,
dass man nie einen Echten Programmierer beim Schreiben von
Buchhaltungsprogrammen in COBOL erwischen wird, oder gar beim Sortieren
der Abonnentenadressen des SPIEGEL. Nein, ein echter Programmierer
braucht Aufgaben von weltbewegender Bedeutung.
Echte Programmierer arbeiten fuer das Los Alamos National Laboratory
und schreiben dort Atomkriegs-Simulationen auf Cray-I-Supercomputern,
oder sie arbeiten bei der National Security Agency und entschluesseln
russische Funksprueche. Nur weil tausende Echter Programmierer fuer die
NASA gearbeitet haben, waren "unsere Jungs" eher auf dem Mond als die
Kosmonauten. Die Computer im Space Shuttle wurden von Echten
Programmierern programmiert, und auch die Betriebssysteme der Cruise
Missiles der Firma BOEING wurden von diesen echten Professionals
entworfen.
Einige der ehrfurchtseinfloessendsten Echten Programmierer arbeiten im
Jet Propulsion Laboratory in Kalifornien. Viele von ihnen kennen das
gesamte Betriebssystem der Pioneer- und Voyager-Sonden auswendig. Mit
einer Kombination von grossen, bodengebundenen FORTRAN-Programmen und
kleinen, von den Sonden mitgefuehrten Assembler-Programmen vollbringen
sie unglaubliche Kunststuecke der Navigation und Improvisation. So
treffen sie nur 10 Kilometer grosse Fenster nahe Saturn nach 6 Jahren
Flug durch den Weltraum, oder reparieren bzw. umgehen defekte Sensoren,
Sender oder Batterien. Angeblich soll es einem Echten Programmierer
gelungen sein, in ein paar hundert Byte unbenutzten Speichers innerhalb
der Voyager-Sonde ein Mustererkennungsprogramm zu pressen, das einen
neuen Mond des Jupiters suchte, fand und fotografierte.
Fuer die Galileo-Sonde ist vorgesehen, dass sie auf ihrem Weg zum
Jupiter entlang einer schwerkraftgelenkten Bahn am Mars vorbeizieht.
Diese Bahn fuehrt in einer Entfernung von 80 +/- 3 km an der
Marsoberflaeche vorbei. Kein Mensch wuerde diese Art der Navigation
einem Pascal-Programm oder gar -Programmierer anvertrauen.
Viele der Echten Programmierer dieser Welt arbeiten fuer die
amerikanische Regierung, meist fuer das Verteidigungsministerium. So
soll es sein. In letzter Zeit erscheinen dunkle Wolken am Horizont der
Echten Programmierer. Es scheint, als haetten einige einflussreiche
Muesli-Fresser im Verteidigungsministerium entschieden, dass in Zukunft
alle Verteidigungsprogramme in so einer Art von grosser,
vereinheitlichter Programmiersprache namens ADA geschrieben werden
muessten. Lange Zeit schien es, als laege ADA's Bestimmung im Verstoss
gegen alle Regeln der Echten Programmierung. Es ist eine Sprache mit
Strukturen, Datentypen, strenger Typbindung und Semikolons. Kurz, sie
ist wie geschaffen, um die Kreativitaet des typischen Echten
Programmierers zu verkrueppeln.
Gluecklicherweise hat die jetzt vom DoD (Department of Defense,
A.d.Tippers) ausgewaehlte Sprache noch genuegend interessante
Eigenschaften, um dem Echten Programmierer eine Annaeherung zu
ermoeglichen: Sie ist unglaublich komplex, sie enthaelt Moeglichkeiten,
um mit dem Betriebssystem herumzumachen, und Edgar Dijkstra mag sie
nicht. Dijkstra ist, wie man wissen sollte, der Autor von "GOTOs
Considered Harmful", einem Meilenstein der Programmiermethodologie, der
von Pascal-Programmierern und Muesli-Fressern gleichermassen bewundert
wird. Und ausserdem, ein zu allem entschlossener Echter Programmierer
kann in jeder Sprache FORTRAN-Programme schreiben.
Der Echte Programmierer kann allerdings auch Kompromisse in Bezug auf
seine Prinzipien eingehen und an etwas geringeren Aufgaben als der
Vernichtung des Lebens arbeiten, sofern er dafuer entsprechend bezahlt
wird. Viele Echte Programmierer schreiben z.B. Telespiele fuer Atari,
allerdings spielen sie nicht damit. Ein Echter Programmierer weiss, wie
er die Maschine jedesmal schlagen kann, und damit ist es keine
Herausforderung mehr. Jeder bei Lucas-Film ist ein Echter
Programmierer, denn es waere doch verrueckt, das Geld von 50 Millionen
Star-Wars-Fans auszuschlagen.
Der Anteil der Echten Programmierer im Bereich der Computer Graphics
ist etwas niedriger als anderswo, was wahrscheinlich daran liegt, dass
noch niemand irgendeinen Nutzen der Computer Graphic entdeckt hat.
Andererseits werden Computer Graphics vornehmlich in FORTRAN
abgehandelt, daher gibt es einige Leute, die so das Schreiben von
COBOL-Programmen vermeiden.
Im Allgemeinen spielt der Echte Programmierer, wie er arbeitet - mit
Computern. Er ist staendig darueber erheitert, dass sein Arbeitgeber
ihn tatsaechlich fuer etwas bezahlt, was er nur so zum Spass ebenso tun
wuerde - allerdings achtet er darauf, diese Meinung nicht zu laut zu
aeussern. Gelegentlich kommt der Echte Programmierer auch aus seinem
Buero heraus, um sich ein wenig frische Luft und ein oder zwei Bierchen
zu genehmigen. Hier daher einige Hinweise, wie man den Echten
Programmierer ausserhalb des Computerraums erkennt:
* Auf Parties stehen Echte Programmierer in einer Ecke und
diskutieren ueber Sicherheitsmechanismen von Betriebssystemen und
wie man darum herumprogrammiert.
* Bei Fussballspielen vergleicht der Echte Programmierer die
Ergebnisse mit seinen auf gruenliniertem Leporello-Papier
gedruckten Computer-Simulationsergebnissen.
* Am Strand zeichnet der Echte Programmierer Flussdiagramme in den
Sand.
* Ein Echter Programmierer geht in die Disco, um sich die Lichtorgel
anzusehen.
* Bei Begraebnissen sagt der Echte Programmierer typischerweise
"Armer Hans-Helmut. Er war mit seinem Sortierprogramm schon fast
fertig, als ihn der Herzinfarkt erwischt hat".
* Im Supermarkt besteht der Echte Programmierer darauf, seine
Bierdosen selber ueber das Fenster des Strichcodelesers zu
schieben, weil er keinem Kassierer zutraut, dies beim ersten
Versuch richtig zu machen.
In welcher Umgebung der Echte Programmierer am besten funktioniert?
Nun, dies ist eine sehr wichtige Frage fuer die Manager von Echten
Programmierern. Wenn man bedenkt, wie teuer es ist, einen von ihnen in
Betrieb zu halten, dann sollte man ihn oder sie in eine optimale
Arbeitsumgebung versetzen.
Der typische Echte Programmierer lebt vor einem Computerterminal. Rund
um dieses Terminal liegen Ausdrucke von jedem Programm, an dem er je
gearbeitet hat, sie stapeln sich grob chronologisch geordnet auf jeder
ebenen Flaeche des Bueros. Im Zimmer verteilt finden sich ueber ein
Dutzend mit kaltem Kaffee mehr oder minder gefuellte Tassen.
Gelegentlich schwimmen Zigarettenkippen darin herum, in einigen Faellen
auch Reste von Orangenschalen. Irgendwo liegen Kopien des OS JCL
Manuals und der "Principles of Operation" an einer besonders
interessanten Stelle aufgeschlagen herum, ausser bei extrem guten
Leuten. An der Wand klebt ein Schnelldrucker-Kalender mit Snoopy drauf
aus dem Jahre 1969. Ueber den Boden verteilt liegen Reste der
Verpackungen von gefuellten Keksen (der Typ, der schon in der Fabrik so
furztrocken gebacken wird, dass er auch bei laengerem Liegen im
Automaten nicht schlechter wird). Schliesslich, in der linken, oberen
Schublade des Schreibtischs, unter der Schachtel mit den Muntermachern,
liegt eine Schablone fuer Flussdiagramme, die sein Vorgaenger dort
vergessen hat. Echte Programmierer schreiben Programme und keine
Dokumentation, das ueberlaesst man den Typen von der Wartung.
Der Echte Programmierer ist in der Lage, 30, 40, ja sogar 50 Stunden in
einem Rutsch zu arbeiten, und das unter hohem Zeitdruck. Genaugenommen
mag er es so am liebsten. Schlechte Antwortzeiten regen den Echte
Programmierer nicht auf - sie geben ihm eine Chance, zwischen zwei
Kommandos ein bisschen Schlaf zu ergattern. Wenn die Planung nicht
genuegend Zeitdruck bereithaelt, dann tendiert der Echte Programmierer
dazu, seine Arbeit herausfordernder zu machen, indem er sich die ersten
neun Wochen mit einem kleinen, aber sehr interessanten Teil des
Problems befasst, um dann in der letzten Woche seine Aufgabe in zwei
oder drei 50-Stunden-Marathonsitzungen zu beenden. Dies beeindruckt
nicht nur den Manager, sondern schafft gleichzeitig eine hervorragende
Entschuldigung fuer das Fehlen der Dokumentation. Und ueberhaupt: Kein
Echter Programmierer arbeitet von 9 bis 5, ausser denen von der
Nachtschicht. Echte Programmierer tragen keine Schlipse. Echte
Programmierer tragen keine hochhackigen Schuhe. Echte Programmierer
kommen zur Arbeit, wenn andere zum Mittagessen gehen. Ein Echter
Programmierer vergisst vielleicht den Vornamen seiner Angetrauten, aber
niemals den Inhalt der gesamten ASCII- (bzw. EBCDIC-) Tabelle. Echte
Programmierer koennen nicht kochen. Da Supermaerkte um 3 Uhr morgens
selten geoeffnet haben, muessen sie sowieso von Kaffee und Keksen
leben.
Die Zukunft betrachtend machen sich eine Reihe von Echten
Programmierern Sorgen, dass die juengste Programmierergeneration nicht
mehr mit der gleichen Lebensperspektive aufwaechst wie sie selbst.
Viele der Juengeren haben noch nie einen Computer mit Maschinenkonsole
gesehen. Kaum ein Schulabgaenger kann heute noch hexadezimal rechnen,
ohne einen Taschenrechner zu benutzen. Die Studenten von heute sind
weich - geschuetzt vor den Realitaeten der Programmierung durch
symbolische Debugger, Texteditoren, die Klammern zaehlen, und
benutzerfreundliche Betriebssysteme. Und das schlimmste ist, einige
dieser angeblichen Computer-Spezialisten kommen zu Rang und Namen, ohne
je FORTRAN zu lernen! Sind wir dazu verdammt, eine Industrie von UNIX-
Hackern und Pascal-Programmierern zu werden?
Nun, aus meiner Erfahrung heraus glaube ich, behaupten zu duerfen, dass
das Schicksal den Echten Programmierern wohlgesonnen ist. Weder OS/370
noch FORTRAN zeigen irgendwelche Symptome des Aussterbens, trotz aller
Anstrengungen der Pascal-Programmierer. Selbst subtilere Tricks wie das
Hinzufuegen strukturierter Schleifen zu FORTRAN sind fehlgeschlagen.
Sicher, einige Computerhersteller liefern FORTRAN-77-Compiler, aber
jeder einzelne von ihnen laesst sich ueber eine einzige Compiler-Option
in einen FORTRAN-66-Compiler verwandeln - mit DO-Schleifen, wie von
Gott geschaffen.
Selbst UNIX scheint fuer den Echte Programmierer nicht mehr so schlecht
zu sein wie frueher. Die neueste UNIX-Version hat das Potential eines
Betriebssystems, das eines Echten Programmierers wuerdig ist. Sie hat
zwei verschiedene, leicht inkompatible Benutzerschnittstellen, einen
geheimnisvollen und komplizierten Teletype-Treiber und virtuellen
Speicher. Und wenn der Echte Programmierer die Strukturierung
ignoriert, kann er sich sogar mit C anfreunden. Schliesslich gibt es
keine Typenbindung, Bezeichner sind sieben (Zehn? Acht?) Zeichen lang,
und man hat Zeiger als Bonus. Das ist, als haette man die besten Teile
von FORTRAN und Assembler vereinigt, von den kreativeren Moeglichkeiten
des #define ganz zu schweigen.
Nein, die Zukunft ist nicht voellig schlecht. So hat sich in den
vergangenen Jahren die populaere Presse sogar ueber die clevere neue
Brut von Computer-Schraten und -Hackern geaeussert, die Plaetze wie
Stanford und MIT zugunsten der Wirklichkeit verlassen haben. Allen
Anzeichen nach lebt der Geist der Echten Programmierung weiter in
diesen jungen Maennern und Frauen. Und solange es schlecht beschriebene
Ziele, bizarre Fehler und unrealistische Zeitplaene gibt, solange wird
es Echte Programmierer geben, die bereit sind, einzuspringen und das
Problem zu loesen, und die sich die Dokumentation fuer spaeter
aufheben.
Lang lebe FORTRAN!
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
 |
Steffen Bühler
Moderator
Anmeldungsdatum: 13.01.2012
Beiträge: 7244
|
| Steffen Bühler Verfasst am: 17. Dez 2020 13:58 Titel: |
|
|
Fortran hab ich Mitte der 80er im Studium kurz kennengelernt, dann hab ich mir Basic auf dem Amiga selber beigebracht. Auch den 68000-Assembler, um den Prozessor richtig kennenzulernen.
In den 90ern kam dann berufsbedingt Pascal, C, C++ dazu. Insbesondere letzere Sprache ist nach wie vor mein Favorit. Ästhetisch und alles andere als geschwätzig. Und: ein anständiges Programm muss objektorientiert sein, sonst wird es doch nur Spaghetticode mit globalen Variablen.
Bei Visual Studio, Python und Co. sehe ich die Gefahr, dass effizientes Programmieren verlernt wird. So, ich brauch mal eben 1 Gigabyte Speicher für mein Bild? Kein Problem. Freigeben muss ich ja nichts, der Garbage Collector sorgt schon für alles. Drei if-Abfragen in einer for-Schleife? Warum soll das langsam sein, bei 4GHz Prozessortakt? Ich merk nichts. Vier returns in einer Funktion? Ist doch nicht schlimm, jemand anders muss das ja nicht verstehen, solange es funktioniert.
Diese Arbeitsweise beobachte ich in den letzten zehn Jahren verstärkt bei jungen Kollegen. Und wundere mich so langsam auch nicht mehr, dass auch professionelle Software immer mehr Speicher will und trotzdem langsam ist. Man sollte die Informatik-Studenten vielleicht wirklich mal im Praktikum an einen 8bit-Prozessor mit 500KB RAM setzen und eine FFT programmieren lassen, einfach um wieder mehr Demut hineinzubringen.
Viele Grüße
Steffen
|
|
|
Nils Hoppenstedt
Anmeldungsdatum: 08.01.2020
Beiträge: 2019
|
| Nils Hoppenstedt Verfasst am: 17. Dez 2020 14:21 Titel: |
|
|
Ich nutze hauptsächlich Matlab. Vorteile sind die hohe Performance bei Matrizen-Operationen (insbesondere Bildverarbeitung), die umfangreichen Visualisierungsmöglichkeiten und natürlich die riesige Matlab-Community.
Viele Grüße,
Nils
|
|
|
Steffen Bühler
Moderator
Anmeldungsdatum: 13.01.2012
Beiträge: 7244
|
| Steffen Bühler Verfasst am: 17. Dez 2020 15:20 Titel: |
|
|
|
Matlab ist ja eher ein CAS als eine Programmiersprache. Sowas nehme ich natürlich auch, hier werkelt noch ein Mathcad 5.0 fröhlich vor sich hin. Was das nicht hinkriegt, mach ich mit Wolfram.
|
|
|
Nils Hoppenstedt
Anmeldungsdatum: 08.01.2020
Beiträge: 2019
|
| Nils Hoppenstedt Verfasst am: 17. Dez 2020 15:45 Titel: |
|
|
Hallo Steffen,
Nur interessehalber: Was unterscheidet denn Matlab von einer Programmiersprache?
Viele Grüße,
Nils
|
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 17. Dez 2020 15:59 Titel: |
|
|
| Steffen Bühler hat Folgendes geschrieben: | | Und: ein anständiges Programm muss objektorientiert sein, sonst wird es doch nur Spaghetticode mit globalen Variablen. |
In der Informatik und vielen Anwendungen ja, in der Mathematik eher nein (lediglich für die Definition von Objekten wie komplexen Zahlen oder Quaternionen, mit denen dann jedoch prozedural oder funktional gearbeitet wird).
Bzgl. deiner Kritikpunkte - Coding vs. professioneller SW-Entwicklung - gebe ich dir teilweise recht. Was ich am meisten vermisse ist das Verständnis von Nebenläufigkeiten. Ich arbeite z.Zt. als Systemarchitekt im industriellen Umfeld - Prozessleitsysteme, IIoT, Cloud, ... - und erkenne immer öfter, dass die Ausbildung diesen Anforderungen nicht gerecht wird.
Nach Abschluss meines Studiums habe ich in der Industrie beobachtet, dass Informatiker speicherfressende Klassenbibliotheken entwicklen, während Mathematiker performante und robuste SW in C schreiben. Heutzutage generieren manche Kollegen schöne UIs mit Angular, die niederen Dienste verachten sie ...
Ich würde heute für bestimmte Positionen ausschließlich Programmierer einstellen, die auch C beherrschen, unabhängig davon, ob das auch verwendet wird. Das wäre mir wichtiger als eine FFT - aber ich weiß, was du meinst.
C++ ? Erstens inzwischen zu verwässert, und außerdem mag ich die STL nicht: kompakt, aber zu viel implizite Kapselung; solange keine Probleme auftreten ist alles OK, aber Debuggen? Interprozesskommunikation mit Streams? Was ich auch nicht mag ist, wenn dir eine Bibliothek ein bestimmtes Programmierparadigma alternativlos aufoktroyiert.
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
Steffen Bühler
Moderator
Anmeldungsdatum: 13.01.2012
Beiträge: 7244
|
| Steffen Bühler Verfasst am: 17. Dez 2020 16:11 Titel: |
|
|
| Nils Hoppenstedt hat Folgendes geschrieben: | | Was unterscheidet denn Matlab von einer Programmiersprache? |
Wenn ich es richtig sehe, wohl nicht viel. Es gibt anscheinend Schleifen und Abfragen wie in jeder Programmiersprache. Und es gibt wohl auch Compiler, damit man ein ausführbares Programm erstellen kann. Somit scheint es sich vom reinen C strukturell nicht zu unterscheiden, es sind eben weitaus mehr mathematische Grundfunktionen drin, die man in C erst durch eine Library bekommt.
Ob man mit Matlab wiederum Klassen oder auch brauchbare Benutzeroberflächen mit Buttons und Slidern erstellen kann, weiß ich nicht. Und ob man mehrere kleine Matlab-Quellcodedateien statt einer großen zu einem Programm verlinken kann, ebenfalls nicht. Sound und Video sowie Datenbanken wären auch interessante Themen, halt alles, was das Gebiet der Mathematik nicht mehr so betrifft. Könnte ich zum Beispiel in ein Mikrofon sprechen, und Matlab macht in Echtzeit eine Digitalfilterung und gibt die aus?
|
|
|
Nils Hoppenstedt
Anmeldungsdatum: 08.01.2020
Beiträge: 2019
|
| Nils Hoppenstedt Verfasst am: 17. Dez 2020 16:31 Titel: |
|
|
| Steffen Bühler hat Folgendes geschrieben: | Ob man mit Matlab wiederum Klassen oder auch brauchbare Benutzeroberflächen mit Buttons und Slidern erstellen kann, weiß ich nicht. Und ob man mehrere kleine Matlab-Quellcodedateien statt einer großen zu einem Programm verlinken kann, ebenfalls nicht. Sound und Video sowie Datenbanken wären auch interessante Themen, halt alles, was das Gebiet der Mathematik nicht mehr so betrifft.
|
Ja klar, das geht alles. Matlab ist in den letzten Jahren sehr mächtig geworden. Es gibt inzwischen auch gute Machine-Learning-Implementierungen.
| Steffen Bühler hat Folgendes geschrieben: |
Könnte ich zum Beispiel in ein Mikrofon sprechen, und Matlab macht in Echtzeit eine Digitalfilterung und gibt die aus? |
Laut Mathworks geht dies ebenfalls:
https://de.mathworks.com/help/audio/gs/real-time-audio-in-matlab.html
Viele Grüße,
Nils
|
|
|
ML
Anmeldungsdatum: 17.04.2013
Beiträge: 3400
|
| ML Verfasst am: 17. Dez 2020 19:50 Titel: Re: Programmiersprachen für mathematische Anwendungen |
|
|
Hallo,
| TomS hat Folgendes geschrieben: | | Mich würde einfach mal interessieren, welche Sprachen ihr so kennt und verwendet - sowie natürlich eure Erfahrungen. |
die Frage ist ja immer, ob man schnell ein Programm braucht oder ein schnelles Programm.
Als Schüler habe ich mit Pascal angefangen, später in der Uni habe ich auf C umgesattelt.
Inzwischen beschäftige ich mich vorwiegend mit Signalverarbeitung und neuronalen Netzen und nutze dazu Matlab. Es hat für meine Anwendungen mächtige Befehle, so dass ich bequem programmieren und parallelisieren kann. Für kleinere Anwendungen beim Arduino (in der Lehre) nutze ich das in der Entwicklungsumgebung genutzte C-ähnliche Konstrukt.
Mittelfristig steige ich vermutlich auf Python um, da meine Schüler das meist schon können.
Dass ich kein echter Programmierer bin, sieht man daran, dass ich noch nie den Reiz verspürt habe, eine eigene Programmiersprache zu erfinden. 
Viele Grüße
Michael
|
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 17. Dez 2020 22:02 Titel: Re: Programmiersprachen für mathematische Anwendungen |
|
|
| ML hat Folgendes geschrieben: | Dass ich kein echter Programmierer bin, sieht man daran, dass ich noch nie den Reiz verspürt habe, eine eigene Programmiersprache zu erfinden.
|
Und daran, dass du Python in Erwägung ziehst 
Ich hab mir das angeschaut: ja, sieht einfach aus, ist mir aber zu wischi-waschi ...
Gerade quäle ich mich durch Julia-Code, mächtig, aber ungewohnt.
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
masterpie
Anmeldungsdatum: 13.11.2019
Beiträge: 408
|
| masterpie Verfasst am: 17. Dez 2020 22:26 Titel: |
|
|
Ich habe vor 40 Jahren mit Assembler begonnen, dann C (die meiste Zeit und als einzige Sprache auch beruflich), etwas Basic und später etwas C++, Java und seit 8 Jahren bin ich von Python und seiner recht großen Wissenschaftscommunity begeistert – aber nur noch als Hobby.
Bei den CAS-Systemen gefällt mir Maple sehr gut. Matlab habe ich mir kurz angesehen. Es soll mal von Python ersetzbar sein. Auf dem Raspi kann man Mathematica (Wolfram) kostenfrei nutzen und mit Raspi 400 läuft das auch schon ganz gut.
Für C++ kann ich "Forschung mit Modernem C++" von Gottschling empfehlen. Der Autor arbeitet an der Weiterentwicklung mit, macht Lehrgänge (eigene Firma SimuNova, tolle eigene Bibliothek MTL4 - auf Geschwindigkeit getrimmt) und kennt Stroustrup persönlich gut. Bei MTL4 habe ich einen guten Eindruck gewonnen, was man aus C++ raus holen kann.
Bei Python gefällt mir aktuell Physik mit Python von Natt gut. Neu und für mich noch nicht einschätzbar ist der "Python-Kurs" von Steinkamp. Die Bücher von Klein sollte man sicher haben oder kennen. Natürlich gibt es noch viele andere gute und sehr gute Bücher.
Julia schaue ich mir mal demnächst an.
Auf keinem der Systeme bin ich Profi gewesen. Heute mache ich das alles ohnehin nur zum Spaß – auf Win10, openSuSE-Linux und Raspian auf Raspis von Version 1 bis 4. Macht Spaß und man muss ja irgendwie durch den Lockdown kommen. 
Gruß, Masterpie
_________________
Wir denken zu viel und fühlen zu wenig. (Charlie Chaplin) |
|
|
ML
Anmeldungsdatum: 17.04.2013
Beiträge: 3400
|
| ML Verfasst am: 17. Dez 2020 23:13 Titel: Re: Programmiersprachen für mathematische Anwendungen |
|
|
Hallo,
| TomS hat Folgendes geschrieben: |
Und daran, dass du Python in Erwägung ziehst
|
Na aber hallo. Und wehe, Du schlägst vor, Python mit einem Folter-Editor wie vi zu bedienen. 
| Zitat: |
Ich hab mir das angeschaut: ja, sieht einfach aus, ist mir aber zu wischi-waschi ...
|
Es kommt halt drauf an, was Du damit machen willst. Für die Entwicklung von neuronalen Netzen finde ich die Kombination Python+Tensorflow ziemlich gut, und Signale und Plots lassen sich mit Python anscheinend auch ganz gut ausgeben.
Viele Grüße
Michael
|
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 17. Dez 2020 23:31 Titel: |
|
|
Also vi ist natürlich die Katastrophe schlechthin.
Nein, es ging mir darum, dass wenn man von C / C++ / ... kommt, Python irgendwie lax aussieht; z.B. Strukturierung per Einrückung ohne explizites Blockende; ... ist halt Geschmacksache
Ich will nicht in Abrede stellen, dass die Sprache für ernsthafte Aufgaben anwendbar ist.
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
Qubit
Anmeldungsdatum: 17.10.2019
Beiträge: 829
|
| Qubit Verfasst am: 18. Dez 2020 06:05 Titel: |
|
|
Ich sehe im mathematischen Umfeld auch Julia stark im Kommen. Tatsächlich sind aber auch CAS inzwischen voll programmierbar (mit entsprechenden Schnittstellen). Ingenieure nutzen hingegen spezifische Programme zur Simulation und Berechnung.
Ansonsten muss man natürlich schauen, um welche Anwendungen/Plattformen es sich handelt.
Bleibt man systemnah / embedded, dann führt kaum ein Weg an C (und Assembler) vorbei, vielleicht wären da GO oder Rust eine Alternative?
Im Business-Bereich dominiert die Java-Welt (mit entsprechenden Frameworks). Mit der neuen GraalVM ( https://www.graalvm.org ) wird es eine Runtime-Umgebung geben, die durchaus an kompilierten C-Code ranreichen wird. Hier hat man dann die freie Wahl, ob Java oder Scala,Scriptsprachen wie Groovy oder Kotlin oder aber auch Python. Wobei, Python selbst nimmt eine Sonderstellung ein, ist multiparadigmenfähig und hat gute Bindings zu C/Libs.
Also, Mathematiker programmieren mit Libs, Informatiker mit Frameworks 
|
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 18. Dez 2020 08:04 Titel: |
|
|
Die zu lösenden Probleme sind sich völlig unterschiedlich.
In der Mathematik ist die Struktur des Problems zumeist klar - das erledigt der Mathematiker - lediglich die effiziente Implementierung stellt eine Herausforderung dar. Letztlich benötige ich Bibliotheken, die bestimmte Aufgaben lösen; welche das sind, in welcher Reihenfolge und mit welchen Abhängigkeiten, das legt der Mathematiker (oder Physiker, Ingenieur, ...) fest. Für eine bestimmte Aufgabenstellung lohnt ein Framework-Ansatz zumeist nicht.
Frameworks hingegen definieren einen Rahmen für die Architektur, wobei z.B. Inversion of Control und Dependency Injection die „Orchestrierung“ des Zusammenspiels unterschiedlicher Klassen oder Microservices bzw. deren Instanzen ermöglichen (in diesem Sinne ist vieles, was sich heute mit dem Begriff Framework schmückt, tatsächlich kein solches). Diese hohe Flexibilität und Wiederverwendbarkeit benötigt man in der Mathematik eher selten.
In meinem Umfeld sehe einen Trend hin zur Metamodellierung und Domain-driven Design / formalen Domain Specific Languages. Der Problemraum, die Abhängigkeiten, Geschäftsprozesse und -objekte werden modelliert, Software mit (lose gekoppelten) Interaktionen wird weitgehend generiert. Dabei kommen für den generierten Code sowie die orchestrierten Interaktionen zunehmend die selben Ansätze zum Einsatz. Die o.g.
Das führt jetzt aber weit von der ursprüngliche Fragestellung weg.
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
Steffen Bühler
Moderator
Anmeldungsdatum: 13.01.2012
Beiträge: 7244
|
| Steffen Bühler Verfasst am: 18. Dez 2020 09:06 Titel: |
|
|
Fehlt nur noch, dass hier einer mit Labview ankommt.
Diesen Vortrag sollte jeder von uns mal gesehen haben. Viel Spaß!
Zuletzt bearbeitet von Steffen Bühler am 18. Dez 2020 10:22, insgesamt einmal bearbeitet |
|
|
masterpie
Anmeldungsdatum: 13.11.2019
Beiträge: 408
|
| masterpie Verfasst am: 18. Dez 2020 10:05 Titel: |
|
|
| TomS hat Folgendes geschrieben: | | Also vi ist natürlich die Katastrophe schlechthin. |
Na endlich mal ein Thema, wo ich ordentlich Öl ins Feuer kippen kann ...
Ich arbeite seit 31 Jahren (einem Augustwochenende 1989) mit dem vi. Emacs habe ich immer mal versucht, aber mir fehlte die Geduld. Der heutige vi nennt sich zu recht vim (m-modifiziert) und kann erheblich mehr, als die Uraltversion aus Unix/SystemV-Zeiten. Dazu noch ein Tool wie make und man kann vieeeel lernen. Siehe z.B. die VLen hier https://ad-wiki.informatik.uni-freiburg.de/teaching/ProgrammierenCplusplusSS2020 von Frau Prof. Bast zu C++ in Freiburg. :thumb
Ich finde, sie macht das sehr gut und lässt ihren Studenten viele Freiheiten. Am Ende müssen aber alle ein bestimmtes Schema einhalten - sicher wegen der Vergleichbarkeit bei der Bewertung. So nebenbei lernt der Student Linux-Kommandos, die Bedienung des vim und die Erstellung von Make-skripten. Bei den Preisen, die die Frau Prof. schon geholt hat, kann das nicht die falsche Lernmethode sein und wenn man vi/vim einmal in den Fingern hat, behält man diese Fertigkeiten. Von der Pike auf lernen und zu Beginn ohne IDE wird von fast allen Autoren/Lehrenden empfohlen.
Vor 30 Jahren endete gerade die Zeit der begehbaren Rechner. Doch selbst damals moderne Workstations hatten kaum Taktfrequenzen über 20 MHz und meist nur 16 Bit-Datenbreite. Da war ein 19"-Schirm schon etwas Besonderes, doch kaum mal mit X11-Oberfläche und wenn, dann halt recht langsam. Meist bekam man ja doch nur ein ASCII-Terminal zugewiesen. Da war nix mit IDE und ähnlich netten Dingen. Dafür lief der vi bei IBM, DEC, DG, Sun, HP und was weiß ich noch wo. Auch 30 Jahre später, wenn man nichts sonst passendes auf einer "alten Möhre" fand. Der vi tat es immer. Selbst, wenn man mit C objektorientiert programmieren wollte. Klar diese Zeiten gehen zu Ende und wer effektiv arbeiten will, wird sich nach bestimmter Anlernzeit auch auf eine IDE stürzen. Bei Python habe ich das recht früh mit Spyder gemacht. Für die C-Sprachen hat man gute Auswahl von KDevelop, QtCreator, Code::Blocks, CodeLite, Xemacs, Kate, Anjuta und etlichen weiteren. Für Java sind Netbeans und Eclipse sicher die Wahl. Dennoch kann ich mit vim und make (cmake) auch heute recht schnell arbeiten und bin immer gut im Bilde, was ich tue und nicht was die IDE tut. Ein Makefile (oder CMake-) sollte ein Programmierer schreiben können (bei Java ein Ant-File). Funktioniert auch auf einem Intel-10-Kerner mit 5 GHz mit NVDIA-Supergrafikkarte oder einem Raspi4+ am 32"-4K-Flachdisplay.
Ich war nie ein Anhänger irgendwelcher Glaubenskriege, welches OS, welche Programmiersprache, welche Tools. Man nimmt, was man muss oder was man will, wenn man es kann und darf. Dazu sind die Aufgaben zu unterschiedlich und jeder wird wissen, was für ihn das beste Tool, das beste OS oder die beste Programmiersprache inkl. Editor bis IDE ist. Wie hier schon richtig festgestellt: Es kommt auf die jeweilige Aufgabe an. Supermoderne Frameworks haben am richtigen Ort ihre Berechtigung - aber nicht immer. In der Netzwerk- und Systemprogrammierung würde ich bei C und Assembler bleiben und sicher beim Prototyping mit Python, Perl, TCL/Tk oder Bash schon zufrieden sein können. Bei größeren und komplexeren Projekten ist für mich C++ mit IDE und entsprechenden Standard-Libs und Qt angesagt. Mit Python kann ich dank Anaconda und Spyder auch unter Windows entwickeln. Mit Code::Blocks auch bedingt C++. Mit den MS-IDEs komme ich nicht klar und muss es nicht. Wenn mir Maple als am hilfreichsten erscheint, dann wird es das sein. Mit Processing und weiteren Möglichkeiten ist Programmierung möglich.
Grüße, Masterpie
P.S.: LabView ist auch etwas interessantes ... 
_________________
Wir denken zu viel und fühlen zu wenig. (Charlie Chaplin) |
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 18. Dez 2020 13:10 Titel: |
|
|
Interessant - aber Öl für‘s Feuer kann ich nicht erkennen ;-)
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
masterpie
Anmeldungsdatum: 13.11.2019
Beiträge: 408
|
| masterpie Verfasst am: 18. Dez 2020 15:44 Titel: |
|
|
| TomS hat Folgendes geschrieben: | | Interessant - aber Öl für‘s Feuer kann ich nicht erkennen ;-) |
Danke, war ja auch nur als Spaß gedacht. Das Thema vi/vim hat schon heftige Stürme in entsprechenden Foren ausgelöst. Schön, wenn das hier sachlicher läuft.
Ich habe in den letzten Stunden julia auf einem Raspi4B installiert und auch gleich noch die Jupyterumgebung. Muss man nicht machen. Man kann julia ja auch so im Terminal starten bzw. ist erst mal erforderlich, um danach die Kommandos
julia> using IJulia
julia> notebook()
abzusetzen. Im Webbrowser (hier Chromium) wird Jupyter gestartet und darunter wird ein neues Notizblatt (nb) als Julia 1.0.3 Notebook gestartet. Darin kann dann wie üblich unter Jupyter gearbeitet werden.
Kernelneustart dauert bei mir ewig. Würde ich nicht empfehlen. Dann lieber das nb verlasssen und neu starten.
Das gleiche versuche ich jetzt unter Win10. Dauert alles etwas. Also Geduld ist angesagt. Ablauf sieht ziemlich genau so aus wie unter Raspian. Nur unter win10 ist das bereits julia 1.53 (vom 9.11.2020) während Raspian noch mit 1.03 daher kommt. Unter openSusE-Linux werde ich es mir auch noch anschauen.
Unter Win10 habe ich durch die Anaconda-Installation auch Jupyter laufen und darunter mit Python3, Sympy getestet. Aber arbeite da lieber mit Spyder3.
julia> using IJulia
julia> notebook()
tut, wie gewünscht. Nur hier fragt er nun, ob er mit
install Jupyter via Conda, y/n?
weitermachen soll. Na gut, dann y und die die dritte Jupyter-Installation auf die Platte. Ist ja noch etwas Platz vorhanden. Die ca. 15GB sind zu verschmerzen.
Win10-Julia lädt miniconda installer ..., installiert und konfiguriert diesen und holt alle erforderlichen Programme und Pakete und extrahiert und installiert diese. Na, da geht eine ganz schöne Menge Daten über die Leitung. Sieht vieles wie die Anaconda-installation aus.
Am Ende hat er Conda und IJulia installiert und Jupyter sogar von meinem Jupyter-Homeverzeichnis gestartet. Soweit allles rumpelfrei durchgelaufen.
Gleiches Julia-Kurztestprogramm reingehämmert. Läuft alles und korrekt. Alles abgspeichert und Kernel neu gestartet. Läuft auch und naja ... schon einiges schneller als auf dem kleinen Raspi4. Alles heruntergefahren und alle Windows (etwas brutal) geschlossen. Mit den kryptischen Ausschriften auf der Julia-Konsole könnte man Mitmenschen erschrecken.
Danach notebook() unter julia-Konsole neu gestartet und sofort wurde Jupyter gestartet. Dort im "Home" das Testprogramm aufgerufen. Kernelstart scheint etwas länger zu brauchen als der Python-Kernel braucht. Aber erträgliche Zeit. Testprogramm läuft wieder problemlos durch. Kernelrestart auch wieder möglich - für den Notfall sinnvoll.
Die vielen kryptischen Ausschriften auf der Julia-Konsole muss man nicht beachten. Das lässt sich bestimmt beim Aufruf unterdrücken. Aber muss ja nicht alles beim ersten mal sein. Soweit bin ich erst mal arbeitsfähig für julia-Tests und somit zufrieden. 
Grüße, Masterpie
_________________
Wir denken zu viel und fühlen zu wenig. (Charlie Chaplin) |
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 19. Dez 2020 09:07 Titel: |
|
|
Ich arbeite bisher - sehr sparsam - mit Notepad++ und der Windows-Kommandozeile; alles was ich brauche, wird jeweils in ein kleines Skript reingepackt (das mache ich auch in anderen Sprachen so, auch für LaTeX; ich mag diese Einstellungen über graphische Front-Ends nicht).
Ansonsten sieht das Notebook im Browser aber gut aus - ich werd’s mal mal testen.
Von Visual Studio habe ich mich - außer für C++ - verabschiedet. Ich find‘s nicht schlecht, aber für meine Zwecke zu groß.
Den Sinn der Julia-Konsole habe ich ehrlich gesagt nicht verstanden, aber ich bin halt auch Compiler-verseucht.
Zum Kernel-Neustart: Kann man diesen verhindern, wenn man ein Julia-Skript per julia test.jl aus der Windows-Kommandozeile startet, also den Kernel gestartet lassen und ihm immer ein neues Skript unterschieben? Oder wird zwingend immer ein neuer Kernel-Prozess je Julia-Skript gestartet? wäre das wirklich der einzige Vorteil der Julia-Konsole?
Ich stell morgen mal ein kleines Programm ein; schon cool, was als Open Source verfügbar ist; nicht nur Mathematik und Statistik, auch sehr gute Graphik, distributed computing, MPI, ...
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
masterpie
Anmeldungsdatum: 13.11.2019
Beiträge: 408
|
| masterpie Verfasst am: 19. Dez 2020 13:05 Titel: |
|
|
Ich habe nun julia auch unter openSusE-Leap15.2 installiert. Eigentlich nichts anderes als auf dem RaspberryPi, nur schlechter. Auch Version 1.03 und keine Updates. Versuche mit Updates aus dem Netz von anderen Anbietern haben nichts verbessert. Also unter SuSe-Linux für mich nicht nutzbar.
Mit Kernelneustart meinte ich den Kernel von Jupyter. Der muss nicht immer neu gestartet werden. Nur wenn ich in einem nb die Ausgaben lösche und alles neu abarbeiten lasse, wird die Zeilennummerierung fortgesetzt. Das muss aber nicht störend sein.
Grafikausgaben unter Raspian/Linux gelingen nicht, da sich die Programmerweiterung nicht übersetzen und damit nicht installieren lässt. Unter Windows sieht es ähnlich aus.
Im Netz findet man Anwendungsbeispiele, die vielfach eine Version 1.3 oder 1.4 von julia erfordern. Das deckt nur die 1.5x-Version unter Windows ab.
Ich denke, hier sollte man noch etwas Entwicklungszeit vergehen lassen, wenn man die hohe Verarbeitungsgeschwindigkeit nicht zwingend braucht. Ansonsten kann ich auch nur sagen, erstaunlich was hier openSource anbietet. Ich würde mich immer wieder mal melden, wenn es echte Fortschritte gibt.
Grüße, Masterpie
_________________
Wir denken zu viel und fühlen zu wenig. (Charlie Chaplin) |
|
|
masterpie
Anmeldungsdatum: 13.11.2019
Beiträge: 408
|
| masterpie Verfasst am: 19. Dez 2020 18:17 Titel: |
|
|
| TomS hat Folgendes geschrieben: | | Den Sinn der Julia-Konsole habe ich ehrlich gesagt nicht verstanden... |
Wahrscheinlich nur als eine Art Startplattform. (Alle weiteren Beschreibungen beziehen sich auf die Windows10-Julia 1.5x-Version) In dieser wird Pluto installiert. Das ist ein interaktives, reaktives Notebook und vollständig in Julia geschrieben und für die Arbeit mit Julia gedacht. Damit besteht keine Notwendigkeit mehr, Jupyter zu verwenden. Pluto wird eine schnellere Arbeitsweise gegenüber Jupyter bestätigt. Naja und das ist dann auch gleich eine ganz andere Arbeitsoberfläche als die Julia Konsole.
Die Installation wird in verschiedenen Inet-Quellen beschrieben. Diese hier http://blog.schockwellenreiter.de/2020/08/2020080102.html gefiel mir recht gut. Da wird auch zum WARUM von Pluto und seinen Verbesserungen kurz etwas gesagt. Man findet aber unter YouTube noch etliche weitere Install-Anleitungen (meist in englisch) und sicher sind die YouTube-Videos der JuliaCon 2020 und 2019 auch recht interessant.
Nach Start des Notebook-Servers (von Pluto) verlässt man die Julia-Konsole und kann unter seiner "Julia-IDE" auf Pluto weiter arbeiten. Ist ein editieren im Webbrowser.
Viel Spaß, beim Erforschen der Möglichkeiten.
Grüße, Masterpie
P.S.: Grafik läuft nun ( 22:12) auch unter Windows nach längeren Reparaturarbeiten.
_________________
Wir denken zu viel und fühlen zu wenig. (Charlie Chaplin)
Zuletzt bearbeitet von masterpie am 19. Dez 2020 22:20, insgesamt einmal bearbeitet |
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 19. Dez 2020 22:20 Titel: |
|
|
| masterpie hat Folgendes geschrieben: | | Ich habe nun julia auch unter openSusE-Leap15.2 installiert. Eigentlich nichts anderes als auf dem RaspberryPi, nur schlechter. Auch Version 1.03 und keine Updates. Versuche mit Updates aus dem Netz von anderen Anbietern haben nichts verbessert. Also unter SuSe-Linux für mich nicht nutzbar. |
Zu Linux kann ich nichts sagen, war seit Jahren nicht mehr auf meinem Rechner.
Ich hab die Windows-Version von der Julia-Homepage installiert, lief - fast perfekt: der Installer kommt nicht mit Multi-User-Umgebungen zurecht und installiert die SW immer ins persönliche Profil - seltsam.
Pakete zieht Julia immer von github, das funktioniert gut.
| masterpie hat Folgendes geschrieben: | | Ich habe Mit Kernelneustart meinte ich den Kernel von Jupyter. |
Ok, Missverständnis.
Das Problem mit dem Julia-Kernel besteht weiter. Ich schau mal, was sich machen lässt. Ich muss auch etwas Profiling betreiben, wo die Zeit bis zum eigtl. Start liegenbleibt; könnte ja auch der JIT-Compiler sein.
| masterpie hat Folgendes geschrieben: | | Ich hGrafikausgaben unter Raspian/Linux gelingen nicht, da sich die Programmerweiterung nicht übersetzen und damit nicht installieren lässt. Unter Windows sieht es ähnlich aus. |
Irgendein Paket hat - ungefragt - Qt nachinstalliert, ein anderes Python-Teile; das halte ich für lästig. Aber die Graphik-Ausgabe funktioniert, wobei ich das nicht direkt brauche; eine PNG-Erzeugung reicht.
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago.
Zuletzt bearbeitet von TomS am 19. Dez 2020 22:24, insgesamt einmal bearbeitet |
|
|
masterpie
Anmeldungsdatum: 13.11.2019
Beiträge: 408
|
| masterpie Verfasst am: 19. Dez 2020 22:24 Titel: |
|
|
Musste recht viel nachinstallieren und einiges einem neuen Build unterziehen. Aber am Ende läuft es nun unter Windows. Mit Linux warte ich, bis die dort auch bei Version 1.5.x sind.
Da wird etliches von Python und PythonQt genutzt. Viele Packages muss man erst mal installieren (wenn man im Netz darauf stößt) und initialisieren. Das dauert beim ersten mal seine Zeit. Aber wenn ich danach ein nb unter Pluto aufrufe, ist in kürzester Zeit das Ergebnis vorhanden. Da kann ich schon staunen.
Werde mir das weiter anschauen.
Gruß,Masterpie
_________________
Wir denken zu viel und fühlen zu wenig. (Charlie Chaplin) |
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 20. Dez 2020 20:57 Titel: |
|
|
Ich habe jetzt ein minimales Setup zusammen; unter Windows läuft das mit Julia 1.5.3 sehr smooth.
Ich muss noch etwas experimentieren, wie man den JIT Compiler austrickst; das dauert schon etwas; andererseits lohnt sich's auch nicht, jede mini-Funktion gleich in ein prä-compiliertes Paket zu stecken.
Der Julia-Kernel wird wohl je Script immer neu hochgezogen; ich hab noch nix anderes gefunden. Interessant wär's, einem eigenen listener-Script immer neue Module unterzujubeln; mal schauen, ob und wie das geht (ich denke an den Script-Namen per IPC / MPI o.ä., dann Laden und jeweils Aufruf einer worker-Funktion ...)
Über die Feiertage versuche ich mal, ein neuronales Netz für Tic-Tac-Toe und Vier-Gewinnt zu trainieren.
Anbei ein kleines Script zur Berechnung von Streuquerschnitten: Anstelle des eigtl. Streuquerschnitts als Funktion des Streuwinkels berechne ich (berechnet Julia) eine Heatmap für die Position der auslaufenden Teilchen auf einer Kugelfläche. Diese projiziere ich flächentreue in die xy-Ebene.
Wenn ich überlege, wie wir da mit Fortran und gnuplot rumgehampelt haben ...
| Code: | # module to calculate scattering cross sections
using LinearAlgebra
using OnlineStats
using RDatasets
using Plots
using PlotThemes
using Printf
using LaTeXStrings # https://juliapackages.com/p/latexstrings
# returns random in-vector in B^2 as impact parameter b <= 1.0 and sin(phi), cos(phi)
# input none
function in2vector()
while true
x, y = ( 2.0 * rand() - 1.0, 2.0 * rand() - 1.0 )
b2 = x^2 + y^2
if b2 <= 1.0
b = sqrt( b2 )
sin_phi = x / b
cos_phi = y / b
return ( b, sin_phi, cos_phi )
end
end
end
# classical hard-sphere scattering:
# returns out-vector on S^1 as radius = 1.0, sin(theta) and cos(theta); theta is scattering angle
# input is impact parameter b; (a = 1.0 is not used)
function hardsphere_out2vector( b::Real, a::Real = 1.0 )
sin_theta = 2.0 * b * sqrt( 1.0 - b^2 )
cos_theta = 2.0 * b^2 - 1.0
return ( 1.0, sin_theta, cos_theta )
end
# classical Coulomb scattering:
# returns out-vector on S^1 as radius = 1.0, sin(theta) and cos(theta); theta is scattering angle
# input is impact parameter b; a is quotient of E_kin / E_inter
function coulomb_out2vector( b::Real, a::Real = 1.0 )
x = b / a
d = x^2 + 1
sin_theta = 2.0 * x / d
cos_theta = (x^2 - 1.0) / d
return ( 1.0, sin_theta, cos_theta )
end
# Hammer equal-area projection from sphere S^2 to ellipsis ~B^2 in xy-plane
# returns x, y
# input is sin(theta) and cos(theta)
function hammer( sin_phi::Real, cos_phi::Real, sin_theta::Real, cos_theta::Real )
sin_phi_half = sign( sin_phi ) * sqrt( (1.0 - cos_phi) / 2.0 )
cos_phi_half = sqrt( (1.0 + cos_phi) / 2.0 )
denom = sqrt( 1.0 + sin_theta * cos_phi_half )
x = sqrt( 2.0 ) * 2.0 * sin_theta * sin_phi_half / denom
y = 2.0 * cos_theta / denom
return ( x, y )
end
# performs scattering using parametric function for scattering angle and calculates heat-map
# returns heat map
# input is scattering function and number ofr runs
function work( func, runs )
xy_tupel = (0.0 , 2.0)
heat = fit!( HeatMap(-3:.01:3, -3:.01:3), xy_tupel )
for n = 0:runs
b, sin_phi, cos_phi = in2vector()
r, sin_theta, cos_theta = func( b, 0.175 )
xy_tupel = hammer( sin_phi, cos_phi, sin_theta, cos_theta )
fit!( heat, xy_tupel )
end
return heat
end
# calls worker functions for different scattering scenarios; calls plot routines
function main()
theme( :dark )
heat = work( hardsphere_out2vector, 1000000000 )
p = plot( heat, title = "Hard sphere scattering", marginals = false, legend = true )
savefig( p, "hardsphere.png" )
heat = work( coulomb_out2vector, 1000000000 )
p = plot( heat, title = "Coulomb scattering", marginals = false, legend = true )
savefig( p, "coulomb.png" )
return nothing
end
main()
|
| Beschreibung: |
|
| Dateigröße: |
172.01 KB |
| Angeschaut: |
1309 mal |
|
| Beschreibung: |
|
| Dateigröße: |
43.79 KB |
| Angeschaut: |
1309 mal |
|
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
masterpie
Anmeldungsdatum: 13.11.2019
Beiträge: 408
|
| masterpie Verfasst am: 20. Dez 2020 22:53 Titel: |
|
|
Woh, toll. Ich habe das bei mir als Pluto-Notebook eingegeben (musste noch drei Packages compilieren) und habe rechnen lassen.
Da Pluto möchte, dass jede Kommentarzeile, using-Zeile, jede Funktion und natürlich main() in einer NB-Zeile stehen - angeblich wegen einfacherer Fehlersuche - kann ich sehen, welche Zeit pro Zeile vergeht (in ns, ms, us, ms und s).
Bei den using-Zeilen ist die Plots-Initialisierung mit 17s "Klassenbester". Die Main-Funktion läuft bis zu den fertigen PNGs auf der Platte 342 s. Da ist also ordentlich was zu tun. Das rechtfertigt eine Software wie julia.
Gruß, Masterpie
_________________
Wir denken zu viel und fühlen zu wenig. (Charlie Chaplin) |
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 21. Dez 2020 00:03 Titel: |
|
|
Der Plot ist nicht ganz selbsterklärend, die Beschriftung fehlt noch. Der Nordpol entspricht der 0°-Vorwärtsstreuung. Die Farbe zeigt die Anzahl der Events („Zählrate“). Im Falle der Coulombstreuung liegt natürlich Energieabhängigkeit vor, ich werde dafür noch einen zweiten Plot einbauen.
Der Appetit kommt beim Essen:
- numerische Berechnung des Streuwinkels für beliebige Potentialfunktion
- Heatmap auf rotierbarer Kugeloberfläche
- Histogram
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 21. Dez 2020 13:41 Titel: |
|
|
Sockets funktionieren stabil und übersichtlich.
Ansonsten ist IPC Unix-artig mit Semaphoren und Signalen sowie Shared Memory vorhanden. Async. File-IO habe ich nicht ausprobiert.
Leider gibt es keine echten MessageQueues.
MPI habe ich nicht ausprobiert, ich brauche was einfaches.
Server:
| Code: |
# module to receive data via socket
using Sockets
using Printf
function socketserver()
println( "Echo server on port 12321" )
try
server = listen( 12321 )
instance = 0
while true
sock = accept( server )
instance += 1
socklabel = "$(getsockname(sock)) number $instance"
@async begin
println( "Server connected to socket $socklabel" )
write( sock, "Reply from echo server.\r\n" )
while isopen( sock )
message = readline( sock )
# write( sock, "$message\r\n" )
# println( "Echoed $message to socket $socklabel" )
end
println( "Closed socket $socklabel" )
end
end
catch ex
println( "Caught exception: $ex" )
end
return nothing
end
function main()
socketserver()
return nothing
end
main()
|
Client:
| Code: |
# module to send data via socket
using Sockets
using Printf
function socketclient( message )
println( "Client on port 12321" )
sock = connect( 12321 )
println( sock, message )
return nothing
end
function main()
for num in 1:10
message = string( @__FILE__ ) * ": main()" * " -> worker(): " * string( num )
socketclient( message )
end
return nothing
end
main()
|
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 21. Dez 2020 16:18 Titel: |
|
|
Also dafür ist es sicher nicht gemacht, aber es funktioniert ;-)
Ich parse die Kommandozeile, schicke das Argument --arg1 per Socket an einen Server; der empfängt das Argument, lädt das entsprechende Julia-Skript, compiliert es dynamisch und führt es aus. Das klappt sogar mit den Streuprogrammen von gestern.
Nächster Schritt ist, das mit fertig compilierten Modulen anstelle von Skripten zu testen. Alternative wäre, den gesamten Code per Socket zu schicken.
Für kurze Skripte allemal sinnvoll. Auch für Hacker sicher spannend ;-)
Das Testscript, das dynamisch geladen und ausgeführt wird:
| Code: |
# script worker1
module worker1
export work
using Printf
function something1()
println( @__FILE__, ": something1()" )
return nothing
end
function work()
println( @__FILE__, ": work()" )
something1()
return nothing
end
# work()
end
|
Das Skript, das die Anforderung wegschickt; das Parsen der Kommandozeile ist schön gelöst:
| Code: |
# module to send data via socket
# module to launch tasks asynchronously via socket
# tasks implemented by dynamically loaded julia scripts, retrieved from command line
using Sockets
using Printf
using ArgParse
# parse command line arguments
function parse_commandline()
s = ArgParseSettings()
@add_arg_table s begin
"--opt1"
help = "an option with an argument"
"--opt2"
help = "another option with an argument"
arg_type = Int
default = 0
"--flag1"
help = "an option without argument, i.e. a flag"
action = :store_true
"arg1"
help = "a positional argument"
required = true
end
return parse_args(s)
end
# sends launch commands via socket
function socketclient( message )
# println( "Client on port 12321" )
sock = connect( 12321 )
# write( sock, "$message\r\n" )
println( sock, message )
close( sock )
return nothing
end
# retrieve task to be launched from command line
function main()
parsed_args = parse_commandline()
# for ( arg, val ) in parsed_args
# println( " $arg => $val" )
# end
message = string( parsed_args["arg1"] )
# println( message )
socketclient( message )
return nothing
end
main()
|
Der Server, der die Aufräge abarbeitet; Sockets wie vorhin, jedoch jetzt noch Laden, Parsen und Aufrufen des fremden Skripts
| Code: |
# module to process tasks asynchronously
# tasks implemented by dynamically loaded julia scripts
using Sockets
using Printf
# loads worker scripts and calls their standard work() functions
function callworker( modname::AbstractString )
try
include( modname * ".jl" )
# println( "call ", modname, "->work()" )
Main.eval( Meta.parse("using Main.$modname") )
mod = getfield( Main, Symbol(modname) )
Base.invokelatest( mod.work ) # standard entry function is work()
catch ex
println( "Caught exception: $ex" )
end
return nothing
end
# listens to launch commands via socket
function socketserver()
println( @__FILE__, ": Process server on port 12321" )
try
server = listen( 12321 )
instance = 0
while true
sock = accept( server )
instance += 1
socklabel = "$(getsockname(sock)) number $instance"
@async begin
println( "Server connected to socket $socklabel" )
# write( sock, "Reply from echo server.\r\n" )
while isopen( sock )
message = readline( sock )
callworker( message )
# write( sock, "$message\r\n" )
println( "Echoed $message to socket $socklabel" )
end
# println( "Closed socket $socklabel" )
end
end
catch ex
println( "Caught exception: $ex" )
end
return nothing
end
function main()
socketserver()
# callworker( "worker1" )
return nothing
end
main()
|
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
ML
Anmeldungsdatum: 17.04.2013
Beiträge: 3400
|
| ML Verfasst am: 29. Dez 2020 01:37 Titel: |
|
|
Hallo Tom,
| TomS hat Folgendes geschrieben: |
Über die Feiertage versuche ich mal, ein neuronales Netz für Tic-Tac-Toe und Vier-Gewinnt zu trainieren.
|
das Erstellen einer KI für Vier-Gewinnt will ich perspektivisch nächstes Jahr in der Schule in einem Wahlpflichtfach anbieten.
Falls Du Dich noch nicht im Detail auskennst, empfehle ich zur Lektüre folgende Veröffentlichungen:
a) das Alpho-Go-Zero Cheat Sheet
https://www.datasciencecentral.com/profiles/blogs/deep-learning-alphago-zero-explained-in-one-picture
und
b) das Paper "Mastering the game of Go without human knowledge", doi:10.1038/nature24270
Die dort vorgestellte KI ist eine der berühmten GO-Kis, die die menschlichen Meister degradiert hat und kann im Prinzip auch auf Vier-Gewinnt angepasst werden. Sie ist von der Programmierung her allerdings m. E. nicht ohne Tücken. So verwenden die Autoren beispielsweise eine KI mit zwei Köpfen statt zweier separater KIs. Allein, um den Überblick zu behalten, würde ich die einzelnen KIs vorziehen. Bei zwei KI-Köpfen stelle ich es mir auch schwer vor, die Verlustfunktionen gut auszutarieren, denn der Anlernvorgang muss letztlich auf die Optimierung beider KI-Ausgänge gleichzeitig optimieren. Allerdings stecke ich bestimmt nicht so tief in der Thematik drin wie die Verfasser des Papers. Mir hat der Kopf, ehrlich gesagt, ganz schön geraucht, als ich mir das Vorgehen im Detail angeschaut habe.
Wenn Du sowas "nebenbei in den Weihnachtsferien" codest, alle Achtung! Oder kanntest Du die Papers eventuell noch nicht, und ich habe Dich soeben mit der Idee angefixt? Corona geht ja vielleicht noch länger als uns lieb ist
Viele Grüße und viel Erfolg
Michael
|
|
|
TomS
Moderator
Anmeldungsdatum: 20.03.2009
Beiträge: 18079
|
| TomS Verfasst am: 29. Dez 2020 10:53 Titel: |
|
|
Hallo Michael,
erst mal danke für die Hinweise. Zu Go und dem speziellen Ansatz weiter unten mehr.
Bisher habe ich nur einiges im Internet gelesen. Eigentlich dachte ich, dass ich ein NN-Framework für Julia nutze, aber ich werde zunächst doch zu Fuß programmieren, um die Sprache besser zu verstehen.
Tic-Tac-Toe und allgemeinere Varianten wie (m,n,k)-Spiele haben alle das selbe Problem des spares rewards: die Belohnung erfolgt am Ende des Spiels, d.h. sehr selten. Das unterscheidet diese Probleme grundsätzlich z.B. von Mustererkennung, wo eben zu jedem Bild einer Katze oder eines Hundes sofort ein Feedback erfolgt. Damit wird das übliche Backtracking und die Anpassung der Gewichte mittels lokaler Optimierung wie gradient descent u.ä. unmöglich.
Eine Variante ist, das NN nicht auf das Spielziel zu trainieren, sondern “sinnvolle Zwischenziele” einzuführen, für die dann jedesmal Backtracking erfolgen kann. Dabei gibt es mehrere Probleme: Zunächst muss man eine Bewertungsfunktion einführen, die nicht nur den Sieg bewertet sondern Stellungen, d.h. zwei Steine in einer Reihe, Drohung, Zentrum usw. Das ist für Tic-Tac-Toe einfach machbar - man kann alle zulässigen Spielbäume generieren und im Speicher halten - für komplexere Spiele - und das beginnt schon mit Vier-Gewinnt - sehr aufwändig. Letztlich implementiert man fast ein klassisches und sehr effizientes alpha-beta-pruning, lediglich ohne den Zuggenerator, um dies dann - extrem ineffizient - durch das NN erlernen zu lassen (Stockfish kann im normalen Spiel viel mehr Stellungen pro Sekunde analysieren als AlphaZero und hat wahrscheinlich die wesentlichen ausgefeiltere Stellungsbewertung).
Dann gibt es noch ein theoretisches Problem, nämlich das der Q-Funktion. Vereinfacht gesagt bestimmt die Q-Funktion das Ziel des NNs. Im Falle von Tic-Tac-Toe ist die Q-Funktion trivial: sowohl für X als auch für O muss das NN auf Remis trainiert werden, da es sich um ein stark-gelöstes Spiel mit optimaler = Remis-Stragie für beide Spieler handelt. Vier-Gewinnt und Go (auf kleineren Brettern als 19 x 19) sind schwach gelöst, es existiert eine Gewinnstrategie für den Anziehenden. In allen Fällen kann bewiesen werden, dass keine Gewinnstrategie für den nicht-Anziehenden existiert. Demnach dürfte man das NN für Tic-Tac-Toe nie auf Sieg trainieren, im Falle von komplizierteren Spielen zumindest nicht für den Nachziehenden. Das ist aber praktisch irrelevant, da dies ja nur im Falle eines perfekt spielenden Gegners gilt. Im Falle von Tic-Tac-Toe ist das aber extrem relevant, da das Spiel so einfach ist; trainiert man das NN auf Remis, bleibt das Spiel immer langweilig; trainiert man es auf Sieg, verliert das NN evtl. auch in Positionen, wo Remis erreichbar wäre (AlphaZero spielt im Schach irrational und schwach in Situationen, wo es nach eigenem Wissen verlieren wird; es stellt zum Beispiel keine Fallen und führt keine komplexen Stellungen herbei, um den Gegner in Zeitnot zu bringen). Man muss also wieder sehr viel explizites Tic-Tac-Toe-Wissen anwenden.
Tic-Tac-Toe ist also leider ein extrem ungeeignetes Beispiel für NNs, und kann deswegen nur eine kurze Übung sein.
Zu AlphaGo und AlphaZero sowie Monte-Carlo-Tree-Search: Die Idee besteht darin, die Zwischenbewertung anhand der Wahrscheinlichkeit der zukünftigen Gewinne in einem Sub-Tree zu ermitteln. Es wird also kein Go-Wissen eingefüttert, es wird stattdessen anhand der Statistik der bisher gespielten (gelernten) Spiele ermittelt, welcher Sub-Tree zu spielen ist. Im Training werden die Sub-Trees irgendwann vollständig ausgespielt, so dass eine Bewertung erfolgen kann; die Backpropagation = das Lernen erfolgt jedoch für die Wahl des Sub-Trees. AlphaGo lernt also nicht direkt, zu gewinnen, es lernt, aus den vorhandenen Möglichkeiten diejenigen auszuwählen, für die die höchste Gewinnwahrscheinlichkeit vorliegt (so habe ich das verstanden).
Ich hatte mir die Idee schon vor Jahren angeschaut. Der Kerngedanke ist recht einfach, die Umsetzung jedoch extrem aufwändig: man benötigt insbs. einen Spielbaumgenerator, eine exakte Buchführung, Backpropagation, also die komplexe Kombination beider Welten (und das sind nur die unmittelbar erkennbaren Elemente, dazu kommen noch zig technische Details).
So mach ich es also auch nicht ;-)
Ich möchte zwei Dinge kombinieren: 1) ein NN, das lernt, ein Spiel zu spielen, jedoch ohne Backpropagation, da dies entweder ziemlich sinnlos wird oder extrem kompliziert - siehe oben. 2) Einen evolutionären Algorithmus, der aus einer NN-Population die erfolgreichsten Kandidaten auswählt. Das ist sicher deutlich einfacher als Monte-carlo-tree-search, zugleich jedoch auch näher an der Realität als ein klassisches NN für gelöste Spiele. Das NN soll dabei ganz klassisch auf der Outputseite die Wahrscheinlichkeit der eigenen Züge ausgeben; dabei soll es auch die Regeln für die erlaubten Züge erlernen. Die Bewertung der Population erfolgt anhand
d.h. mittels verschiedener Gewichtungen für Sieg (win w) und Remis (draw d).
Das NN soll eine Teil der Spiele gegen sich selbst (jeweils eine andere NN-Instanz *) sowie einen Teil gegen einen random-Player spielen. Bei 64 NNs wären das mindestens 2016 Spiele je Runde plus die gegen den random-Player. Ein Spiel ist wenig aussagekräftig; nimmt man eher 100, wird die Zahl der notwendigen Spiele je Population bereits recht groß. Bei 32 NNs wäre das mit 496 Paarungen und demnach 49600 Partien recht überschaubar - zumindest bei 3*3 = 16 oder 4*4 = 32 Zügen je Partie (die Partien werden bei einem Sieg natürlich nicht weitergespielt). Ansonsten reduziere ich auf 16 NNs. Nach einer Population werden die besten z.B. 4 NNs ausgewählt und daraus 7 * 4 = 28 Clone plus Mutationen erzeugt, die dann in der nächsten Runde antreten.
*) EDIT: gerade erkannt, dass es zusätzlich auch gegen die eigene Instanz spielen soll; dann werden es etwas mehr Spiele
Was mir noch unklar ist, wo genau der Zufall bei der Evolution ansetzen soll. Es gibt zwei Möglichkeiten bei der Mutation der NNs zur Erzeugung einer neuen Generation:
a) Mutationsrate
pro neuer Generation werden K aus N Gewichte mutiert; über die Zeit wird R reduziert.
b) Gewichtung der Mutation je weight im NN
f() ist eine fixe Zufallsverteilung, epsilon wird über die Zeit reduziert.
Das entspricht dem Ansatz des simulated annealings.
Man untersucht heute in der KI die Neuroevolution zur Anpassung der Hyper-Parameter, d.h. die Zahl der Ebenen der NNs, der Neuronen, auch der Lernzyklen usw. Ich würde dies alles jedoch zunächst parametrierbar einbauen und die Evolution nur zur Anpassung der Gewichte nutzen.
Mir ist klar, dass dies deutlich ineffizienter ist als MCTS, jedoch wesentlich einfach zu implementieren. Und man kann das sehr gut parallelisieren, ggf. auch für wenig Geld in eine Cloud schieben.
_________________
Niels Bohr brainwashed a whole generation of theorists into thinking that the job (interpreting quantum theory) was done 50 years ago. |
|
|
|
|
Registrieren
Login
FAQ
Suchen
