Reproduzierbarkeit – Wissenschaftliche Arbeit als Software-Projekt

Wer darüber etwas nachdenkt kommt schnell zu dem Schluss, dass das Problem nicht vollständig lösbar ist: Selbst im längsten Methoden-Teil wären nicht alle Faktoren auflistbar, die zum Zeitpunkt der Durchführung eines Experiments dessen Ausgang beeinflusst haben könnten. Das Streben nach Reproduzierbarkeit muss also in vielen Bereichen der Wissenschaft eine Bemühung bleiben. Eine die bei guter Wissenschaft möglichtst ernst genommen wird!

Ein erster Ansatz zur Reproduzierbarkeit von statistischen Analysen bildet beispielsweise die Verwendung eines Kommandozeilen-basierten Systems. Analysen können dann in einem Skript automatisiert werden. Das ist sicher ein großer Fortschritt auf dem Weg zur Reproduzierbarkeit, denn das Skript produziert aus den Rohdaten Tabellen und Grafiken auf eine wiederholbare Weise. Doch selbst dies gewährleistet keine vollständige Reproduzierbarkeit: Nicht das Skript wird veröffentlicht, sondern eine -im Besten Fall sehr direkt- daraus abgeleitete “literarische” Arbeit, Ausgaben müssen kopiert, Grafiken eingefügt werden.
Selbst wenn eine oder mehrere Skripte der Veröffentlichung beigefügt sind, bleiben Probleme: In welcher Reihenfolge sind sie auszuführen, aus welchen Analysen wurden welche Werte extrahiert und wie bekomme ich das Ganze auf meinem System zum laufen? 

Im wissenschaftlichen Alltag sieht es zudem häufig so aus, dass per Kopieren und Einfügen Zahlen in ein Paper wandern, Grafiken werden häufig über den Umweg eins Grafik-Manipulations-Programm (das hört sich schonmal schön unwissenschaftlich an) in das Paper gebracht und Einzelergebnisse häufig auch von verschiedenen Personen und verschiedenen Betriebs-Systemen beigesteuert.
An allen Schnittstellen zwischen Mensch und Maschine entstehen so Möglichkeiten für Fehler: Der falsche Wert wurde kopiert, die Achse nicht korrekt beschriftet oder gar die falsche Datei eingelesen. Ein Problem, selbst für den einzelnen, der sich nur selbst kontrollieren also wiederholen -nur replizieren nicht reproduzieren- möchte.

Einen Ansatz zur Lösung dieses Problems kommt durch Softwareentwickler, die vor einem verwandten Problem stehen. Um ihren Code weiterzuentwickeln und nutzbar zu machen müssen ihn nicht nur Assembler und Compiler (das sind die “magischen” Dinge, die Programmiersprachen in etwas übersetzen, was der Computer versteht) sondern auch Menschen lesen können. Daher Donald Knuths Idee, des “literate Programming”: Kurz gesagt sollen Kommentare, die dem Menschen erklären, was der Programmcode macht in einer Layout-Sprache wie LaTeX in das Programm integriert werden. Das Ergebnis sind so genannte Noweb-“Mischdokumente” von Layout und Programm-Code.

Integration in R

Friedrich Leisch hat dieses System nun in in einem R-Paket namens Sweave umgesetzt. Es ermöglicht die einfache Integration von R und LaTeX-Code.
Bilder, Tabellen (mit Hilfe des genialen R-Pakets xtable) und sogar einzelne Zahlen direkt im Text, können so in jedem Kompilierzyklus neu aus den Rohdaten berechnet werden.
Die Mischdokumente von R und LaTeX-Code -R Noweb oder kurz .Rnw- werden von der Kommandozeile

R CMD Sweave deineDatei.Rnw

in ein .tex Dokument verwandelt.

Dieses System findet in der Dokumentation von R breite Anwendung. Sie so genannten “Vignetten”, die beispielsweise im Bioconductor-Projekt für jedes Paket verfügbar sind, sind mit dem System geschrieben. Doch nicht nur über R lässt sich damit schreiben, auch Dokumente, die den Code nur ausführen, nicht zeigen sind möglich.

Ein komplexes Beispiel

Um ein solches R/sweave Dokument zu erklären möchte ich nun ein Beispiel nutzen an dem ich in der letzten Woche gearbeitet habe.
Auf meinem Git-Rpository auf Github kann man ein solches Beispiel anschauen. Ich würde mich freuen, wenn jemand versuchen würde die Präsentation aus den Rohdaten zu reproduzieren (wie man mit git arbeitet wird auf Github gut erklärt. Leider hab ich aus Platzgründen das Projekt mit den umfangreichen Rohdaten von GitHub nehmen müssen. Hier ist das

pdf

und hier die

Sweave source Datei

Falls jemand wirklich versuchen möchte das ganze zu reproduzieren, kann er von mir auch noch die Rohdaten haben.

Ich habe absichtlich ein nicht triviales Beispiel verwandt, die Präsentation und das Repository enthalten fast alle Daten, die meine Doktorarbeit bisher produziert hat! Das ist vor allem eine Liste mit 6 Millionen Sequenz-tags zur Genexpressionsanalyse. Bei größeren Projekten mit intensiveren Rechenprozessen stellt die Notwendigkeit zur Neuberechnung nach jeder Änderung im Layout natürlich schnell eine Beschränkung dar (Es gibt in meiner Präsentation einen Rechen-Schritt der 3 Stunden in Anspruch nimmt).
Wer das System zunächst mit weniger komplizierten Dokumenten testen will, wird im Netz viele einfachere Beispiele finden, für LaTeX Artikel aber auch für Präsentationen.

Die R Code Schnipsel werden durch folgende Syntax erkannt.

<< optionen = TRUE/FALSE >>=

Rcode.bespiel <- “hier”

@

wobei man mit optionen wie fig, tex, echo, cache (dazu gleich mehr) etc… das Verhalten, die Art der Umsetzung des Code-Schnipsels steuert: Wird der R-Code ins pdf übernommen, der Output, oder eine Grafik.

Wer sich an solch komplexe Dokumente wagt wird schnell feststellen, dass er nicht nach jeder Änderung im LaTeX-Code alle Berechnungen neu ausführen möchte:
Die Möglichkeit, das System auch für zeitraubende Rechenoperationen zu nutzen kommt erst durch ein “cachen” d.h. Zwischenspeichern von einmal eingelesenen oder erzeugten R-Objekten zustande.

Daher auch die Komplexität und Größe der Datensätze in meinem Repo, ich wollte einfach sehen, was alles möglich ist. Die Antwort: Alles! Es funktioniert! Ein Rekompilieren des “dynamischen Dokuments” dauert unter Nutzung des Caches etwa 20 Sekunden…

Die Vorteile des Systems

Mein Code wird besser! Es ist oft ein langer Weg von einem Perl-Skript über R und Latex zum pdf, dieser wird durch das System nachvollziehbarer. Man will eine spezielle Tabelle oder Grafik erzeugen und schreibt den Code dann wirklich dafür – das ist oft schwer wenn man das pdf nicht vor Augen hat. Ein Beispiel dafür sind die Skripte, die sich hinter

<< cache = TRUE >>=

S <- as.data.frame(read.delim(pipe(“./pilot.pl”),
sep=”,”,
header=FALSE,
as.is=TRUE))
@

verstecken. Ich habe die Perl-Skripte geschrieben, noch bevor ich das System nutzte, sie enthalten viele unnötig komplexe Datenstrukturen, die nicht wirkliche gebraucht werden.
Im Code den ich für das System geschrieben habe (besonders in dem ausgeführten Perl-Skript) gehe ich viel zielgerichteter vor.

<< cache = TRUE, echo = FALSE >>=

cov454 <- as.data.frame(read.delim(pipe(“./tgicl_coverage.pl -a Ac_FM08.ace -s singletons.fasta”)))

exp <- merge(exp.tab,cov454)

exp_plot <- qplot(exp$raw.count, exp$coverage)+ scale_x_log10(“number of tags observed”)+ scale_y_log10(“Coverage by 454″)+ geom_smooth(method=”lm”)

@

Hier wird auch deutlich, dass für die Produktion von Publikationen R den präziseren, besseren Code erlaubt. Die Datenstrukturen sind einfach übersichtlicher als in den meisten anderen Programmiersprachen. Eines meiner Ziele wird daher sein Helferskripte klein zu halten und mehr Code direkt in R zu schreiben.

Als weiteren Effekt habe ich einfach mehr Ordnung³! Ich weiß wo mein Code ist und dass es die richtige Version des Codes ist.

Weiter Herausforderungen

Durch Nutzen der R-Funktion pipe, die ein Kommando des Betriebssystems ausführen kann werden alle Werkzeuge auch außerhalb von R nutzbar. Man kann so eigene SKripte oder komplexe Programme auszuführen um Datenobjekte einzulesen. Solcher Input-Code stellt dann aber wieder eine Herausforderung für die gecachten Objekte dar:
Änderungen an Helferskripten sollten vor Nutzung der gespeicherten Objekte kontrolliert werden. Bei einer Änderung in einem Skript, Programm oder den Rohdaten sollten die gespeicherten Objekte nur nach Ausgabe einer Warnung benutzt werden und gegebenenfalls auf einer Löschung und Neuberechnung der Objekte bestanden werden. 

Das könnte man umsetzen indem man bei der Kompilierung der Rnw Datei ein Prüfsummen-verfahren auf alle Dateien (ausführbare Dateien und die Rohdaten), die in der pipe eines gespeicherten Objekts vorkommen, anwendet.

Durch die dargestellte Arbeitsweise wird der komplette Prozess der Erstellung einer Publikation zu einem Software-Projekt. Es gelten damit viele der Maximen, die auch bei solchen Projekten gelten. Ein Beispiel ist die Portabilität: Das Dokument sollte möglichst auf verschiedenen Betriebssystemen reproduzierbar sein, nicht nur aus heeren Idealen sondern auch zum Schutz vor Problemen mit der eigenen Hard- und Software.

______________________________________________________________________________________________________________________

1 Die Antwort auf diese Frage ist eigentlich ein entschiedenes “Jain”, da Approximationsalgorithmen nur gleich gute, nicht exakt gleiche Ergebnisse liefern.

2 Die Hardwareanforderungen sind allerdings etwas haarig, ich bin mir nicht sicher, aber 4GB Arbeitsspeicher sollten ausreichen.

3 Ich habe erst für diese Projekt angefangen ein Versionskontrollsystem (Git) zu benutzen, ich bin gespannt ob es im Zusammenspiel mit dem R/Sweave-System weiter Vorteile, wie das Teilen des Caches zwischen verschiedenen Rechnern gibt. Das Zurückgehen in der History (mitsamt den pdfs) ist ein großer Vorteil: kein Erneutes Kompilieren des alten Dokuments.

» von Emanuel Heitlinger