Come aumentare la riproducibilità a lungo termine della ricerca (in particolare utilizzando R e Sweave)

Contesto: in risposta a una domanda precedente sulla ricerca riproducibile, ha scritto Jake

Un problema che abbiamo scoperto durante la creazione del nostro archivio JASA è stato il cambiamento delle versioni e dei valori predefiniti dei pacchetti CRAN. Quindi, in quell'archivio, includiamo anche le versioni dei pacchetti che abbiamo usato. Il sistema basato sulla vignetta si romperà probabilmente man mano che le persone cambiano i loro pacchetti (non sono sicuro di come includere pacchetti extra nel pacchetto che è il Compendio).

Infine, mi chiedo cosa fare quando R stessa cambia. Esistono modi per produrre, per esempio, una macchina virtuale che riproduca l'intero ambiente di calcolo utilizzato per un documento in modo tale che la macchina virtuale non sia enorme?

Domanda:

• Quali sono le buone strategie per garantire che l'analisi dei dati riproducibili sia riproducibile in futuro (diciamo, cinque, dieci o venti anni dopo la pubblicazione)?
• In particolare, quali sono le buone strategie per massimizzare la riproducibilità in corso quando si utilizzano Sweave e R?

Ciò sembra essere correlato al problema di garantire che un progetto di analisi dei dati riproducibile verrà eseguito sulla macchina di qualcun altro con valori predefiniti, pacchetti, ecc. Leggermente diversi

Ad un certo livello, questo diventa impossibile. Prendi in considerazione il caso del famoso bug Pentium in virgola mobile: non devi solo conservare i tuoi modelli, i tuoi dati, i tuoi parametri, i tuoi pacchetti, tutti i pacchetti esterni, il sistema host o la lingua (diciamo, R) e il sistema operativo. e potenzialmente anche l'hardware su cui tutto funzionava. Ora considera che alcuni risultati possono essere basati sulla simulazione e richiedono un particolare cluster di macchine ...

È solo un po 'troppo per essere pratico.

Detto questo, penso che soluzioni più pragmatiche di controllo delle versioni del tuo codice (e forse anche dei tuoi dati) nel controllo delle revisioni, l'archiviazione delle versioni di tutti i software pertinenti e la possibilità di riprodurre i risultati eseguendo un singolo script di livello superiore potrebbero essere un " abbastanza buono "compromesso.

Il tuo chilometraggio può variare. Ciò differisce anche per discipline o settori. Ma ricorda la vecchia visione sull'impossibilità di sistemi infallibili: crei semplicemente stupidi più intelligenti.

Il primo passo nella riproducibilità è assicurarsi che i dati siano in un formato che sia facile da leggere per i futuri ricercatori. I file flat sono la scelta chiara qui (Fairbairn in stampa).

Per rendere utile il codice a lungo termine, forse la cosa migliore da fare è scrivere una documentazione chiara che spieghi sia cosa fa il codice sia anche come funziona, in modo che se la catena degli strumenti scompare, l'analisi può essere reimplementata in un sistema futuro .

• Fairbairn (in corso di stampa) L'avvento dell'archiviazione obbligatoria dei dati . Evolution DOI: 10.1111 / j.1558-5646.2010.01182.x

Una strategia prevede l'utilizzo del cacherpacchetto.

• Peng RD, Eckel SP (2009). "Ricerca riproducibile distribuita utilizzando calcoli memorizzati nella cache", IEEE Computing in Science and Engineering, 11 (1), 28–34. ( PDF online )
• vedere anche altri articoli sul sito Web di Roger Peng

Ulteriori discussioni ed esempi sono disponibili nel libro:

• Metodi statistici per epidemiologia ambientale con R

Tuttavia, non ho esperienza diretta della sua efficacia nel garantire la riproducibilità in corso.

Se sei interessato al percorso della macchina virtuale, penso che sarebbe fattibile tramite una piccola distribuzione Linux con la versione specifica di R e pacchetti installati. I dati sono inclusi, insieme agli script, e impacchettano il tutto in un file box virtuale .

Questo non aggira i problemi hardware menzionati in precedenza come il bug della CPU Intel.

Consiglierei due cose oltre alle eccellenti risposte già presenti;

• Nei punti chiave del codice, scaricare i dati correnti come file flat, opportunamente denominato e descritto nei commenti, evidenziando così se un pacchetto ha prodotto risultati diversi in cui sono state introdotte le differenze. Questi file di dati, nonché l'input originale e l'output risultante dovrebbero essere inclusi nel "set di ricerca riproducibile"

• Includi alcuni test dei pacchetti interessati nel tuo codice, ad esempio usando qualcosa come TestThat . La parte difficile è fare piccoli test riproducibili che rischiano di evidenziare eventuali cambiamenti in ciò che un pacchetto fa in relazione alla tua analisi. Ciò evidenzierebbe almeno a un'altra persona che esiste qualche differenza negli ambienti.

Buoni suggerimenti, ho un sacco di cose da esaminare ora.

Ricorda, una considerazione estremamente importante è assicurarsi che il lavoro sia "corretto" in primo luogo. Questo è il ruolo che svolgono strumenti come Sweave , aumentando le possibilità che ciò che hai fatto e ciò che hai detto di fare siano la stessa cosa.