Gunter Frank, Gastautor / 18.05.2020 / 14:00 / Foto: Achgut.com / 80 / Seite ausdrucken

Der alte Code und das neue Virus – mit Aktualisierung

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.

Foto: Achgut.com

Sie lesen gern Achgut.com?
Zeigen Sie Ihre Wertschätzung!

via Direktüberweisung
Leserpost

netiquette:

Michael Scheffler / 19.05.2020

Herr Dörre, ich gebe Ihnen Recht: FORTRAN allein sagt nichts über einen schlechten Code aus. Finite-Elemente-Codes haben diese Sprache häufig noch als Schnittstelle. Sie ist nu r nicht für Objektorientierung, Vererbung etc. geeignet. Aber ein gekoppeltes Differenzialgleichungssystem kann man lösen. Und um mehr geht es nicht . Warum man aber nicht MATLAB genutzt hat, sei dahingestellt.

Johannes Schumann / 19.05.2020

Ich habe jetzt viele Kommentare gelesen, die Fortran in Schutz nehmen. Sicherlich ist nicht Fortran alleine schuld, aber sich auf Legacy-Programme verlassen, die in C++ konvertiert werden (was man auch von Eiffel her kennt), ist äußerst kritisch. Oft ist es besser, eine Software von vorne neu zu durchdenken und in einer modernen Sprache mit Zukunft zu schreiben. Ich schreibe beruflich ja selber Software, und leider darunter, dass man immer wieder Legacy-Code mitschleppt. Oder dass C/C++-Entwickler ihre alten Programme fast 1:1 in Java umformulieren. Dann muss man nur an verschiedenen Definitionen für grundlegende Datentypen scheitern. Ich habe nun schon oft solchen Code gesehen und mir die Haare gerauft.

Johannes Schumann / 18.05.2020

Die hätten die Klima-Jungs modellieren, programmieren und simulieren sollen. Deren Modelle sind nie falsch, wenn man den Potilikern glauben darf. :-) Was Fortran angeht: Auch wenn sie genutzt wird, man sollte sie ablösen. Es gibt bessere Sprachen für Codequalität und numerisch rechnen können viele. Ich bin übrigens Informatiker und weiß, wovon ich rede. Oft werden diese alten Sprachen mit ihren veralteten Paradigmen mitgeschleppt, weil man Programmierer dafür hat. Es ist oft gut, hin und wieder einen Schnitt zu machen und es gibt so tolle Sprachen, die sauberer entworfen sind. In Java beispielsweise sind in den letzten Jahren immer mehr Features der funktionalen Sprachen hinzugekommen und es fühlt sich manchmal richtig unnatürlich an. Schlimm ist es auch, wenn C++-Entwickler auf Java umsteigen und meinen, sie könnten alles. Gut, die Syntax ist ähnlich, aber die ist nachrangig. Die Paradigmen sind wichtig. Fortran ist aber auch nicht das Schreckgespenst, wie es Cobol ist. Das wäre eine tolle Programmiersprache für die Kinder von Frau Baerbock, wenn die mal in die Programmierung schnuppern möchten.

Ernst Dinkel / 18.05.2020

Fortran als angeblichen “Schnee von gestern” veranwortlich zu machen ist Bullshit. Software kann fehlerhaft sein entweder aufgrund von Design-/Programmierfehlern, oder weil die eingesetzte Compiler-Version bzw. Bibliotheken buggy waren.  Dass dieses “Imperial College” Mist gebaut hat, kann natürlich sein, hat aber grundsätzlich nichts mit Fortran zu tun.

Wolfgang Sauer / 18.05.2020

Also das Fortran Argument als einziges heranzuziehen um die Software abzuwerten ist schon sehr schwach. Viele technisch/wissenschaftliche Software ist historisch gewachsen und hat im Kern immer noch Fortran Code, seien es Festigkeitsberechnungen für Maschinenteile, Brücken oder auch Stromungsmodelle/Klimamodelle. Wenn da etwas schiefläuft liegt es am fehlerhaften Code (Logikfehler) oder an unangepasster Anwendung (Randbedingungen passen nicht aufs Problem). Ich kenne allerdings aus meiner beruflichen Zeit etliche junge Programmierer welche entzückt von ihrem modernen Code die komplexe Abbildung der Realität - auch in altem Fortran Code - aus den Augen verlieren, etwa so als wäre z.B. eine englische Trivialität wahrer als eine komplexere deutsche Aussage.

S. Marek / 18.05.2020

Sehr geehrter Herr Gunter Frank, hier sind Sie auf dem Holzweg geraten. Nicht die Modellierung vom Hrn. Neil Ferguson ist für die unbedachten Chaos Verantwortlich sondern die eigene Unfähigkeit jeweiliger Länder und deren Regierungen überprüfte Anti-Pandelie-Pläne zu erstellen und entsprechende Vorsorge im Bezug auf technische Ausrüstung zu halten und entsprechend zu erneuern bzw. neuen wissenschaftlichen Anforderungen anzupassen. Da aber die Kommunistische Partei Chinas alles unternommen hat um den Leck aus dem Wuhan Institut zu vertuschen anstatt den Schaden einzugrenzen,mit freundlicher “Unterstützung” der WHO, kamen viele in der Einschätzung der Gefahr im Verzug bzw. ignorierten diese sträflich. Ein totaler “Lockdown” ist nach meiner Meinung schreckliche Fehlentscheidung.

Karsten Dörre / 18.05.2020

Computer machen das, was man ihnen befiehlt (Routine). Mariner-1-Venussonde scheiterte an einem Lese- und Eingabefehler beim Füttern des Computerprogramms. Fortran ist nicht schlechter als andere Programmiersprachen. Wird nicht oft verwendet, weil heutige Generationen Bilder, Graphiken und Buntes lieber mögen, weil schneller verständlich als meilenlange Texte zu übersetzen. Auch wenn Mariner-1 (unbemannte Raumfahrt der USA) scheiterte, wurden mit alten Programmiersprachen (Fortran) der Weg ins Weltall sowie zu Venus, Merkur und Mond bewerkstelligt. Ob die vergleichsweise mickrigen 18,5 Millionen Dollar Verlust bei Mariner-1 Maßstab sein sollen, ist fraglich. Die andere Feststellung, dass der verlorenen Leben bei Mariner-1 ist absurd. Beim Mariner-1-Desaster kam keine Person ums Leben.

Ralf Pöhling / 18.05.2020

@Thomas Roth Haben Sie vielleicht einen Link? Mit C++ kann ich umgehen. Sofern der Code einigermaßen strukturiert daherkommt. Fremdcode ist in der Tat bisweilen schwer zu lesen. Jeder Programmierer hat ja irgendwie seinen eigenen Stil.

Karsten Kaden / 18.05.2020

Herr Frank hat als Nicht-ITler den Artikel etwas unglücklich interpretiert. Nicht die Programmiersprache ist das Problem, sondern die damit erstellten Algorithmen. Diese reagieren, analog zu denen der Klimamodelle, sehr empfindlich auf geringste Änderungen der Eingangsparameter, sodaß die Ergebnisse bereits stark abweichen, wenn man die Simulation nur auf anderer Hardware laufen läßt. Zudem hat sich der Herr Ferguson in der Vergangenheit schon mehrmals dramatisch mit Vorhersagen geirrt (ein Schelm, wer hier an Drosten denkt). Wenn man dem Link bei “model appears to be totally unreliable” folgt, öffnet sich ein weiterer Artikel mit Details dazu. Die Paywall läßt sich übrigens mit deaktiviertem Javascript umgehen.

Ralf Pöhling / 18.05.2020

Ich habe mit Fortran nie etwas zu tun gehabt, ich komme aus der C/C++ Ecke. Aber ich weiß, dass es im universitären bzw. wissenschaftlichen Umfeld noch genutzt wird. Eine Programmiersprache wirft per se nicht unzuverlässige Ergebnisse aus. Es ist eine Frage, wie sauber und logisch der Code daherkommt (gilt auch für eventuell eingebundene Bibliotheken) und ob der Compiler fehlerfrei in Maschinencode übersetzt bzw. die genutzten CPUs im Rahmen ihrer Genauigkeit fehlerfrei laufen. Ich schätze, dass man mit Fortran wohl auf die Nutzung von Hauptprozessoren limitiert ist und das Einbinden externer Hardware, wie z.B. beim Numbercrunching mittels “missbrauchter” Grafikhardware unter C/C++, nicht möglich ist. Aber das hätte nur Konsequenzen in der Performance, nicht im Endergebnis. Setzt voraus, dass der Code gut Programmiert ist. Keine komplexere Software ist fehlerfrei. Keine. Bugs, die die Software zum Absturz bringen, sind zwar lästig, zeigen aber sofort auf, dass etwas nicht stimmt und führen dann dazu, dass man den Code solange debugged, bis er reibungslos läuft. Schlimmer sind Logikfehler, die das Programm nicht(!) abstürzen lassen, aber falsch rechnen und deshalb falsche Ergebnisse auswerfen. Bei einer Software, deren Berechnungen so komplex sind, dass sie vom Entwickler bzw. Softwaretester zur Laufzeit nicht mal eben auf den schnellen Blick gegengeprüft werden können, braucht es exorbitant genaue Planung und systemische Gegenprüfung beim Entwickeln. Wenn eine Grafiksoftware falsch rechnet, so ist dies auf dem Bildschirm natürlich sofort zu erkennen und führt allenfalls zu miserablen Verkaufszahlen. Bei einer Software, die kryptische Zahlenkolonnen auswirft, oder aus diesen Zahlenkolonnen eine Kurve zeichnet, ist ein grober Logikfehler in den Berechnungen nicht sofort ersichtlich und kann fatale Konsequenzen nach sich ziehen. Ich habe mich z.B. stets von der Entwicklung von Software für den medizinischen Bereich ferngehalten. Aus genau diesem Grund.

Weitere anzeigen Leserbrief schreiben:

Leserbrief schreiben

Leserbriefe können nur am Erscheinungstag des Artikel eingereicht werden. Die Zahl der veröffentlichten Leserzuschriften ist auf 50 pro Artikel begrenzt. An Wochenenden kann es zu Verzögerungen beim Erscheinen von Leserbriefen kommen. Wir bitten um Ihr Verständnis.

Verwandte Themen
Gunter Frank, Gastautor / 13.08.2020 / 11:00 / 75

Zweifelhafte Corona-Tests – und wie Panik geschürt wird

Die amerikanische Food and Drug Administration (FDA) hat eine aktuelle Warnung vor einem Coronatest mit besonders hohen falsch positiven Raten (3 Prozent) herausgegeben. Dies zeigt einmal…/ mehr

Gunter Frank, Gastautor / 08.08.2020 / 06:23 / 140

Die „Zweite Welle“: Kompetenzfrei und alarmistisch  

Bei inzwischen fast 600.000 Tests wöchentlich stieg der prozentuale Anteil der positiv Getesteten von 0,6 auf 1 Prozent an (Epidemiologisches Bulletin Seite 31). Daraus wird die „zweite Welle" konstruiert,…/ mehr

Gunter Frank, Gastautor / 23.07.2020 / 06:08 / 117

Bericht zur Coronalage 23.07.2020: Massentests und künstliche Wellen

Die Corona-Erkrankungs- und Todeszahlen entsprechen in Europa schon seit langem dem Auslaufen einer saisonalen viralen Atemwegsinfektion, die man gemeinhin Grippewelle nennt. Meist mit Zahlen, wie…/ mehr

Gunter Frank, Gastautor / 23.06.2020 / 06:25 / 110

Bericht zur Coronalage 23.06.2020: Rinderwahn

Die Winterepidemie ist vorbei. Aber Regierung und Medien hören einfach nicht auf, die angebliche Bedrohung am Leben zu erhalten und uns an der Rückkehr zu…/ mehr

Gunter Frank, Gastautor / 28.05.2020 / 06:25 / 156

Bericht zur Coronalage 28.05.2020

Die neuesten Zahlen bestätigen ziemlich eindeutig die These, dass wir es auch dieses Jahr mit einer Winterepidemie zu tun hatten, die im April ausläuft. In…/ mehr

Gunter Frank, Gastautor / 07.05.2020 / 06:10 / 93

Bericht zur Coronalage 07.05.2020

Mit diesem Beitrag möchte ich die medizinische Risikoanalyse mit der Sicht der medizinischen Praktiker abrunden. Es stehen mittlerweile die notwendigen Informationen zur Verfügung, um diese Analyse…/ mehr

Gunter Frank, Gastautor / 27.04.2020 / 12:00 / 84

Bericht zur Corona-Lage vom 27.04.2020

Wir reden nun über Zahlen, hinter denen immer Einzelschicksale stehen. Das weiß ich nur zu gut, da ich als Hausarzt immer schon Menschen beim Sterben…/ mehr

Gunter Frank, Gastautor / 22.04.2020 / 06:15 / 150

Bericht zur Coronalage vom 22.04.2020 – worauf wartet die Politik?

Risikoanalyse Ansteckungsgefahr Nun ist es offiziell, der Reproduktionsfaktor R sank schon vor dem Shutdown unter 1. Das ist der Zeitpunkt, ab dem ein an Corona-Covid-19 Erkrankter…/ mehr

Unsere Liste der Guten

Ob als Klimaleugner, Klugscheißer oder Betonköpfe tituliert, die Autoren der Achse des Guten lassen sich nicht darin beirren, mit unabhängigem Denken dem Mainstream der Angepassten etwas entgegenzusetzen. Wer macht mit? Hier
Autoren

Unerhört!

Warum senken so viele Menschen die Stimme, wenn sie ihre Meinung sagen? Wo darf in unserer bunten Republik noch bunt gedacht werden? Hier
Achgut.com