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

Question

Contexto: En respuesta a una pregunta anterior sobre la investigación reproducible Jake escribió

Un problema que descubrimos cuando crear nuestro archivo JASA fue que las versiones y los valores predeterminados de los paquetes de CRAN cambiaban. Así que, 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 mismo cambia. ¿Hay formas de de producir, digamos, una máquina virtual que reproduzca todo el entorno computacional utilizado para un papel de manera que la máquina virtual no sea no sea enorme?

Pregunta:

• ¿Cuáles son las buenas estrategias para garantizar que los análisis de datos reproducibles sean reproducibles en el futuro (digamos, cinco, diez o veinte años después de la publicación)?
• En concreto, ¿cuáles son las buenas estrategias para maximizar la reproducibilidad en curso cuando se utiliza Sweave y R?

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

Answer 1

A cierto nivel, esto se vuelve imposible. Considere el caso del famoso fallo del punto flotante del Pentium: no sólo necesita conservar sus modelos, sus datos, sus parámetros, sus paquetes, todos los paquetes externos, el sistema o lenguaje anfitrión (digamos, R) así como el sistema operativo... además de potencialmente el hardware en el que todo se ejecutó. Ahora considere que algunos resultados pueden estar basados en la simulación y requerir un cluster particular de máquinas...

Eso es demasiado para ser práctico.

Dicho esto, creo que las soluciones más pragmáticas de versionar el código (y tal vez también los datos) en el control de revisiones, almacenar las versiones de todo el software relevante y hacer posible la reproducción de los resultados mediante la ejecución de un único script de alto nivel puede ser un compromiso "suficientemente bueno".

Su kilometraje puede variar. Esto también difiere según las disciplinas o la industria. Pero recuerde el viejo dicho sobre la imposibilidad de los sistemas infalibles: simplemente se crean tontos más inteligentes.

Answer 2

El primer paso para 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 más clara en este caso (Fairbairn en prensa).

Para que el código sea útil a largo plazo, quizá lo mejor sea escribir una documentación clara que explique tanto lo que hace el código como su funcionamiento, de modo que si su cadena de herramientas desaparece, su análisis pueda volver a implementarse en algún sistema futuro.

• Fairbairn (en prensa) La llegada del archivo obligatorio de datos . Evolución DOI: 10.1111/j.1558-5646.2010.01182.x

Answer 3

Una estrategia consiste en utilizar el cacher paquete.

• Peng RD, Eckel SP (2009). "Distributed reproducible research using cached computations", IEEE Computing in Science and Engineering, 11 (1), 28-34. ( PDF en línea )
• ver también más artículos sobre Sitio web de Roger Peng

En el libro se pueden encontrar más discusiones y ejemplos:

• Métodos estadísticos para la epidemiología ambiental con R

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

Answer 4

Si te interesa 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 las secuencias de comandos, y el paquete de todo el asunto en un caja virtual archivo.

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

Answer 5

Yo recomendaría dos cosas además de las excelentes respuestas ya presentadas;

• En los puntos clave de su código, vuelque los datos actuales como un archivo plano, convenientemente nombrado y descrito en los comentarios, destacando 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 utilizando algo como TestThat . Lo difícil es hacer pruebas pequeñas y reproducibles que puedan poner de manifiesto cualquier cambio en lo que hace un paquete que se relacionan a su análisis. Esto al menos pondría de manifiesto para otra persona que hay alguna diferencia en los entornos.