Comment augmenter la reproductibilité à long terme de la recherche (en particulier en utilisant R et Sweave)

Contexte: En réponse à une question précédente sur la recherche reproductible, Jake a écrit

Un problème que nous avons découvert lors de la création de notre archive JASA était que les versions et les valeurs par défaut des packages CRAN avaient changé. Donc, dans cette archive, nous incluons également les versions des packages que nous avons utilisés. Le système basé sur la vignette se cassera probablement à mesure que les gens changeront leurs packages (vous ne savez pas comment inclure des packages supplémentaires dans le package qui est le Compendium).

Enfin, je me demande ce qu'il faut faire lorsque R lui-même change. Existe-t-il des moyens de produire, disons, une machine virtuelle qui reproduit tout l'environnement de calcul utilisé pour un papier de telle sorte que la machine virtuelle ne soit pas énorme?

Question:

• Quelles sont les bonnes stratégies pour garantir que l'analyse des données reproductibles est reproductible à l'avenir (disons, cinq, dix ou vingt ans après la publication)?
• Plus précisément, quelles sont les bonnes stratégies pour maximiser la reproductibilité continue lors de l'utilisation de Sweave et R?

Cela semble être lié à la question de garantir qu'un projet d'analyse de données reproductible s'exécutera sur la machine de quelqu'un d'autre avec des valeurs par défaut, des packages, etc. légèrement différents.

À un certain niveau, cela devient impossible. Prenons le cas du fameux bug à virgule flottante Pentium: vous devez non seulement conserver vos modèles, vos données, vos paramètres, vos packages, tous les packages externes, le système hôte ou la langue (disons, R) ainsi que le système d'exploitation. . plus potentiellement le matériel sur lequel tout cela a fonctionné. Considérez maintenant que certains résultats peuvent être basés sur la simulation et nécessiter un cluster particulier de machines ...

C'est juste un peu beaucoup pour être pratique.

Cela dit, je pense que des solutions plus pragmatiques de version de votre code (et peut-être aussi de vos données) dans le contrôle des révisions, de stocker les versions de tous les logiciels pertinents et de permettre de reproduire les résultats en exécutant un seul script de niveau supérieur peuvent être un " assez bon "compromis.

Votre kilométrage peut varier. Cela diffère également selon les disciplines ou l'industrie. Mais rappelez-vous que l'ancien a vu l'impossibilité des systèmes infaillibles: vous créez simplement des imbéciles plus intelligents.

La première étape de la reproductibilité consiste à s'assurer que les données sont dans un format facile à lire pour les futurs chercheurs. Les fichiers plats sont le choix évident ici (Fairbairn sous presse).

Pour rendre le code utile à long terme, la meilleure chose à faire est peut-être d'écrire une documentation claire qui explique à la fois ce que fait le code et comment il fonctionne, de sorte que si votre chaîne d'outils disparaît, votre analyse peut être réimplémentée dans un système futur. .

• Fairbairn (sous presse) L'avènement de l'archivage obligatoire des données . Evolution DOI: 10.1111 / j.1558-5646.2010.01182.x

Une stratégie consiste à utiliser le cacherpackage.

• Peng RD, Eckel SP (2009). «Recherche reproductible distribuée à l'aide de calculs mis en cache», IEEE Computing in Science and Engineering, 11 (1), 28–34. ( PDF en ligne )
• voir aussi plus d'articles sur le site de Roger Peng

D'autres discussions et exemples peuvent être trouvés dans le livre:

• Méthodes statistiques pour l'épidémiologie environnementale avec R

Cependant, je n'ai pas d'expérience directe de son efficacité pour assurer une reproductibilité continue.

Si vous êtes intéressé par la route des machines virtuelles, je pense que ce serait faisable via une petite distribution Linux avec la version spécifique de R et les packages installés. Les données sont incluses, ainsi que les scripts, et regroupent le tout dans un fichier de boîte virtuelle .

Cela ne permet pas de contourner les problèmes matériels mentionnés précédemment, tels que le bogue CPU Intel.

Je recommanderais deux choses en plus des excellentes réponses déjà présentes;

• Aux points clés de votre code, videz les données actuelles sous forme de fichier plat, convenablement nommé et décrit dans les commentaires, soulignant ainsi si un package a produit des résultats différents là où les différences ont été introduites. Ces fichiers de données, ainsi que l'entrée d'origine et la sortie résultante doivent être inclus dans votre «ensemble de recherche reproductible»

• Incluez des tests des packages concernés dans votre code, par exemple en utilisant quelque chose comme TestThat . La partie difficile consiste à effectuer de petits tests reproductibles qui sont susceptibles de mettre en évidence tout changement dans ce qu'un package fait qui se rapporte à votre analyse. Cela mettrait au moins en évidence pour une autre personne qu'il y a une certaine différence dans les environnements.

Bonnes suggestions, j'ai beaucoup de choses à examiner maintenant.

N'oubliez pas, une considération extrêmement importante est de s'assurer que le travail est «correct» en premier lieu. C'est le rôle que jouent des outils comme Sweave , en augmentant les chances que ce que vous avez fait et ce que vous avez dit que vous avez fait soit la même chose.