Cómo aumentar la reproducibilidad a largo plazo de la investigación (particularmente usando R y Sweave)


31

Contexto: en respuesta a una pregunta anterior sobre investigación reproducible, Jake escribió

Un problema que descubrimos al crear nuestro archivo JASA fue que las versiones y los valores predeterminados de los paquetes CRAN cambiaron. Entonces, en ese archivo, también incluimos las versiones de los paquetes que utilizamos. El sistema basado en viñetas probablemente se romperá cuando la gente cambie sus paquetes (no estoy seguro de cómo incluir paquetes adicionales dentro del paquete que es el Compendio).

Finalmente, me pregunto qué hacer cuando R cambia. ¿Hay formas de producir, por ejemplo, una máquina virtual que reproduzca todo el entorno computacional utilizado para un papel de modo que la máquina virtual no sea enorme?

Pregunta:

  • ¿Cuáles son buenas estrategias para garantizar que el análisis de datos reproducibles sea reproducible en el futuro (por ejemplo, cinco, diez o veinte años después de la publicación)?
  • Específicamente, ¿cuáles son buenas estrategias para maximizar la reproducibilidad continua al usar Sweave y R?

Esto parece estar relacionado con la cuestión de garantizar que un proyecto de análisis de datos reproducible se ejecute en la máquina de otra persona con valores predeterminados, paquetes, etc.


¿Ha considerado las pruebas unitarias con RUnit para verificar el comportamiento teórico?

Respuestas:


18

En algún nivel, esto se vuelve imposible. Considere el caso del famoso error de punto flotante Pentium: no solo necesita conservar sus modelos, sus datos, sus parámetros, sus paquetes, todos los paquetes externos, el sistema host o el idioma (por ejemplo, R), así como el sistema operativo ... .más potencialmente el hardware con el que se ejecutó todo. Ahora considere que algunos resultados pueden estar basados ​​en la simulación y requieren un grupo particular de máquinas ...

Eso es solo un poco por ser práctico.

Dicho esto, creo que las soluciones más pragmáticas de versionar su código (y tal vez también sus datos) en el control de revisiones, almacenar versiones de todo el software relevante y hacer posible reproducir los resultados ejecutando un solo script de nivel superior puede ser un " suficientemente bueno "compromiso.

Su experiencia puede ser diferente. Esto también difiere según las disciplinas o la industria. Pero recuerde la vieja opinión sobre la imposibilidad de los sistemas infalibles: simplemente crea tontos más inteligentes.


1
(+1) Solo puedo estar de acuerdo contigo. Acerca de R específicamente, parece muy difícil asegurarse de que (a) algunos cálculos seguirán siendo reproducibles después de actualizar un paquete (que me sucede recientemente), y (b) no surgirá ningún conflicto con las dependencias algún día (fue el caso, por ejemplo, para lme4).
chl

13

El primer paso en la reproducibilidad es asegurarse de que los datos estén en un formato que sea fácil de leer para futuros investigadores. Los archivos planos son la opción clara aquí (Fairbairn en prensa).

Para que el código sea útil a largo plazo, quizás lo mejor sea escribir una documentación clara que explique lo que hace el código y también cómo funciona, de modo que si su cadena de herramientas desaparece, su análisis se puede volver a implementar en algún sistema futuro .


1
De acuerdo, datos sólidos y metadatos primero.
mindless.panda

11

Una estrategia implica usar el cacherpaquete.

  • Peng RD, Eckel SP (2009). "Investigación reproducible distribuida utilizando cálculos en caché", IEEE Computing in Science and Engineering, 11 (1), 28–34. ( PDF en línea )
  • ver también más artículos en el sitio web de Roger Peng

Se pueden encontrar más discusiones y ejemplos en el libro:

Sin embargo, no tengo experiencia de primera mano de su efectividad para garantizar la reproducibilidad continua.


7

Si está interesado en la ruta de la máquina virtual, creo que sería factible a través de una pequeña distribución de Linux con la versión específica de R y los paquetes instalados. Los datos se incluyen, junto con los scripts, y empaquetan todo en un archivo de caja virtual .

Esto no evita los problemas de hardware mencionados anteriormente, como el error de la CPU Intel.


4

Recomendaría dos cosas además de las excelentes respuestas ya presentes;

  • En los puntos clave de su código, deseche los datos actuales como un archivo plano, adecuadamente nombrado y descrito en los comentarios, resaltando así si un paquete ha producido resultados diferentes donde se han introducido las diferencias. Estos archivos de datos, así como la entrada original y la salida resultante deben incluirse en su 'conjunto de investigación reproducible'

  • Incluya algunas pruebas de los paquetes en cuestión dentro de su código, por ejemplo, usando algo como TestThat . La parte difícil es hacer pruebas pequeñas y reproducibles que puedan resaltar cualquier cambio en lo que hace un paquete relacionado con su análisis. Esto al menos resaltaría a otra persona que hay alguna diferencia en los entornos.


1

Buenas sugerencias, tengo muchas cosas que analizar ahora.

Recuerde, una consideración extremadamente importante es asegurarse de que el trabajo sea "correcto" en primer lugar. Este es el papel que juegan herramientas como Sweave , al aumentar las posibilidades de que lo que hiciste y lo que dijiste que hiciste sea lo mismo.


1
El proyecto de Sumatra también puede ser útil: neuralensemble.org/trac/sumatra/wiki . Puede usar su interfaz de línea de comandos para ejecutar su código, estar en R o algo más. También hay una API de Python. Hay una buena publicación de blog sobre R-bloggers que discute herramientas centradas en R para la investigación reproducible, y también menciona el uso de Sumatra. r-bloggers.com/managing-a-statistical-analysis-project- –-guidelines-and-best-
Practices
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.