Como aumentar a reprodutibilidade a longo prazo da pesquisa (particularmente usando R e Sweave)


31

Contexto: Em resposta a uma pergunta anterior sobre pesquisa reproduzível, Jake escreveu

Um problema que descobrimos ao criar nosso arquivo JASA foi que as versões e padrões dos pacotes CRAN foram alterados. Portanto, nesse arquivo, também incluímos as versões dos pacotes que usamos. O sistema baseado em vinheta provavelmente será interrompido quando as pessoas mudarem seus pacotes (não sabe como incluir pacotes extras no pacote que é o Compêndio).

Finalmente, eu me pergunto sobre o que fazer quando o próprio R muda. Existem maneiras de produzir, digamos, uma máquina virtual que reproduza todo o ambiente computacional usado para um papel, de modo que a máquina virtual não seja enorme?

Questão:

  • Quais são as boas estratégias para garantir que a análise de dados reproduzíveis seja reproduzível no futuro (digamos, cinco, dez ou vinte anos após a publicação)?
  • Especificamente, quais são as boas estratégias para maximizar a reprodutibilidade contínua ao usar Sweave e R?

Isso parece estar relacionado à questão de garantir que um projeto de análise de dados reproduzível seja executado na máquina de outra pessoa com padrões, pacotes etc. ligeiramente diferentes.


Você considerou o Teste de Unidade com o RUnit para verificar o comportamento teórico?

Respostas:


18

Em algum nível, isso se torna impossível. Considere o caso do famoso bug de ponto flutuante Pentium: você não precisa apenas conservar seus modelos, dados, parâmetros, pacotes, todos os pacotes externos, o sistema ou idioma do host (por exemplo, R) e o sistema operacional. além de potencialmente o hardware em que tudo funcionava. Agora considere que alguns resultados podem ser baseados em simulação e exigiram um cluster específico de máquinas ...

Isso é um pouco demais por ser prático.

Com isso dito, acho que soluções mais pragmáticas de versionar seu código (e talvez também seus dados) no controle de revisões, armazenar versões de todos os softwares relevantes e possibilitar a reprodução dos resultados executando um único script de nível superior podem ser um " bom o suficiente ".

Sua milhagem pode variar. Isso também difere entre disciplinas ou setor. Mas lembre-se da velha visão sobre a impossibilidade de sistemas infalíveis: você simplesmente cria tolos mais inteligentes.


1
(+1) Só posso concordar com você. Sobre o R especificamente, parece muito difícil garantir que (a) alguns cálculos permaneçam reproduzíveis após a atualização de um pacote (o que aconteceu recentemente) e (b) nenhum conflito com dependências surgirá um dia (foi o caso, por exemplo, para lme4).
chl

13

O primeiro passo na reprodutibilidade é garantir que os dados estejam em um formato fácil para os futuros pesquisadores lerem. Arquivos simples são a escolha clara aqui (Fairbairn no prelo).

Para tornar o código útil a longo prazo, talvez a melhor coisa a fazer seja escrever uma documentação clara que explique o que o código faz e também como ele funciona, para que, se sua cadeia de ferramentas desaparecer, sua análise possa ser reimplementada em algum sistema futuro. .


1
Dados e metadados sólidos e acordados primeiro.
mindless.panda

11

Uma estratégia envolve o uso do cacherpacote.

  • Peng RD, Eckel SP (2009). "Pesquisa reproduzível distribuída usando cálculos em cache", IEEE Computing in Science and Engineering, 11 (1), 28-34. ( PDF online )
  • veja também mais artigos no site de Roger Peng

Discussões e exemplos adicionais podem ser encontrados no livro:

No entanto, não tenho experiência em primeira mão de sua eficácia para garantir a reprodutibilidade contínua.


7

Se você está interessado na rota da máquina virtual, acho que seria possível através de uma pequena distribuição Linux com a versão específica do R e os pacotes instalados. Os dados são incluídos, juntamente com os scripts, e empacotam tudo em um arquivo de caixa virtual .

Isso não resolve os problemas de hardware mencionados anteriormente, como o bug na CPU da Intel.


4

Eu recomendaria duas coisas, além das excelentes respostas já presentes;

  • Nos pontos-chave do seu código, faça o dump dos dados atuais como um arquivo simples, adequadamente nomeado e descrito nos comentários, destacando assim se um pacote produziu resultados diferentes onde as diferenças foram introduzidas. Esses arquivos de dados, bem como a entrada original e a saída resultante devem ser incluídos no seu 'conjunto de pesquisas reproduzíveis'

  • Inclua alguns testes dos pacotes envolvidos em seu código, por exemplo, usando algo como TestThat . A parte difícil é fazer testes pequenos e reproduzíveis que provavelmente realçam as alterações no que um pacote faz relacionado à sua análise. Pelo menos isso destacaria para outra pessoa que há alguma diferença nos ambientes.


1

Boas sugestões, tenho muitas coisas para analisar agora.

Lembre-se, uma consideração extremamente importante é garantir que o trabalho esteja "correto" em primeiro lugar. Esse é o papel que ferramentas como Sweave desempenham, aumentando as chances de que o que você fez e o que disse que fez é a mesma coisa.


1
O projeto Sumatra também pode ser útil : neuralensemble.org/trac/sumatra/wiki . Você pode usar sua interface de linha de comando para executar seu código, estar em R ou algo mais. Também existe uma API Python. Há um bom post sobre blogueiros R discutindo ferramentas centradas em R para pesquisa reproduzível, e menciona o uso do Sumatra também. r-bloggers.com/managing-a-statistical-analysis-project- –-guidelines-and-best-Practices /
Josh Hemann
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.