von Günter Frank
Mit Aktualisierung vom 20.5.20
Zwei Spezialisten haben sich die Computer Modellierung des britischen Wissenschaftlers Neil Ferguson, der die Regierung in Sachen Corona beriet, näher angesehen. Er sagte Millionen von Corona-Toten voraus und beeinflusste weltweit die Lockdown-Maßnahmen.
Das Urteil der IT-Fachleute ist verheerend: Es handele sich womöglich um den zerstörerischten Softwarefehler aller Zeiten, was die wirtschaftlichen Kosten und die Zahl der verlorenen Leben anbetreffe. Beachten Sie bitte den Nachtrag/ die Aktualisierung am Ende des Textes-
Erinnern Sie sich noch an die Modellrechnung des britischen Wissenschaftlers des Imperial College in London, Neil Ferguson, der die Regierung in Sachen Corona beriet und die wissenschaftliche Grundlage für die strengen Ausgangsbeschränkungen in Großbritannien lieferte? Er prognostizierte 2,2 Millionen Coronatote für die USA und 500.000 für Großbritannien. Auf diesem Modell beruhte letztlich die Corona-Strategie der Abflachung der Kurve „flattening the curve“ durch Social Distancing und Lockdown.
Heute erweist sich dieses Modell als hysterische Überschätzung. Selbst die vielen Coronatoten in Großbritannien (ich möchte stets anfügen, dass diese Coronatoten auch die sehr wahrscheinlich hohe Zahl an Verstorbenen beinhalten, die unnötig intubiert wurden), werden bei weitem nicht die vorderen Ränge der jährlichen Todesursachenstatistik einnehmen, mit oder ohne Lockdown.
Gescheiterte Venus-Raumsonde
David Richards und Konstantin Boudnik, Gründer, CEO sowie Sotfwareleiter von WANdisco bezeichnen diese Modellrechnung nun als den womöglich zerstörerischsten Softwarefehler aller Zeiten:
„Die Modellierung nicht-pharmazeutischer Interventionen für Covid-19 durch das Imperial College, die dazu beitrug, Großbritannien und andere Länder zu drakonischen Lockdowns zu bewegen, wird die gescheiterte Venus-Raumsonde ablösen, die als der verheerendste Softwarefehler aller Zeiten in die Geschichte eingehen könnte, was die wirtschaftlichen Kosten und die Zahl der verlorenen Leben betrifft.“
Original auf Englisch heißt es:
„Imperial College’s modelling of non-pharmaceutical interventions for Covid-19 which helped persuade the UK and other countries to bring in draconian lockdowns will supersede the failed Venus space probe could go down in history as the most devastating software mistake of all time, in terms of economic costs and lives lost.”
Im britischen Telegraph fragen die beiden anerkannten Programmier-Spezialisten, warum die Regierung keine zweite Meinung eingeholt hat, bevor sie das Covid-Computer-Modell des Imperial College akzeptiert hat. Weiter schreiben Sie:
„Seit der Veröffentlichung des Mikrosimulationsmodells von Imperial haben diejenigen von uns, die ein berufliches und persönliches Interesse an der Softwareentwicklung haben, den Code studiert, auf dem die politischen Entscheidungsträger ihre schicksalhafte Entscheidung basierten, unsere mehrere Billionen Pfund schwere Wirtschaft einzumotten und Millionen von Menschen in Armut und Not zu stürzen. Und wir waren zutiefst beunruhigt über das, was wir entdeckt haben. Das Modell scheint völlig unzuverlässig zu sein, und Sie würden nicht Ihr Leben darauf verwetten.“
Schon vor 20 Jahren Schnee von gestern
Das Modell von Imperial scheine auf einer Programmiersprache namens Fortran zu basieren, die schon vor 20 Jahren Schnee von gestern gewesen sei. Ihr Code sei auch für die gescheiterte Raumsonden-Mission verwendet worden, wie für die Raumsonde Mariner 1. Und sie sagen: „In unserer kommerziellen Realität würden wir jeden für die Entwicklung eines solchen Codes feuern, und jedes Unternehmen, das sich bei der Herstellung von Software zum Verkauf darauf verlässt, würde wahrscheinlich pleite gehen“.
Weiter schreiben Sie: Die Modelle müssten in der Lage sein, den grundlegenden wissenschaftlichen Test zu bestehen, um bei gleichen Ausgangsparametern die gleichen Ergebnisse zu erzielen. Andernfalls gibt es einfach keine Möglichkeit, zu wissen, ob sie zuverlässig sein werden.
Das Resumee der beiden Kritiker: „Tatsächlich verwenden viele globale Industrien erfolgreich deterministische Modelle, die den Zufallsfaktor berücksichtigen. Kein Chirurg würde einen Herzschrittmacher bei einem Herzpatienten einsetzen, wenn er wüsste, dass er auf einem wohl unvorhersehbaren Ansatz beruht, aus Angst, den hippokratischen Eid zu gefährden. Warum um alles in der Welt würde die Regierung ihr Vertrauen darauf setzen, wenn das gesamte Wohlergehen unserer Nation auf dem Spiel steht?“
Nachtrag vom 20.Mai 2020
Mein letzter Beitrag wurde in den Leserbriefen zur Recht kritisiert, weil ich mich eben fachfremd bin bzgl. Computer Modellen. Leser Daniel Hirsch hat das ganze Problem mit dem Imperial Model viel besser und treffender erklärt. Imperial Model, Computersprache und Schuster bleib bei deinen Leisten. Beim letzten Beitrag, habe ich mein Fachgebiet verlassen, und einige Leser erweiterten daraufhin meinen Horizont. Zu Recht, denn ich werfe es beispielsweise Prof. Christian Drosten vor, dass er sich ausserhalb seiner Fachkompetenz z.B. zur Epidemiologie äussert und genau deswegen scheitert. Ein Virologe muss vor den Gefahren warnen, aber Epidemiologie bedeutet gerade eben nicht, stets vom worst case auszugehen, sondern sich um echte Daten zu kümmern und diese im Sinne von Wahrscheinlichkeiten zu deuten. Daniel Hirsch ist Computerfachmann und kann die Problematik des Imperial Models deshalb viel treffender beschreiben. Ich möchte Ihnen mit seiner Erlaubnis seine Zuschrift an mich nicht vorenthalten:
Als Mathematiker mit der Spezialisierung numerische Mathematik habe ich während meines Studiums an der Uni Heidelberg zahlreiche Supercomputer entworfen, betrieben und eigene Modelle entwickelt (mit Schwerpunkt in der nichtlinearen Optimierung und im Bereich unstetige Galerkin-Verfahren). Deshalb möchte ich gern die Gelegenheit nutzen und ein bisschen von meiner Expertise beitragen.
1. Programmiersprache
Die Programmiersprache ist letztlich nur eine Form um Maschinensprache (die sprichwörtlichen „bits and bytes“) für den Menschen lesbar bzw. menschliches strukturiertes Denken für den Computer ausführbar zu machen. Die Programmiersprachen sind dabei in ihren Grundfunktionen gleich. In jeder Sprache finden sich einfache Strukturen, wie Schleifen (Zählschleife: „mache irgendwas n mal“; vorprüfende Schleife: „so lange eine Bedingung erfüllt ist, mache irgendwas“; nachprüfende Schleife: „wenn irgendeine Bedingung richtig ist, mache das, was Du vorher gemacht hast nochmal“), Bedingungen („wenn irgendwas richtig ist, mache folgendes, anderenfalls was anderes“), Zugriffe auf Dateisysteme oder auf den Monitor/Tastatur. Zudem gibt es inzwischen in vielen Programmiersprachen auch die Möglichkeit komplexere Strukturen, wie z.B. vererbbare Objekte, Templates, etc. zu bauen. Das im Detail auszuleuchten sprengt den Rahmen.
Fortran ist in der Tat eine recht alte Programmiersprache (von 1957), die ihre Vor- und Nachteile hat. Das zu diskutieren löst in aller Regel – wie so oft in der IT – einen Glaubenskampf aus. Die Unterschiede in den Programmiersprachen liegen neben der offensichtlichen anderen Syntax in der Regel eine Ebene tiefer, also wie performant ein Compiler ist, wie performant das erzeugte binary ist, wie gut der Code auf andere Plattformen übertragen werden kann, etc. Es spielt aber auch eine Rolle, wie stark die Kommerzialisierung einer Programmiersprache ist. Programmiersprachen, die für kommerzielle Software verwendet werden, sind oft stärker unterstützt und entwickeln sich schneller als weniger populäre Sprachen. Die wesentlichen Vorteile von Fortran aus meiner persönlichen Sicht sind, dass die Lernkurve um Fortran programmieren zu können, recht flach und kurz ist und sehr viel frei verfügbarer Code existiert. Es gibt Literatur, wonach gute Fortran Compiler bei Array-basierten Anwendungen schnelleren Code als flexiblere Sprachen wie z.B. C++ produzieren können sollen. Das läßt sich in der Regel aber mit „besserem“ Code kompensieren. Richtig ist in jedem Fall, dass gerade im universitären Bereich Fortran weite Verbreitung hat und es eine lebendige Community gibt, die die vorhandenen Compiler und den Standard (zuletzt 2018) weiterentwickelt. Es ist daher nicht ungewöhnlich Programme in Fortran in diesem Umfeld zu finden.
2. Universitäre Softwareentwicklung
In Mathematik und Physik ist es weit verbreitet Software für verschiedene Zwecke zu entwickeln. Oft wird die Software für eine bestimmte Klasse Großrechner (z.B. Parallelrechner) oder gar nur für einen ganz bestimmten Rechner entwickelt. Im Vordergrund steht dabei immer die Mathematik oder die Physik und weniger die informatische Qualität der Implementierung. Da es ein recht großer Aufwand ist, jedes Einzelproblem, welches man lösen möchte, dediziert zu programmieren, verwendet man den Code in sogenannten Bibliotheken immer wieder. Darin sind mathematische Formen, wie Vektoren, Tensoren, Gitter, etc. ebenso wie die mathematischen Modelle und Algorithmen, die mit diesen Strukturen umgehen müssen, bereits implementiert. Diese Bibliotheken werden dann – meist kostenlos – allen anderen Wissenschaftlern zur Verfügung gestellt. Die Entwicklungsteams sind klein und es wird nicht nach kommerziellen Standards entwickelt. Man kann nicht erwarten, dass die Software einem IT-Qualitätsassessment standhalten wird. Daraus zu folgern, dass die Software falsch rechnet, ist jedoch voreilig.
3. Mathematische Modellierung
Wenn ein Modell aufgestellt wird, bedient man sich für gewöhnlich zunächst der Mathematik und zwar ganz klassisch mit Tafel und Kreide. Die Implementierung erfolgt danach mit Hilfe der vorhandenen Bibliotheken. Wenn das Modell implementiert ist, verwendet man üblicherweise Testdaten und -probleme um zu zeigen, dass die Software funktioniert. Oft werden die Ergebnisse auch publiziert, da neue Modelle / Algorithmen in der Regel nur dann implementiert werden, wenn sie aus wissenschaftlicher Sicht neu sind oder wenn die Implementierung aus irgendeinem Grund besser ist als bisherige Implementierungen (z.B. schnellere Konvergenz, geringerer notwendiger Speicherplatz, höhere Genauigkeit, etc.). Andernfalls macht sich keiner die Mühe vorhandene Modelle nochmal zu implementieren – außer vielleicht im Rahmen einer Übung zu einer Vorlesung. Hier liegt auch der Unterschied zur Venus-Sonde. Die Software für die Venussonde war für eine einmalige Anwendung gedacht (nämlich genau diese Sonde auf dieser Mission) und konnte unter Echtbedingungen nie getestet werden. Die Modelle von Neil Ferguson sind mehrfach getestet und mit anderen Modellen gegen gerechnet worden. Das schließt Programmierfehler freilich nicht aus, aber bisher gibt es keinen Hinweis auf einen solchen. Wahrscheinlicher sind Fehler in den Ausgangsdaten.
4. Numerischer Fehler
Das größte Problem bei mathematischen Modellen ist der sogenannte numerische Fehler. Die meisten Strukturen in der alltäglichen Mathematik basieren auf den reellen Zahlen. Ohne die reellen Zahlen funktioniert unsere Welt nicht mehr. Bestes Beispiel: Der Umfang eines Kreises. Ohne die Zahl pi, ist der Umfang nicht exakt zu errechnen. Dummerweise hat pi unendlich viele Nachkommastellen (die wir logischerweise auch nicht alle kennen). Daher kann man eine solche Zahl nicht auf einem Computer abbilden, der ja nur über endlich viel Speicher verfügt, selbst wenn wir alle Nachkommastellen kennen würden. Man behilft sich durch Runden der Zahl (typischerweise auf 16 Stellen) . Für alltägliche Probleme reicht die Rundungslogik auf normalen Rechnern völlig aus. Allerdings gibt es noch ein weiteres Problem: Ein mathematisches Modell besteht aus sehr vielen Einzeloperationen. Die Rechenoperationen reagieren dabei unterschiedlich gut auf die Eingangsdaten und die Einzelfehler jeder Operation können sich im gesamten Modell aufschaukeln. Es ist daher sehr wichtig, die Stabilität/Zuverlässigkeit des Algorithmus gegen derartige Effekte zu kennen.
5. Eingangsfehler
Bei allen Algorithmen gilt das „shit-in-shit-out“-Prinzip. Arbeitet man mit Daten, die einen großen Fehler beinhalten, dann kommt am Ende ein noch viel größerer Fehler raus (wie viel schlimmer sagt uns die Stabilität eines Modells). Die Programmiersprache ist nicht entscheidend, denn es kommt überhaupt nicht darauf an, ob ein mathematisches Modell in Fortran, C++, Basic oder von mir aus auf Lochkarten implementiert wird. Genauso wenig wie es darauf ankommen sollte, ob man eine Addition mit dem Rechenschieber, dem Abakus, einem Taschenrechner oder im Kopf durchführt. Ich bin davon überzeugt, dass das Problem des Modells von Neil Ferguson in den Eingangsdaten liegt. Das von ihm verwendete Modell basiert im Wesentlichen auf folgenden Daten:
- Todesrate (CFR) in Hubei – hierzu hat sich Neil Ferguson 39 Todesfälle von diversen Webseiten zusammen gesucht und davon 26 verwendet (leider ohne zu sagen, welche 26)
- CFR auf den Evakuierungsflügen von China nach z.B. Deutschland, Japan und Malaysia (insgesamt 290 Fälle)
- Aufwuchsrate der Epidemie, also der tägliche Zuwachs an neuen Fällen – diese Aufwuchsrate wurde auf Basis der offiziellen Meldungen abgeleitet
- Zeitraum zwischen Infektion und Tod / Erholung
Damit gibt es folgende Probleme:
- Zunächst ist die CFR nicht zuverlässig. Sie hatten das so schön formuliert – „viele Patienten sterben nicht an COVID-19 sondern mit COVID-19“. Diese Erkenntnis, die ja auch im Wesentlichen auf der Arbeit von Prof. Schirmacher und seinen Kollegen beruht, hatte man zu diesem Zeitpunkt (Anfang Februar) noch nicht, sondern hat platt angenommen, wer positiv auf COVID getestet wurde und starb, ist an COVID-19 gestorben. Die Todesfälle in Hubei betreffen allesamt ältere Menschen (nur sechs Opfer sind unter 60 Jahre, der Jüngste ist 36, wobei nicht klar ist, welche 26 Personen aus dem Datensatz mit 39 Opfern in die Analyse eingeflossen sind). Bereits an diesen frühen Daten war absehbar, dass ältere Menschen deutlich stärker betroffen sind als jüngere. Das Modell lässt das vollkommen unberücksichtigt. Prof. Ioannidis hat bereits früh auf die mangelnde statistische Güte der vorhandenen Daten hingewiesen.
- Es fehlten überall Testkapazitäten, daher wurde nicht repräsentativ getestet, sondern in der Regel nur beim Vorliegen von (teils schweren) Symptomen und auch erstmal nur in Wuhan, also mit sehr hoher Wahrscheinlichkeit Menschen mit Vorerkrankungen und mit sehr geringer Wahrscheinlichkeit junge, gesunde Menschen ohne Symptome, deren CFR weit geringer ist. Menschen ohne oder mit nur milden Symptomen sind in der Stichprobe aus Hubei vollkommen unterrepräsentiert.
- Umgekehrt wurden die ausgewählten Heimkehrerflüge größtenteils vollständig getestet. Deshalb überwiegen in diesem Datenset die Patienten ohne Symptome (Gesamt 10 Fälle, davon 7 asymptomatisch). Die Daten sind daher keineswegs vergleichbar.
- Bei den Heimkehrerflügen war in 50% der Fälle kein Infektionsdatum bekannt. Neil Ferguson hat daher einfach das Datum des ersten Kontakts mit den Gesundheitsbehörden angenommen. Dazu schreibt er wörtlich: „We note this is the latest possbile onset date and may therefore increase our estimates of CFR”.
- Zudem wurde mit Ausbreitung der Pandemie auch die Testkapazität erhöht, so dass sich die Wahrscheinlichkeit, dass eine bestimmte Bevölkerungsgruppe in der Gruppe aller getesteten repräsentiert ist, sich mit der Zeit – quasi täglich – verändert hat. Die Hypothese, die täglich publizierte Zahl der Infizierten, würde jeden Tag im gleichen linearen Verhältnis zur tatsächlichen Zahl der Infizierten stehen, ist nicht richtig. Neil Ferguson hat das zwar in der Studie erwähnt und auch richtigerweise auf die unterschiedlichen Testkapazitäten, -qualität und -praxis in verschiedenen Ländern hingewiesen, aber die Relation zwischen Testaufwuchs und gemessenen Infektionen konnte niemand zu diesem Zeitpunkt richtig abschätzen.
- Die Aufwuchsrate der Epidemie wurde deutlich überschätzt, denn es wurden ja nicht jeden Tag gleich viele Menschen getestet, sondern jeden Tag mehr, so dass man auch immer mehr Infizierte fand. Der Aufwuchs setzt sich zusammen aus dem Aufwuchs der Testkapazitäten und dem Aufwuchs der tatsächlichen Infektion, ersteres wurde aber zu gering geschätzt.
- Für die Wahrscheinlichkeitsverteilung für den Verlauf zwischen Infektion und Tod / Genesung wurde die Wahrscheinlichkeitsverteilung der SARS-Epidemie von 2003 in Hong Kong herangezogen und verallgemeinert, so dass der Zeitraum mit 22 Tagen analog zur damaligen SARS-Epidemie angenommen wurde. Auf den ersten Blick erscheint das fragwürdig, denn zum Zeitpunkt der Studie lagen noch keine gesicherten Erkenntnisse vor, dass der Verlauf von COVID-19 dem von SARS entspricht.
Mit dieser recht wackeligen Datenlage und noch wackligeren Annahmen wurde dann mit Hilfe von verschiedenen statistischen Methoden (Bayes Statistik, Maximum-Likelihood, Kaplin-Meier) die CFR berechnet.
Die hohe Unsicherheit beschreibt Neil Ferguson selbst, denn die ermittelte CFR schwankt in den Gruppen Hubei und den Rückflügen zwischen 1,2% und 18%. Am Ende werden eigentlich nicht zusammen passende Daten miteinander vermischt und eine CFR von ca. 1% mit einem Unsicherheitsintervall von 0,5% bis 4% geschätzt. Zieht man die unbeachteten Fehler (Überschätzung der Aufwuchsrate, Dunkelziffer bei den Infektionen, Differenzierung bei der Todesursache, etc.) in die Kalkulation mit ein, reduziert sich das weiter.
Aus handwerklicher Sicht hätte das eigentlich niemals publiziert werden dürfen. Die Schwankungen in den Ergebnissen gehen über eine ganze Größenordnung und die Unsicherheit in den Eingangsdaten ist offensichtlich. Es zeigt aber sehr schön, das Dilemma. Die Wissenschaft konnte im Februar keine klaren Ergebnisse liefern. Es wäre möglich, dass die CFR bei 18% lag. Genauso konnte sie bei 0,8% oder darunter oder bei jedem anderen Wert liegen. Die Entscheidung war daher eine rein politische. Die Politik wiederrum hat einfach die „aus der Hüfte geschossene“ Todesrate von 1% genommen und durchmultipliziert. Dabei kamen ebenso logisch wie falsch Millionen Tote heraus.
Man kann an diesem Beispiel wunderbar erkennen, wie gefährlich die mathematische Modellierung sein kann, wenn man die Annahmen nicht gründlich betrachtet. Ein ehemaliger Chef von mir (alter Controller) hat mal zu mir gesagt: „Businesscases schaue ich mir nie an. Ich glaube schon, dass die Leute richtig rechnen können. Ich schaue mir immer die Annahmen an. Da lügen sich alle in die Tasche.“ Um in solchen schwerwiegenden und unklaren Situationen eine gute Entscheidung zu treffen, reicht es nicht auf oft fragwürdige Zahlen zu schauen. Es braucht vor allem Führungsqualitäten, wozu auch ein Bauchgefühl und Risikobewusstsein gehören.
Der Beitrag erschien zuerst bei ACHGUT hier
Man sollte sich darüber klar werden, dfaß es nur einen glaubwürdigen Prof., nämlich den aus HH gibt. Hier der Kurzhinweis auf sein Ergebnis:
>>Bei vielen gestorbenen Covid-19-Patienten können Thrombosen und Embolien festgestellt werden. Das ist das Ergebnis einer Studie am Institut für Rechtsmedizin des Universitätsklinikums Hamburg-Eppendorf (UKE), wie Stefan Kluge, Direktor der UKE-Intensivmedizin am Freitag in Hamburg sagte. Demnach seien bei Obduktionen von zwölf Covid-19-Patienten in sieben Fällen verstärkt Thrombosen – also Gerinnselbildungen – in den Gefäßen der unteren Extremitäten festgestellt worden. Vier Patienten seien an einer Lungenembolie gestorben, ohne dass es vor ihrem Tod entsprechende Anzeichen gegeben habe.
Die Ergebnisse der Studie hätten sich auch bei weiteren Obduktionen wiedergefunden, sagte der Direktor des Instituts für Rechtsmedizin, Klaus Püschel. Insgesamt seien in seinem Institut bisher 190 gestorbene Covid-19-Patienten untersucht worden.
Therapie mit blutverdünnenden Mitteln empfohlen.
Die Ergebnisse hätten auch Einfluss auf die Behandlung Erkrankter, sagte Kluge. „Wir haben jetzt die Möglichkeit, einen Teil der Patienten zu behandeln mit Blutverdünnern. Und das sollten wir auch tun.“
Laut einer Studie des Universitätsklinikums Hamburg-Eppendorf hatten viele Corona-Tote Lungenembolien. Der Infektiologe Hans-Peter Hauber von der Asklepios-Klinik Altona im Gespräch.
Dass in die den Angaben zufolge weltweit erster Studie dieser Art nur vergleichsweise wenig Obduktionen eingingen, sei auch dem Zeitfaktor geschuldet, sagte der Oberarzt des Instituts für Rechtsmedizin, Jan Sperhake. Hätte man mehr Fälle berücksichtigt, „wären wir nicht schnell genug gewesen. So einfach ist das.“
Ein weiteres Ergebnis sind häufig festgestellte Nebenerkankungen bei verstorbenen Covid-19-Patienten an Lunge und Herz oder Krankheiten wie Parkinson und Demenz. Übergewicht und Zuckerkrankheit scheinen laut Sperhake ein Risikofaktor zu sein. Insgesamt weisen die Ärzte aber darauf hin, dass weitere Folgeuntersuchungen für ein besseres Bild nötig sind.<<
Und damit dürfte klar sein, daß die meisten Ärzte gepennt haben oder schlimmer noch unfähig sind sich selbst gegen Virusübertragungen bei Obduktionen zu schützen.
Wie gut Ärzte sind kann man daran erkennen, daß die mir etliche Zähne ziehen wollten. Bis auf die 4 Weisheitszähne und einen vor einem Eckzahn habe ich noch alle Zähne. Das zeigt: Traue niemals einem Arzt. Überprüfe das, was die machen wollen.
Wie heißt es doch so schön? Vertrauen ist gut, Kontrolle ist besser!
Vielen Dank allen Kommentatoren!
Der Disput erinnert mich an die schönen Zeiten, als es in der Bibliothek des Jenaer ZEISS-Werkes noch keinerlei Literatur zur Programmierung gab und wir Fans einen ReAssembler geschrieben haben, um hinter die Tricks zu schauen, welche die Programmierer des Home-Computers Sinclair ZX81 angewendet haben, um in einem winzigen Chip nicht nur BASIC, sondern auch noch das Betriebssystem mit mehreren wichtigen Schnittstellen zur Außenwelt, wie Tastatur, Bildschirm und Tonbandgerät (zur austauschbaren Aufzeichnung geschriebener Programme in Z80-Assembler u. BASIC) unterzubringen.
Damals zerfiel diese Welt in die beiden Konkurrenten Sinclair mit dem ZX81 und Commodore mit dem C64, die sich die Ossis von wohlmeinenden Omas und Opas „…aus dem Westen…“ mitbringen ließen.
Es hat uns trotzdem nicht daran gehindert, uns auch mit FORTH und Assembler zu befassen und für den Winzling auch noch ein trickreiches Grafikprogramm zu schreiben (mit 256 x 192 Pixeln), also Punkt-Setzen, Linie-Ziehen, Kreisbogen und Vollkreis mit Stauchungs-Koeffizient für Ellipsen usw. Echtes Nostalgie-Feeling solche Erinnerungen!
Herzlichen Dank!
Schöne Erinnerungen ….
Meinereiner hatte vor der Wende beide – ZX81 und dann C64, wobei eher der ZX Spectrum damals das „Gegenstück“ zum C64 war.
Hier in Ilmenau an der TH gab es schon Jahre vor der Wende (!!!)einen „Commodore-Computer-Club“ (Nutzer anderer „Heimrechner“ waren natürlich auch sehr willkommen…). Da wurde nicht nur „gespielt“ und kopiert, sondern auch „DDR-typische“ Anwendungen „gebastelt“, wie z.B. das Thema, aus einer Typenradschreibmaschine einen „Quasi-Nadeldrucker“ zu machen oder überhaupt an den C64 zu bringen. Selbst über „KI“ auf dem C64 wurde gefachsimpelt ….
Ich habe mit meinem C64 „Pioniernachmittage“ an unserer (Grund-) Schule gestaltet, wo viele Kinder überhaupt erst mal mit Computern direkt in Berührung gekommen sind ((Geschicklichkeitsspiele, Ratespiele …). Was ich den Kindern einleitend immer gesagt habe: Computer sind eigentlich ganz dumm, erst der Programmierer entscheidet, was der Computer kann oder auch nicht, womit der Bogen zum Fadenthema wieder hergestellt ist.
Ich bin leider nicht weit über Basicprogrammierung hinaus gekommen, hat aber bis heute für meine messtechnischen Anwendungen gereicht. Zu DDR-Zeiten hatten wir Messgeräte-Schnittstellen für den K1002 „nachgebastelt“ und jahrelang erfolgreich (bis nach der Wende) betrieben (bis die Magnetkarten nicht mehr funktionierten…). Der Code war sehr „maschinennah“, aber was wir da mit 2k Programmspeicher „angestellt“ haben, dafür würde man heute einige MB brauchen …..
PS: In der DDR wurden Programmiersprachen in MOPS und POPS unterschieden, aber das dürfte Ihnen ja bekannt sein … 😉
Twitter Post von John Carmack:
„Before the GitHub team started working on the code it was a single 15k line C file that had been worked on for a decade, and some of the functions looked like they were machine translated from Fortran. There are some tropes about academic code that have grains of truth, but \“
Zur Info für alle Egoshooter-Zocker der ersten Stunde:
John Carmack entwickelte unter anderem einen Großteil der Game-Engines von Doom und Quake !
Der Hauptartikel ist unglaublicher Schrott (z.B. dass die Wahl von Fortran eine Rolle spielen würde), peinlich, dass so etwas überhaupt veröffentlicht wird.
Versöhnt wurde ich dann durch den Nachtrag. Da stand dann endlich, was wir alle schon wussten: Epidemiologische Modelle sind simpel und effizient, das Problem liegt in der Abschätzung der Eingabeparameter, was gerade bei einer neuen Krankheit mit großen Unsicherheiten verbunden ist.
Dass Ferguson da anfangs suboptimal gehandelt hat, ist im Nachhinein leicht festzustellen. Interessant ist, dass es der Klimaforscher James Annan schon sofort gesagt hat und die Eingangsparameter besser bestimmt hat, siehe
http://julesandjames.blogspot.com/2020/04/blueskiesresearchorguk-model.html
Und hier sieht man sehr schön, wie empfindlich die Prognosen auf Veränderungen der Daten reagieren (logarithmische Skala beachten!):
http://julesandjames.blogspot.com/2020/04/reporting-delays-etc.html
Ich möchte mich weder aufdrängen, noch die Regeln der Höflichkeit verletzen, aber, schlagen Sie doch mal die Seite der dailymail.co.uk bspw. auf.
Die in Gefangenschaft gehaltenen Menschen haben alles längst durchschaut. Betrachten Sie die wunderbaren, schönen Bilder vom gestrigen Mittwoch. Es ist alles so wie früher, wie an jedem warmen, sonnigen Tag, nicht nur am Strand. Man hält keinen Abstand mehr.
Quelle:
https://www.dailymail.co.uk/news/article-8341971/PMs-plan-end-lockdown-TEN-DAYS.html
Hallo Herr Kegelmann,
mir ist nicht klar, inwieweit ihr Beitrag einen Bezug zu meinem Post hat. Könnten Sie das erläutern?
Ich versuche mal einen herzustellen:
Ihre Bilder zeigen, dass nun eine neue Ära anbricht. Wie werden sich dadurch die Eingabeparameter verändern? Schwer zu sagen, es ist ja eine neuartige Krankheit und es fehlen die Erfahrungen, welchen Einfluss diese Veränderungen z.B. auf die Reproduktionsrate haben werden. Jede Modellierung der Zukunft ist also automatisch nur eine grobe Abschätzung.
Mit Glück geht alles gut, mit Pech starten wir eine zweite Welle mit einem zweiten Lockdown. In diesem Falle hätten wir wohl Probleme damit, die Bilder als „wunderbar“ zu bezeichnen.
Sie sind in „Gefangenschaft“? Mein Beileid, da geht es mir weitaus besser.
Vielleicht zum Trost ein Kant-Zitat? Freiheit ist die Einsicht in Notwendigkeit.
Hallo Herr @Limbach, ich zitiere Sie:
„Und hier sieht man sehr schön, wie empfindlich die Prognosen auf Veränderungen der Daten reagieren […]“
1. Nennen Sie mir (alle) Staaten, die Daten absolut sicher validieren wollen und es auch können. Zur Erinnerung: Keine echte Validierung, keine Wissenschaft möglich.
2. Der Hamburger Rechtsmediziner Prof. Püschel kann das. Er soll bei mittlerweile über 200 Leichen die Obduktion (Autopsie) durchgeführt haben. Die unfähige Regierung ignoriert ihn und seine bemerkenswerten Resultate. Diese Tatsache allein, sollte bei Ihnen die Alarmglocken läuten lassen. Wer Püschel ignoriert, macht automatisch Pseudo-Wissenschaft, will das Volk betrügen.
3. Kant? Nein danke. Dann ist mir ein Stoiker lieber.
„Die Krankheit ist ein Hindernis für den Körper, nicht für den Willen, sofern dieser es nicht selbst so will.
Hinken ist ein Hindernis für das Bein, nicht für den Willen. Dies sage dir bei allem, was dich trifft. Dann wirst du finden, daß die Ereignisse immer ein Hindernis für etwas bilden, nicht aber für dich.“ (Epiktet, der Marcus Aurelius beeinflusst haben soll.)
4. Kant war einfältig und hat die Leute betrogen, sie dumm gemacht. Auch war er in der Freimaurerkirche zum Todtenkopf und der [albernen] Phönix. Das müssten Sie als Kantianer wissen. Das ist Ihre Pflicht, wäre es. Und an die Auferstehung einer toten Phönix glauben zu wollen, ist wirklich das Allerletzte, was ein Mensch brauchen kann. Und einen Totenkopf anbeten? Igitt.
Stoiker schlagen jeden Kantianer. 😉
5. Lesen Sie die anderen Artikel, vor allem auch die vielen klugen Kommentare, dann erkennen auch Sie, der Lockdown war ein sehr teurer und gemeiner Fehler, dieser Regierung in Berlin. Und fahren Sie (zur Not nur gedanklich) nach Taiwan. Die zeigen Ihnen, wie man damit richtig umgeht. Denn, mit Taiwan beschäftigt sich kaum einer. Die werden auch ignoriert. Die kommunistisch geführte WHO hat Taiwan aus der WHO hinaus befördert, weil die kriminellen Rotchinesen das so wollten. In Rotchina gibt es keine freie Meinung, kein freies öffentliches Denken. Demnach wird auch dort keine echte Wissenschaft gedeihen können.
Die britischen Bürger sind weitaus klüger als Merkel und ihre korrupten Möchtegern-Wissenschaftler.
Ganz recht, Herr Kegelmann. Wer braucht schon Epidemiologen, wenn es Rechtsmediziner gibt. Klimawissenschaft lasse ich mir auch lieber von einem Elektroingenieur machen.
Man kann in JEDER Programmiersprache Mist machen. Simulationen sind problematisch! Die Kritik an FORTRAN ist nicht berechtigt. Heute(!) läuft noch viel COBOL. C ist für viel Typenmist und damit für Zugriffsfehler bekannt. Das mußten wir 40 Jahre aushalten. Das Konzept entscheidet besonders für Simulationen.
@Mathias Kegelmann: Als mittlerweile ausgemusterter Softie mit >30 Jahren Erfahrung in C++, C, Pearl, Fortran und mehreren Assemblern darf ich ihnen mitteilen, dass mir noch Keiner begegnet ist, der ein nicht triviales Programm in einem Schritt erzeugt hat, egal wie viel der Compiler an Fehler- Vermeidungstrategien enthält. Auch in Assembler kann man Array – Grenzen testen, man muss es nur selbst tun.
@Manfred Herr, danke.
Ich wollte damit nur sagen, andeuten, in Erinnerung rufen, in Assembler zu programmieren ist ungleich schwerer und zeitaufwendiger. Assembler hat noch andere Schwierigkeitsgrade, wie Prozessertyp, Lesbarkeit, tieferes Verständnis der Materie.
Ich kann leider keine Assembler-Programmieurng. Hat sich nicht ergeben. Aber, für den, der sie beherrscht, bieten sich große Vorteile.
Auch in C wollen Arrays gelernt sein.
Mit 30 Jahren Erfahrung sind Sie mir eindeutig überlegen. Gratulation. Da kann ich nur von Ihnen lernen.
Ich darf höflich daran erinnern, dieser Neil Ferguson, könnte auch gedanklich mehr mit seiner (linksextremistischen) Geliebten und ihrem wahnsinnig designten Körper beschäftigt gewesen sein, als mit dem Virus.
Seine Geliebte ist verheiratet. Während des Lockdowns trafen sich beide, feierten Party, mit anderen womöglich zusammen, und setzten dem Ehemann die Hörner auf, ohne dessen Zustimmung.
Ferguson hielt sich also selbst nicht an seiner (unfachmännischen) Empfehlung. Das führte dann auch zu seiner Entlassung. So las ich es zumindest.
Ferguson kann auch deshalb kein großer Denker sein, weil er so nebenbei die komplette Wirtschaft eines Landes ruiniert. Kompetenz ist etwas völlig anderes.
Ferguson war noch nie Taiwan. Sollte er tun.
Ein wirklich selten schwacher Beitrag!
Erstens muss ich Herrn Heino Müller Recht geben bezüglich Fortran. Man kann behaupten, Fortran ist die Mutter aller Programmiersprachen, moderne sehen ganz anders aus und haben viel mehr Möglichkeiten, sind aber gewissermaßen alle Weiterentwicklungen von Fortran.
Zweitens: „…erfolgreich deterministische Modelle, die den Zufallsfaktor berücksichtigen.“ Es wird dem Leser suggeriert, dass Modelle die Zufälle berücksichtigen könnte, die man in der Wirklichkeit nicht im Voraus einbeziehen kann. Das ist riesengroßer Unfug. Um bei dem Beispiel vom Chirurgen und Herzpatienten zu bleiben: Bei jedem großen Eingriff kann es zum Tod des Patienten kommen, durch Zufall. Egal wie gründlich die Vorbereitung ist, manchmal stellt sich zum Schluß heraus, der Patient hätte ohne der OP paar Monate gelebt, nun ist er tot. Zufall, nicht berechenbar. Zu welchen Thema auch immer, davon auszugehen, dass Computer Programme Zufälle exakt zu vorherzusehen… So eine Steigerungsform von Dummheit kann ich nicht formulieren.
Drittens: Es ist ein generationsübergreifende und bildungsübergreifende Problem unserer Gesellschaft, dass man i.d.R. Simulationsergebnisse nicht richtig einordnen kann, selbst unter vielen Eike-Lesern.
Der Klassiker: Wenn ich freudig mitteile, es ist 20 Grad warm, kommt aus der Umgebung häufig „mein Handy zeigt aber nur 17 Grad an!“ Es ist ein allgemeines Unvermögen bis Unwillen, zwischen Wirklichkeit (20 gemessen) und Simulation (17 vorhergesagt) zu differenzieren. Habe inzwischen die Lust verloren nachzufragen, welche Art von Thermometer das Handy hat, man erntet nur Unverständnis. Es wird eben nicht differenziert, beide steht auf ein Display und ist also gleichwertig.
Den Lesern hier traue ich zu, den Unterschied in diesem Beispiel zu erkennen. Bei komplexeren Simulationen, die man inhaltlich nicht exakt nachvollziehen kann (Beispiel Klima), neigt auch hier wohl die Mehrheit dazu, über gute, schlechte, richtige oder fehlerhafte Simulation zu sprechen, anstatt auf den Punkt zu kommen:
Jede Simulation zeigt nur Eins von vielen möglichen Ergebnissen. Die Wirklichkeit könnte nah dran sein, weit weg davon sein, manchmal auch exakt übereinstimmen. Bei den Wettervorhersagen klar zu sehen, bei allen anderen komplexen Simulationen mit vielen Unbekannten und Zufälle ist es nun mal genau so. Es ist nur eine Möglichkeit, ob es so kommt oder ganz anders, weiß nur der liebe Gott.
Damit kann eine Simulation unmöglich die Grundlage einer weitreichende Entscheidung sein. Wer das tut ist entweder völlig unfähig als Entscheider, oder ist ein Betrüger, der die Simulation als Ausrede für seine Entscheidung vorschiebt. Eine Simulation mit welchen Ergebnis auch immer, kann nur eine von vielen Bausteine sein, die zur Entscheidungsfindung führen. Nicht mehr und nicht weniger.
Daher ist die Artikel-Aussage: „Falsche Entscheidung, da auf Grundlage einer Simulation in der falschen Sprache getroffen“ mehrfach inhaltlich absoluter Unsinn.
Komme zum Klima zurück und erneuere mein Angebot: gebt mit genug Geld und Zeit und ich erschaffe eine Klimasimulation die für das Jahr 2100 die Temperatur ihrer Wahl vorhersagt, in der Spanne von plus minus 5 gemäß heute. Habe von Programmierung keine Ahnung, war aber lange genug Schnittstelle zwischen Kunde und Developer bei komplexen Berechnungen. Es wird so lange getrimmt, bis der Kundenwunsch erfüllt ist. Beim einer Klimasimulation würde ich zuerst den Programmierern vorschlagen, den CO2 Einfluß auf fast Null zu reduzieren und den Sonneneinfluß zu erhöhen und entsprechende Schwankungen der Sonne einzubauen…
Woher könnte jemand exakt feststellen, dass „meine Methode“ falscher sei als die von Ramstorf und Konsorten?
Nur mal so um den Glauben an heiligen Simulationen ein wenig zu erschüttern!
Die Kritik ist berechtigt. Es kommt nicht auf die Programmiersprache an, sondern wie man sie nutzt.
Ach, jetzt ein Computer Program schuld? Wie bei uns auf der Arbeit, wird etwas von der Firmenleitung verbockt, war es ein dummer Computerfehler. Verbockt einer aus der Arbeiterklasse etwas, war es menschliches Versagen. ?
Die Kritik ist berechtigt. Es kommt nicht auf die Programmiersprache an, sondern wie man sie nutzt.
„Erinnern Sie sich noch an die Modellrechnung des britischen Wissenschaftlers des Imperial College in London, Neil Ferguson, der die Regierung in Sachen Corona beriet und die wissenschaftliche Grundlage für die strengen Ausgangsbeschränkungen in Großbritannien lieferte? Er prognostizierte 2,2 Millionen Coronatote für die USA und 500.000 für Großbritannien.“
Der Artikel wurde am 19.März verfasst. Die Modellrechnung basiert auf bekannten Daten vor diesem Datum. Erst danach wurde der „Shutdown“ in England eingeführt. Wenn die damaligen Projektionen die Fallzahlen überschätzt haben ist dies nicht ein Fehler des Codes, sondern ein Beweis für die Wirksamkeit des Shutdowns.
https://www.deutsche-apotheker-zeitung.de/news/artikel/2020/04/06/shutdown-duerfte-bereits-zehntausende-tote-in-europa-verhindert-haben
„rechneten die Londoner Forscher mit 600.000 infizierten Menschen (95-Prozent-Vertrauensintervall: 240.000-1.500.000)“. Sagt eigentlich schon alles. Mal wieder wird aus Nichtwissen eine Simulation erstellt. Wenn die Maßnahmen so wirkungsvoll waren, warum ist dann in Frankreich, welches früher härtere Maßnahmen ergriffen hat, die Übersterblichkeit ‚durch die Decke gegangen‘?
„Wenn die Maßnahmen so wirkungsvoll waren, warum ist dann in Frankreich, welches früher härtere Maßnahmen ergriffen hat, die Übersterblichkeit ‚durch die Decke gegangen‘?“
Sie haben das Pandemie-Problem nicht verstanden. Ich verwende folgenden einfachen Ansatz. NA(t) ist die Zahl der aktiv infizierten, N0(t) die Anzahl der nicht infizierten und und nicht immunen lebenden Individuen. Dann gilt für die Wachstumsrate der aktiv infizierten Individuen dNA(t)= r(t)*NA(t)*N0(t). Der Koeffizient r(t) wird bestimmt durch (1) durch das Individuum selbst, (2) durch die Gebiets-Strukturen (Bevölkerungsdichte, Sozialverhalten usw.), (3) durch staatliche Eingriffe. Schweden kam ohne staatliche Eingriffe aus. Der Einfluss der staatlichen Eingriffe in Frankreich und in Deutschland ergibt sich wohl erst aus einer genaueren Analyse des Verlaufs der Fall-Zahlen.
Geehrter Herr Berberich,
verwenden Sie für die Zahl der aktiv Infizierten absolute Zahlen oder berücksichtigen Sie das Verhältnis zwischen Infizierten und Anzahl der durchgeführten Tests? Und was die Wirksamkeit der Maßnahmen angeht, kann man auf Euromomo sehr schön sehen, dass es keine Korrelation zwischen Zeitpunkt sowie Art der Maßnahmen und der Übersterblichkeit gibt. Zur Problematik der absoluten Fallzahlen noch etwas Interessantes:
https://www.heise.de/tp/features/Die-Ueberschaetzung-des-tatsaechlichen-Anstiegs-der-Coronavirus-Neuinfektionen-4709977.html
@Heino Müller
Zustimmung. Kann man so sehen, kann man so verteidigen.
Ich habe mich selbst bereits mit Fortran beschäftigt, einige Zeilen nachprogrammiert und hätte gerne mehr Zeit darin investiert. Es gibt „gefühlt“ zig Varianten von Fortran. Oder zuviele davon.
Für ein Virus und derem Verlauf dürfte Fortran aber nicht die beste Wahl sein, sondern unnötig kompliziert. Wie Sie selbst andeuten, muß man das Programmieren sehr gut beherrschen, um Fortran zu verwenden. Es gibt aber nicht so viele gute Programmierer.
Fortran wurde entwickelt, zu einer Zeit, in der man noch mit Lochkarten arbeitete. Daher ist das Schreiben von Fortran-Programmen am Lochkartenformat orientiert. Zusätzlich ist jede Programmzeile in vier Bereiche eingeteilt. Zumindest bei der klassischen Fortran-Variante.
Fortran wurde bereits 1955 erfunden, bei IBM. Da gab es den Begriff „computer scientist“ noch gar nicht.
Was für Fortran spricht, ist seine sehr viel höhere Schnelligkeit. Die auch heutige High-Level-Sprachen übertreffen soll, so Kupferschmidt im Jahr 2002.
Fortran ist weiterhin die Sprache (der Wahl) für Ingenierue, die Berechnungen durchführen wollen, müssen, die nicht alltäglich sind, nicht standardisierbar, für die noch keine Software programmiert wurde. Vor allem für Numerische Verfahren, nicht-lineare Gleichungssysteme. Und so fort.
Also, ich finde Fortran eine sehr interessante Sprache. Ob für die Kalkulation eines Virus so ein Riesenaufwand notwendig sein soll, das bezweifle ich sehr. Ein Mathebuch und etwas Papier hätten auch gereicht. Keine Programmierung der Welt kann intensives Nachdenken, Reflektieren ersetzen. Das verstehen vor allem Linke nicht.
Der Beitrag auf ACHGUT heisst heute: „Der alte Code und das neue Virus – mit Aktualisierung“. Vielleicht könnte man die Aktualisierung hier mit übernehmen? Die ist interessant …
Danke, haben wir übernommen. Die Kritik ist berechtigt. Es kommt nicht auf die Programmiersprache an, sondern wie man sie nutzt.
So etwas kenne ich aus verschiedenen Bereichen. Wer nicht analysiert hat kann mit numerischen Methoden nichts erreichen. Frei nach dem Motto: Nachdem wir das Ziel aus den Augen verloren hatten, verdoppelten wir die Anstrengungen (Rechencluster). Wenn ich qualitativ keine Zusammenhänge herstellen kann, brauche ich mir über die Höhe (Quantität) des mittleren Abendhochwassers in Hamburg in 50 Jahren keine Gedanken zu machen …
Sorry, muss natürlich „Entscheidend“ heißen.
Aber bitte, es liegt doch nicht an der Programmiersprache. Entsprechend ist doch der Algorithmus der programmiert wird. Man kann auch mit der neuesten Programmiersprache Unsinn programmieren.
Liebe EIKE-ianer!
So sehr ich die Beiträge auf AchGut schätze, lest bitte die Kommentare, bevor Ihr einen dort erschienen Beitrag „nachdruckt“. Die Aussage der zitierten IT Experten sind inhaltlich als fortgeschritten dümmlich zu bezeichnen. Ich will jetzt meinen Verriß vom AchGut Artikel nicht wiederholen. Aber, es gilt nach wie vor : garbage in, garbage out. FORTRAN ist eine Sprache aus dem technischen Bereich. Natürlich gibt es heute Entwicklungssysteme, die komfortabler zu bedienen sind. Wenn aber die Simulation die Wirklichkeit nicht abbildet (siehe Klimasimulationen GW!!!!!!!!), dann liegt das am Lösungsdesign, nicht an der Programmiersprache!
Also Fortran würde ich jetzt nicht unbedingt die Schuld an einem ev. Versagen des Modells geben. Wer das behauptet, hat gelinde gesagt von Programmierung keine Ahnung. Es kommt immer darauf an, was der Programmierer für Algorithmen in seinem Modell verwendet und wie er die in der jeweiligen Programmiersprache umsetzt. Ich habe während meines Studiums der Meteorologie in den Übungen zur theoretischen Meteorologie ein „barotropes Modell“ programmieren müssen (in Fortran). Aus Interesse habe ich das Programm auch noch in C und in GFA-Basic geschrieben. Die Ergebnisse waren absolut gleich, bis auf die Tatsache dass die Basic-Version die doppelte Rechenzeit von Fortran und C gebraucht hat.
Also die Programmiersprache hat letztendlich nichts mit der Qualität eines Ergebnisses zu tun, sondern nur das Wissen und Können des Programmierers.
@Mag. Erwin Polreich, na ja. Wieviele Zeilen umfasste Ihr Programm?
Dann programmieren Sie doch mal das Gleiche in Assembler. Auch eine Programmiersprache.
Fortran does one thing (much better and easier) that C does not do: math.
In C programmieren, ist gleichbedeutend, mit einem Porsche zu fahren und in ein offenes Messer zu greifen.
Wieso gibt es dann so unglaublich viele Programmiersprachen? Wohl, weil jede über gewisse Vorteile verfügen darf.
Manche Programmiersprachen provozieren leichter gewisse Fehler. Niemand ist frei von Denkfehlern. Für die ist der Mensch allein verantwortlich. Oder nehmen Sie das Thema Arrays. Auch ein Kapitel für sich. In manchen Sprachen schwieriger, folglich fehleranfälliger. Und Arrays sind wichtig. Wenn man mit großen Datenmengen zu tun hat. Vor allem dann.
Die Wahl der Programmiersprache entscheidet über, ist eine Funktion, der Häufung der Programmierfehler. Außerdem gilt knallhart: mit steigender Zahl an Codezeilen, steigen auch die Programmierfehler. Und wie!! Manche Sprachen begünstigen Fehler leichter als andere. Eine Binsenweisheit.
Wer Fortran als Schnee von gestern bezeichnet, hat irgendetwas nicht richtig verstanden bzw. ist kein erfahrener Programmierer. Zu Erläuterung:
Fortran ist eine Programmiersprache, mit deren Hilfe ein Wissenschaftler oder auch Ingenieur Anweisungen formuliert (Code), die über den zugehörigen Compiler dem Rechenwerk des Computers vermittelt, was es ausrechnen soll. Das tut Fortran weitestgehend fehlerfrei. Das Problem fehlerhaften Arbeitens liegt fast immer beim programmierenden Wissenschaftler, der sich bemüht, (natürliche) Vorgänge in ein numerisches Verfahren zu gießen, welches letztlich vom Compiler in ein digitales Zahlenspiel übersetzt wird.
Fortran ist in vielen Bereichen noch immer die Programmiersprache der Wahl, aber wird leider kaum noch an Universitäten gelehrt.
Was nun genau am Covid-Computer-Modell des Imperial College faul ist, wird hier nicht dargelegt. Es ist mit Sicherheit nicht die Wahl der Programmiersprache.
Ja genau, man kann in jeder Programmiersprache Logikfehler machen oder Garbage in -> Garbage out usw. Formale Fehler wie z.B. nicht deklarierte Variablen oder auch Spagetti Code (worauf das Bild wohl anspielen soll) werden von modernen Compilern ( Ubersetzungsprogramme vom Pseudoenglisch Code z.B. Fortran in Maschinencode des Computers) abgefangen, auch von Fortran Compilern. Vor 20/40 Jahren waren die Compiler noch nicht so intelligent und haben viele formale Fehler durchgehen lassen. Damals gab es allerdings auch noch nicht so viele Programmiersprachen, eine der wenigen war Fortran und der alte Code von damals hat wohl daher seinen schlechten Ruf. Einmal durch moderne Compiler jagen sollte die formalen Fehler aber aufspüren. Die eigentliche Frage beim Imperial College Code ist deswegen: ist das neuer Fortan Code -> kein Problem. Ist das alter Code und ist zwischenzeitlich nicht neu compiliert worden -> potentielles Problem.
Stimmt. Habe Informatik studiert. Die Programmierung ist entscheidend, nicht die Sprache.
@Annette Schubert, ach was.
Ich „befehle“ Ihnen, von nun an, nur noch in Assembler zu programmieren.
Danach werden Sie so einen Kommentar (hoffentlich) nie wieder von sich geben.
Ergänzung:
Jeder Programmierer macht in jeder Programmiersprache auf jeder Systemplattform irgendwelche Fehler … das war immer so und wird so bleiben. Reduzieren läßt sich das nur durch Testen – Prüfen -Testen – Prüfen – Testen … usw. … was bei umfangreichen wissenschaftlichen Rechenmodellen / Prognosen / „mit der Hand am Arm“ schon schwierig ist.
Mit wachsender Anzahl von variablen Parametern und der Datenmenge wächst das Problem …
Aber: Wenn das Konzept schon fehlerhaft ist und dann noch unschlüssige Daten einfließen gilt das immer noch gültige Grundprinzip – Mist rein = Mist raus 🙂
Bitte hier nur unter vollem Klarnamen posten, siehe Regeln.
@Heino Müller
Ich stimme Ihnen zu. Man kann selbstverständlich auch andere Programmiersprachen benutzen. Fortran ist sehr alt, was aber nicht dagegen spricht, es zu benutzen.
Die Kritik ist berechtigt. Es kommt nicht auf die Programmiersprache an, sondern wie man sie nutzt.