Aumentando a longevidade de arquivamento do código

Existe uma lista publicada de melhores práticas para garantir a longevidade do código, visando resultados científicos reproduzíveis? (por exemplo, código aberto, práticas de documentação, seleção de dependências, seleção de idioma, máquinas virtuais etc.).

Conhece estudos (ou faltam exemplos / anedotas) que tentaram estimar a meia-vida de códigos científicos típicos ou outros softwares (se é que isso é uma pergunta razoável?)

a longevidade planejada do TeX vem à mente:

“Desde o início de 1977, o projeto de pesquisa TeX em que iniciei foi conduzido por dois objetivos principais. O primeiro objetivo era a qualidade: queríamos produzir documentos que não eram apenas bons, mas realmente os melhores. (…) O segundo objetivo principal era o arquivamento: criar sistemas que fossem independentes das mudanças na tecnologia de impressão, tanto quanto possível. Quando a próxima geração de dispositivos de impressão surgiu, eu queria poder manter a mesma qualidade já alcançada, em vez de ter que resolver todos os problemas novamente. Eu queria projetar algo que ainda seria utilizável em 100 anos. ”- Donald E. Knuth: Tipografia Digital, p. 559 (citado em http://de.wikipedia.org/wiki/TeX )

Com base nos livros de Knuth sobre tipografia digital, mesmo uma completa reimplementação do TeX e METAFONT deve ser possível. Eles incluem anotações e explicações para todo o código.

Ao exigir que seus resultados sejam estáveis ​​ao longo de décadas, você entra em uma espécie de dilema congelante. Por um lado, você deseja facilitar a reprodução dos resultados 100%, para congelar seu software / ambiente. Por outro lado, alguém que esteja interessado em reproduzir seus resultados no futuro certamente desejará aproveitar isso. Essa pessoa ficará presa a um software muito antigo, dificultando a alteração de qualquer coisa. Para qualquer coisa que se baseia em vários pacotes externos, alguns anos já são suficientes para tornar as coisas praticamente imutáveis.

Para o TeX, o congelamento é anunciado no artigo de 1990

O futuro do TEX e do METAFONT http://www.ntg.nl/maps/05/34.pdf

"Acredito firmemente que um sistema imutável tem um grande valor, embora seja axiomático que qualquer sistema complexo possa ser melhorado. Portanto, acredito que não é sensato fazer mais" melhorias "nos sistemas chamados TEX e METAFONT. Vamos considerar esses sistemas como pontos fixos, que devem fornecer os mesmos resultados daqui a 100 anos a partir de agora.

O sistema ideal combinaria reprodutibilidade com mutabilidade. Tentar ser o mais independente, simples e bem testado possível certamente ajuda.

Perdoe-me se eu estava discordando demais da pergunta original. [cross postado em 'Scientists for Reproducible Research', reproducible-research@googlegroups.com]

Existem muitos desafios técnicos que tornam extremamente difícil a reprodutibilidade exata dos resultados computacionais bit a bit.

No nível do software, alterações no código ou em qualquer uma das bibliotecas usadas pelo código podem obviamente causar resultados diferentes. Você ficaria surpreso com o número de bibliotecas de suporte que podem acabar vinculadas a um código científico típico.

Em um nível inferior, recompilar qualquer um dos códigos ou bibliotecas usadas pelo código com um novo compilador ou com diferentes otimizações do compilador ativadas também pode causar problemas. Um motivo é que várias operações no código podem ser executadas em uma ordem diferente quando o código é recompilado. Como a adição de ponto flutuante não é associativa (a + b) + c <> a + (b + c), isso pode gerar resultados diferentes.

OK, e se preservarmos todo o ambiente de software (SO, bibliotecas e código compilado) (por exemplo) gravá-lo em um CD-ROM inicializável que executará o código. Agora podemos ter certeza de que obteremos os mesmos resultados se executarmos esse código em um computador diferente?

Surpreendentemente, alguns códigos realmente variam a ordem dos cálculos com base nos aspectos do modelo de processador específico em que estão sendo executados. Por exemplo, as bibliotecas de álgebra linear otimizadas geralmente dividem as multiplicações de matriz para trabalhar em blocos que cabem no cache. Quando a Intel lança um novo microprocessador com um cache maior, o código pode ajustar dinamicamente o tamanho do bloco, resultando em aritmética executada em uma ordem diferente e fornecendo resultados diferentes. Outros códigos ajustam dinamicamente a ordem dos cálculos com base na quantidade de memória disponível - se você executar o código em um computador com mais memória que poderia fazer com que a aritmética fosse executada em uma ordem diferente e, assim, fornecer resultados diferentes.

As coisas ficam incrivelmente mais complicadas quando você insere um código multithread, pois o histórico exato de execução dos diferentes threads geralmente não é determinístico e isso pode novamente fazer com que operações aritméticas sejam executadas em uma ordem diferente de uma execução para a próxima.

Na prática, o máximo que você pode realmente esperar são resultados semelhantes de uma máquina para outra, até as tolerâncias de precisão dos algoritmos usados. por exemplo, se eu tiver um problema de localização de raiz e usar a bissecção para obter uma raiz dentro de + -1,0e-10, ficarei feliz desde que máquinas diferentes estejam produzindo respostas que concordem com essa tolerância.

Houve muitas tentativas de fazer a reprodutibilidade acontecer e há toda uma literatura sobre esse tópico. Minha opinião pessoal de 15 anos de software científico é que não é realista, por mais insatisfatória que eu encontre essa resposta. Os problemas são que (i) software complexo possui bugs e, portanto, não pode ser congelado; (ii) o software nunca possui recursos completos e, portanto, o desenvolvimento continua; (iii) qual é o valor de entregar com um papel várias centenas de milhares de linhas de código?

Como eu digo, acho esta resposta insatisfatória. Acredito que, como um campo, a ciência computacional não tenha sido muito bem-sucedida na produção de literatura que instale confiança de que os resultados que publicamos são corretos e reprodutíveis. Ao mesmo tempo, não consigo encontrar maneiras de fazer as coisas melhor. Certamente, é útil liberar o código fonte que acompanha o papel. Ao mesmo tempo, todos que são honestos concordam que os resultados de um artigo geralmente serão produzidos por diferentes versões do código que, na maioria dos casos, contêm hacks que descrevem diferentes condições de contorno, diferentes lados do lado direito, etc. vêm com versões diferentes do mesmo código. Isso é estranho para o leitor, para começar, mas é totalmente improdutivo se o código for grande, como acontece hoje em dia - meus dois artigos mais recentes usaram códigos com cerca de 20.000 linhas de código e que se baseiam em acordos.II (600.000 linhas de código) e Trilinos (linhas de 1.5M de código). Que informação isso fornece a um leitor em potencial? (Devo dizer que meus códigos ainda estão disponíveis.)

Para uma possível solução para esse problema, consulte meu projeto do ActivePapers . Em resumo, descreve como dados e código podem ser empacotados junto com dependências explícitas em versões específicas de cada componente de software. Isso possibilita a reprodução exata de uma computação, além de permitir a execução de um software atualizado nos mesmos dados.

Devo acrescentar que o ActivePapers não é mais que uma prova de conceito e é improvável que seja útil em um futuro próximo. O motivo é que ele se baseia no princípio de que todo código executável deve existir como bytecode da JVM. No momento, isso exclui muitas bibliotecas científicas populares. No entanto, uma vez que a reprodutibilidade é reconhecida como importante, as prioridades nas ferramentas de programação também podem mudar.

Acredito que, no que diz respeito à escolha da linguagem, o uso de uma padronizada (por exemplo, C / Fortran / C ++) se qualificaria como "melhor prática". Se um pacote depende de outras 10 bibliotecas / pacotes, especialmente aqueles escritos em idiomas obscuros, isso obviamente é ruim para a longevidade. Muitos projetos acabam ficando órfãos depois de algum tempo. Eu não acho que grandes bibliotecas / APIs como BLAS / LAPACK, PETSc, FFTW, MPI etc. desapareceriam tão cedo. O BLAS já é bastante antigo.

O seguinte trecho de código (roubado de http://www.math.utah.edu/software/c-with-fortran.html ) é anterior ao Fortran 77, usa constantes Hollerith para manipulação de caracteres, mas compila muito bem 40-50 anos depois com o compilador GNU Fortran:

stali@x61:~$ cat olde.f

       CALL S(12HHello, world, 12)
       END
       SUBROUTINE S(MSG,N)
       INTEGER K, N, M
       INTEGER MSG(1)
       M = (N + 3) / 4
       WRITE (6,'(20A4)') (MSG(K), K = 1,M)
       END

stali@x61:~$ gfortran -std=legacy olde.f; ./a.out
Hello, world

Abrir o código-fonte / colocá-lo em algum lugar, como código de googl, que é menos provável que desapareça em breve (embora eles tenham desativado a pesquisa de código) é um acéfalo.