Erhöhung der Archivierungslebensdauer von Code

Gibt es eine veröffentlichte Liste bewährter Verfahren zur Gewährleistung der Langlebigkeit von Code mit Blick auf reproduzierbare wissenschaftliche Ergebnisse? (z. B. Open Source, Dokumentationspraktiken, Auswahl von Abhängigkeiten, Auswahl einer Sprache, virtueller Maschinen usw.).

Kennen Sie Studien (oder fehlen diese, Beispiele / Anekdoten), die versucht haben, die Halbwertszeit von typischem wissenschaftlichem Code oder anderer Software abzuschätzen (wenn das überhaupt eine vernünftige Frage ist?)

Die geplante Langlebigkeit von TeX fällt mir ein:

„Seit diesen Anfängen im Jahr 1977 wurde das von mir begonnene TeX-Forschungsprojekt von zwei Hauptzielen vorangetrieben. Das erste Ziel war Qualität: Wir wollten Dokumente produzieren, die nicht nur schön, sondern auch die besten sind. (…) Das zweite Hauptziel war die Archivierung: Systeme zu schaffen, die so weit wie möglich unabhängig von Änderungen in der Drucktechnologie sind. Als die nächste Generation von Druckgeräten auf den Markt kam, wollte ich die bereits erreichte Qualität beibehalten können, anstatt alle Probleme neu lösen zu müssen. Ich wollte etwas entwerfen, das in 100 Jahren noch brauchbar ist. ”- Donald E. Knuth: Digitale Typografie, p. 559 (zitiert aus http://de.wikipedia.org/wiki/TeX )

Basierend auf Knuths Büchern über digitale Typografie sollte sogar eine vollständige Neuimplementierung von TeX und METAFONT möglich sein. Sie enthalten Anmerkungen und Erklärungen für den gesamten Code.

Wenn Sie verlangen, dass Ihre Ergebnisse über Jahrzehnte stabil bleiben, geraten Sie in eine Art eiskaltes Dilemma. Einerseits möchten Sie es einfach machen, Ihre Ergebnisse zu 100% zu reproduzieren, damit Sie Ihre Software / Umgebung einfrieren. Auf der anderen Seite wird jemand, der daran interessiert ist, Ihre Ergebnisse in Zukunft zu reproduzieren, sicherlich darauf aufbauen wollen. Diese Person wird mit sehr alter Software stecken bleiben, was es sehr schwierig macht, etwas zu ändern. Für alles, was auf mehreren externen Paketen aufbaut, reichen bereits einige Jahre aus, um die Dinge praktisch unveränderlich zu machen.

Für TeX wird das Einfrieren im Artikel von 1990 angekündigt

Die Zukunft von TEX und METAFONT http://www.ntg.nl/maps/05/34.pdf

"Ich bin der festen Überzeugung, dass ein unveränderliches System von großem Wert ist, auch wenn es selbstverständlich ist, dass jedes komplexe System verbessert werden kann. Daher halte ich es für unklug, weitere" Verbesserungen "an den Systemen TEX und METAFONT vorzunehmen. Betrachten wir diese Systeme als Fixpunkte, die in 100 Jahren die gleichen Ergebnisse liefern sollten, die sie heute produzieren. "

Das ideale System würde Reproduzierbarkeit mit Veränderbarkeit verbinden. Der Versuch, so eigenständig, einfach und erprobt wie möglich zu sein, hilft sicherlich.

Verzeihen Sie mir, wenn ich zu sehr von der ursprünglichen Frage abwich. [Kreuz gepostet von 'Scientists for Reproducible Research', reproducible-research@googlegroups.com]

Es gibt viele technische Herausforderungen, die es äußerst schwierig machen, eine genaue Bit-für-Bit-Reproduzierbarkeit der Rechenergebnisse zu erreichen.

Auf Softwareebene können Änderungen am Code oder an einer der vom Code verwendeten Bibliotheken offensichtlich dazu führen, dass unterschiedliche Ergebnisse erzielt werden. Sie werden überrascht sein, wie viele Support-Bibliotheken zu einem typischen wissenschaftlichen Code verknüpft werden können.

Auf einer niedrigeren Ebene kann das Neukompilieren eines Codes oder einer der vom Code verwendeten Bibliotheken mit einem neuen Compiler oder mit aktivierten verschiedenen Compileroptimierungen ebenfalls Probleme verursachen. Ein Grund ist, dass verschiedene Operationen im Code möglicherweise in einer anderen Reihenfolge ausgeführt werden, wenn der Code neu kompiliert wird. Da die Gleitkommaaddition nicht assoziativ ist (a + b) + c <> a + (b + c), kann dies zu unterschiedlichen Ergebnissen führen.

OK, was ist, wenn wir die gesamte Softwareumgebung (Betriebssystem, Bibliotheken und kompilierten Code) erhalten, indem wir sie (z. B.) auf eine bootfähige CD-Rom brennen, auf der der Code ausgeführt wird? Können wir jetzt sicher sein, dass wir die gleichen Ergebnisse erzielen, wenn wir diesen Code auf einem anderen Computer ausführen?

Überraschenderweise variieren einige Codes tatsächlich die Reihenfolge der Berechnungen basierend auf Aspekten des jeweiligen Prozessormodells, auf dem sie ausgeführt werden. Beispielsweise lösen optimierte lineare Algebra-Bibliotheken normalerweise Matrixmultiplikationen auf, um an Blöcken zu arbeiten, die in den Cache passen. Wenn Intel einen neuen Mikroprozessor mit einem größeren Cache veröffentlicht, passt der Code möglicherweise die Blockgröße dynamisch an, was zu einer Arithmetik führt, die in einer anderen Reihenfolge ausgeführt wird und unterschiedliche Ergebnisse liefert. Andere Codes passen die Reihenfolge der Berechnungen dynamisch an die Größe des verfügbaren Speichers an. Wenn Sie den Code auf einem Computer mit mehr Speicher ausführen, kann dies dazu führen, dass die Arithmetik in einer anderen Reihenfolge ausgeführt wird und somit unterschiedliche Ergebnisse erzielt werden.

Die Dinge werden erstaunlich komplizierter, wenn Sie Multithread-Code einwerfen, da der genaue Ausführungsverlauf der verschiedenen Threads häufig nicht deterministisch ist und dies wiederum dazu führen kann, dass arithmetische Operationen von Lauf zu Lauf in einer anderen Reihenfolge ausgeführt werden.

In der Praxis können Sie höchstens auf Ergebnisse hoffen, die von einer Maschine zur nächsten ähnlich sind, bis hin zu den Genauigkeitstoleranzen der verwendeten Algorithmen. Wenn ich beispielsweise ein Problem mit der Wurzelfindung habe und die Halbierung verwende, um eine Wurzel auf + -1,0e-10 zu bringen, sollte ich glücklich sein, solange verschiedene Maschinen Antworten liefern, die innerhalb dieser Toleranz übereinstimmen.

Es gab viele Versuche, Reproduzierbarkeit zu erreichen, und es gibt eine ganze Literatur zu diesem Thema. Meine persönliche Meinung aus 15 Jahren wissenschaftlicher Software ist, dass es unrealistisch ist, so unbefriedigend, wie ich diese Antwort finde. Die Probleme sind, dass (i) komplexe Software Fehler aufweist und daher nicht eingefroren werden kann; (ii) Software ist niemals vollständig und die Entwicklung wird fortgesetzt. (iii) Welchen Wert hat es, mit einem Papier mehrere hunderttausend Codezeilen zu liefern?

Wie gesagt, ich finde diese Antwort unbefriedigend. Ich glaube, dass die Computerwissenschaft als Fachgebiet nicht sehr erfolgreich Literatur produziert hat, die das Vertrauen weckt, dass die von uns veröffentlichten Ergebnisse korrekt und reproduzierbar sind. Gleichzeitig kann ich mir keine Möglichkeiten einfallen lassen, um die Dinge besser zu machen. Natürlich ist es nützlich, den zu einem Papier gehörenden Quellcode freizugeben. Gleichzeitig wird jeder, der ehrlich ist, zustimmen, dass die Ergebnisse in einem Papier normalerweise von verschiedenen Versionen des Codes erzeugt werden, die in den meisten Fällen Hacks enthalten, die unterschiedliche Randbedingungen, unterschiedliche rechte Seiten usw. beschreiben. Ein Papier würde dann kommen mit verschiedenen Versionen des gleichen Codes. Dies ist für den Leser zunächst unangenehm, Aber es ist geradezu unproduktiv, wenn der Code so groß ist, wie es heute häufig vorkommt. In meinen beiden jüngsten Veröffentlichungen wurden Codes verwendet, die etwa 20.000 Codezeilen umfassen und auf Deal.II (600.000 Codezeilen) und Trilinos (1,5 Millionen Zeilen) aufbauen von Code). Welche Informationen liefert das einem potenziellen Leser? (Ich sollte sagen, dass meine Codes trotzdem verfügbar sind.)

Eine mögliche Lösung für dieses Problem finden Sie in meinem ActivePapers- Projekt. Zusammenfassend wird beschrieben, wie Daten und Code zusammen mit expliziten Abhängigkeiten von bestimmten Versionen jeder Softwarekomponente gepackt werden können. Dies ermöglicht es, eine Berechnung exakt zu reproduzieren und gleichzeitig aktualisierte Software mit denselben Daten auszuführen.

Ich sollte hinzufügen, dass ActivePapers nur ein Proof of Concept ist und in naher Zukunft wahrscheinlich keinen praktischen Nutzen haben wird. Der Grund ist, dass es auf dem Prinzip basiert, dass der gesamte ausführbare Code als JVM-Bytecode existieren muss. Dies schließt derzeit zu viele populärwissenschaftliche Bibliotheken aus. Sobald jedoch die Reproduzierbarkeit als wichtig erkannt wird, können sich auch die Prioritäten in den Programmierwerkzeugen ändern.

Ich glaube, dass in Bezug auf die Wahl der Sprache die Verwendung einer standardisierten Sprache (z. B. C / Fortran / C ++) als "Best Practice" gelten würde. Wenn ein Paket von 10 anderen Bibliotheken / Paketen abhängt, insbesondere von solchen, die in obskuren Sprachen geschrieben sind, ist dies offensichtlich schlecht für die Langlebigkeit. Viele Projekte werden nach einiger Zeit verwaist. Ich glaube nicht, dass wichtige Bibliotheken / APIs wie BLAS / LAPACK, PETSc, FFTW, MPI usw. bald verschwinden würden. BLAS ist schon ziemlich alt.

Der folgende Code (gestohlen von http://www.math.utah.edu/software/c-with-fortran.html ) ist älter als Fortran 77, verwendet Hollerith-Konstanten für die Manipulation von Zeichen, kompiliert aber 40-50 Jahre später mit der GNU Fortran Compiler:

stali@x61:~$ cat olde.f

       CALL S(12HHello, world, 12)
       END
       SUBROUTINE S(MSG,N)
       INTEGER K, N, M
       INTEGER MSG(1)
       M = (N + 3) / 4
       WRITE (6,'(20A4)') (MSG(K), K = 1,M)
       END

stali@x61:~$ gfortran -std=legacy olde.f; ./a.out
Hello, world

Open Sourcing / Platzierung irgendwo wie Google Code, der weniger wahrscheinlich bald verschwindet (obwohl die Codesuche beendet wurde), ist ein Kinderspiel.