« Ouverture du code informatique dans la recherche » : différence entre les versions

De April MediaWiki
Aller à la navigationAller à la recherche
(Mes notes de lecture de l'article.)
Ligne 1 : Ligne 1 :
==Textes de référence ==
= Textes de référence =


* [http://www.nature.com/nature/journal/v482/n7386/full/nature10836.html The Case for Open Computer Programs]
* 1) [http://www.nature.com/nature/journal/v482/n7386/full/nature10836.html The Case for Open Computer Programs]


* [http://www.framablog.org/index.php/post/2010/03/07/recherche-scientifique-code-informatique Article du framablog : Toute recherche scientifique digne de ce nom doit ouvrir son code informatique ]
* 2) [http://www.framablog.org/index.php/post/2010/03/07/recherche-scientifique-code-informatique Article du framablog : Toute recherche scientifique digne de ce nom doit ouvrir son code informatique ]


* [http://www-igm.univ-mlv.fr/~teresa/logicielsIGM-LabInfo/documents/presentationPlan-Dec2007.pdf Autour de la valorisation de logiciels développés dans un laboratoire de recherche (PDF), lien mort, voir ci dessous]
* 3) [http://www-igm.univ-mlv.fr/~teresa/logicielsIGM-LabInfo/documents/presentationPlan-Dec2007.pdf Autour de la valorisation de logiciels développés dans un laboratoire de recherche (PDF), lien mort, voir ci dessous]
Je vous propose les suivants (qui parlent de la même chose ±) :
Je vous propose les suivants (qui parlent de la même chose ±) :
http://igm.univ-mlv.fr/~teresa/logicielsLIGM/documents/Laboratoire/talkLaboDec2007.pdf
http://igm.univ-mlv.fr/~teresa/logicielsLIGM/documents/Laboratoire/talkLaboDec2007.pdf
Ligne 15 : Ligne 15 :
https://www.projet-plume.org/relier
https://www.projet-plume.org/relier


= Notes de lecture sur le texte 1) =


* Titre de l'article : The Case for Open Computer Programs
* Auteurs : Darrel C. Ince, Leslie Hatton & John Graham-Cumming
* Date de parution dans Nature : 23 février 2012
== Portée de l'article (domaine concerné) ==
Cet article s'applique à la recherche scientifique qui emploie des '''méthodes numériques'''
et '''publie''' des résultats obtenus par ces méthodes numériques.
De très nombreux domaines de recherche sont donc concernés. De grandes
avancées ont été effectuées, sont effectuées grâce à l'essor du calcul
scientifique et la possibilité de collecter, générer, traiter des données de
plus en plus importantes.
== Définition de la reproductibilité ==
La reproductibilité est un des principes fondamentaux de la méthode
scientifique. Il ne s'agit pas d'obtenir indépendamment chaque résultat
numérique identiquement à 7 décimales près. Cette reproductibilité exacte
("idéale") n'est pas possible, mais il faut exiger quelque chose de raisonnable
et pertinent, quelque part entre cela et rien du tout.
Le curseur est placé ici : il s'agit de pouvoir retrouver les résultats centraux
d'une publication donnée.
Le concept de '''recherche reproductible''', qui implique la mise à disposition
du code et des données, est un candidat pour répondre à cette exigence
raisonnable (voir référence 6 de l'article).
On distingue la '''reproductibilité directe''' et la '''reproductibilité indirecte'''
(voir fin de la première colonne, page 1).
La première consiste à recompiler et réexécuter le code sur son propre matériel ;
cela permet de détecter des problèmes numériques et d'interprétation propres
aux différents langages de programmation.
La deuxième consiste à valider, par une approche indépendante, des points
particuliers utilisés dans l'obtention des résultats.
Pour avoir reproductibilité directe, l'accès au code est indispensable.
== Thèse de l'article ==
Le libre accès au code source des programmes d'ordinateur ainsi qu'aux jeux de
données (utilisés pour l'obtention de tel résultat scientifique) est une condition
minimale pour la reproductibilité.
L'article (publié dans Nature) dénonce la politique de Nature en tant qu'éditeurs.
Il cite : ‘‘Nature does not require authors to make code available, but we do
expect a description detailed enough to allow others to write their own code
to do similar analysis.’’
Je traduis : "Nature n'exige pas des auteurs qu'ils rendent leur code disponible,
mais nous attendons qu'ils en fournissent une description suffisamment détaillée,
pour permettre à d'autres d'écrire leur propre code afin de mener des analyses
similaires."
Une telle déclaration est de fait nuisible à la reproductibilité.
L'article cite comme exemple à suivre la revue concurrente Science, qui demande
aux auteurs de fournir leur code.
La revue Biostatistics a même nommé un éditeur chargé d'examiner les
programmes et données associés aux papiers soumis afin d'en établir la
reproductibilité. C'est un signe de bonne volonté, ce n'est pas une mesure
discriminatoire. Ultimement, la reproductibilité ne peut pas être exigée ou garantie.
== Arguments ==
La communauté scientifique prise dans son ensemble sous-estime les limitations du
calcul numérique ; elle donne trop de valeur aux résultats numériques ; elle manque
de circonspection dans sa relation au calcul numérique.
Elle est grisée par l'utilisation de grilles de calcul de plus en plus fines, de calculs de
plus en plus longs et complexes, et de jeux de données de plus en plus grands. Or,
contre-intuitivement peut-être, tout cela ne résout pas les incertitudes liées au calcul
numérique. Cela peut même les exacerber.
Avec l'augmentation des moyens de calculs et de stockage, la publication des codes
source est donc une urgence.
Une description en langue humaine d'un programme d'ordinateur (telle qu'attendue
par Nature) est très insuffisante, voire trompeuse. Une langue humaine comporte
une part irréductible d'ambiguïté et conduit donc à des implémentations ambiguës,
elles-mêmes conduisant à des résultats que l'on ne pourrait comparer ou
interpréter.
Il y aura toujours des erreurs de programmation (de 1 à 10 pour 1000 lignes de code,
selon l'estimation de la référence 21).
A plus bas niveau, on trouve les erreurs sur les propriétés numériques chez les logiciels
et librairies scientifiques. L'exécution d'un programme qui manipule des nombres
flottants donne typiquement des résultats variables, indépendamment de toute erreur
de programmation. Cela peut conduire à de grandes différences dans les résultats finaux,
par exemple dans le cas d'erreurs d'arrondi quand de très nombreux calculs sont
effectués à la suite.
Enfin, les langages de programmation communément utilisés dans la recherche
scientifique comportent des ambiguïtés d'exécution. L'article cite D. Monniaux
(référence 22) : ‘‘More subtly, on some platforms, the exact same expression, with the
same values in the same variables, and the same compiler, can be evaluated to different
results, depending on seemingly irrelevant statements (printing debugging information
or other constructs that do not openly change the values of variables).’’
Je traduis : "Plus subtil encore, sur certaines plates-formes, la même expression
exactement, avec les mêmes valeurs affectées aux mêmes variables, et le même
compilateur, peut être évaluée différemment, cela dépendant de déclarations en
apparence anodines (comme afficher les informations de débogage, ou d'autres
concepts qui ne modifient pas ouvertement les valeurs des variables)."
Complètement effrayant, n'est-ce pas ?
Maintenir la fermeture du code garantit que les possibles incertitudes ou
erreurs trouvées dans les conclusions d'un papier ne pourront être dépistées
comme provenant d'une description ambiguë, d'une question d'implémentation
numérique, ou d'une question d'architecture des machines. Le non accès au
code empêche donc aussi la reproductibilité indirecte.
Traiter le code comme une boîte noire freine (si ce n'est empêche) la validation,
l'affinement de résultats. L'avancement scientifique est ainsi bridé.
Trouver des erreurs dans un code ne dévalorise pas ses auteurs. Consulter,
vérifier le code se comprend comme la révision par les pairs, telle que pratiquée
dans la publication scientifique. Il est normal de trouver des erreurs.
Les programmeurs scientifiques sont des êtres humains.
== Limites identifiées ==
Sur le principe de la reproductibilité, tout le monde est d'accord : mais comment
la rendre possible en pratique ?
Il y a un manque d'outils et d'espaces pour mettre à disposition code et données.
Il y a un manque de culture commune sur les limitations du calcul scientifique.
Par exemple, la recherche, pourtant très active, sur la variable flottante ne
pénètre pas les communautés scientifiques non informaticiennes.
Le développement de programmes dans le calcul scientifique est sous-estimé
ou considéré comme ne constituant pas la recherche scientifique en tant que telle.
== Propositions concrètes ==
Que les agences de financement adoptent les services d'hébergement avec gestion
de versions. Qu'elles s'inspirent pour cela des communautés open source.
Mettre en avant l'enjeu de la reproductibilité dans l'éducation et la formation.
Que les revues scientifiques adoptent un standard permettant d'identifier facilement
le degré d'accessibilité du code source.
Qu'une description du matériel (hardware) et de l'environnement soit aussi associés
au code source.
Je me permets alors de citer cette initiative exemplaire :
http://lcav.epfl.ch/reproducible_research (LCAV, EPFL, Reproducible Research).
Il faut garder à l'esprit que malgré l'ouverture du code, des données et des informations
sur l'environnement, la reproductibilité ne peut être garantie. Mais en s'engageant
dans une démarche volontariste d'ouverture, on met les chances de son côté pour
la reproductibilité, et donc plus de progrès scientifique.


[[Catégorie:Recherche]]
[[Catégorie:Recherche]]

Version du 5 janvier 2013 à 20:24

Textes de référence

Je vous propose les suivants (qui parlent de la même chose ±) : http://igm.univ-mlv.fr/~teresa/logicielsLIGM/documents/Laboratoire/talkLaboDec2007.pdf http://igm.univ-mlv.fr/~teresa/logicielsLIGM/documents/Mathrice/talkmathriceOct2007.pdf et l'article associé : http://igm.univ-mlv.fr/~teresa/logicielsLIGM/documents/Laboratoire/ArticlePresentationPlan-Dec2007.pdf cet article n'est pas publié, mais il apparaît dans la liste de documents de RELIER : https://www.projet-plume.org/relier

Notes de lecture sur le texte 1)

* Titre de l'article : The Case for Open Computer Programs
* Auteurs : Darrel C. Ince, Leslie Hatton & John Graham-Cumming
* Date de parution dans Nature : 23 février 2012

Portée de l'article (domaine concerné)

Cet article s'applique à la recherche scientifique qui emploie des méthodes numériques et publie des résultats obtenus par ces méthodes numériques. De très nombreux domaines de recherche sont donc concernés. De grandes avancées ont été effectuées, sont effectuées grâce à l'essor du calcul scientifique et la possibilité de collecter, générer, traiter des données de plus en plus importantes.

Définition de la reproductibilité

La reproductibilité est un des principes fondamentaux de la méthode scientifique. Il ne s'agit pas d'obtenir indépendamment chaque résultat numérique identiquement à 7 décimales près. Cette reproductibilité exacte ("idéale") n'est pas possible, mais il faut exiger quelque chose de raisonnable et pertinent, quelque part entre cela et rien du tout. Le curseur est placé ici : il s'agit de pouvoir retrouver les résultats centraux d'une publication donnée. Le concept de recherche reproductible, qui implique la mise à disposition du code et des données, est un candidat pour répondre à cette exigence raisonnable (voir référence 6 de l'article).

On distingue la reproductibilité directe et la reproductibilité indirecte (voir fin de la première colonne, page 1). La première consiste à recompiler et réexécuter le code sur son propre matériel ; cela permet de détecter des problèmes numériques et d'interprétation propres aux différents langages de programmation. La deuxième consiste à valider, par une approche indépendante, des points particuliers utilisés dans l'obtention des résultats. Pour avoir reproductibilité directe, l'accès au code est indispensable.

Thèse de l'article

Le libre accès au code source des programmes d'ordinateur ainsi qu'aux jeux de données (utilisés pour l'obtention de tel résultat scientifique) est une condition minimale pour la reproductibilité.

L'article (publié dans Nature) dénonce la politique de Nature en tant qu'éditeurs. Il cite : ‘‘Nature does not require authors to make code available, but we do expect a description detailed enough to allow others to write their own code to do similar analysis.’’ Je traduis : "Nature n'exige pas des auteurs qu'ils rendent leur code disponible, mais nous attendons qu'ils en fournissent une description suffisamment détaillée, pour permettre à d'autres d'écrire leur propre code afin de mener des analyses similaires." Une telle déclaration est de fait nuisible à la reproductibilité. L'article cite comme exemple à suivre la revue concurrente Science, qui demande aux auteurs de fournir leur code. La revue Biostatistics a même nommé un éditeur chargé d'examiner les programmes et données associés aux papiers soumis afin d'en établir la reproductibilité. C'est un signe de bonne volonté, ce n'est pas une mesure discriminatoire. Ultimement, la reproductibilité ne peut pas être exigée ou garantie.

Arguments

La communauté scientifique prise dans son ensemble sous-estime les limitations du calcul numérique ; elle donne trop de valeur aux résultats numériques ; elle manque de circonspection dans sa relation au calcul numérique. Elle est grisée par l'utilisation de grilles de calcul de plus en plus fines, de calculs de plus en plus longs et complexes, et de jeux de données de plus en plus grands. Or, contre-intuitivement peut-être, tout cela ne résout pas les incertitudes liées au calcul numérique. Cela peut même les exacerber. Avec l'augmentation des moyens de calculs et de stockage, la publication des codes source est donc une urgence.

Une description en langue humaine d'un programme d'ordinateur (telle qu'attendue par Nature) est très insuffisante, voire trompeuse. Une langue humaine comporte une part irréductible d'ambiguïté et conduit donc à des implémentations ambiguës, elles-mêmes conduisant à des résultats que l'on ne pourrait comparer ou interpréter.

Il y aura toujours des erreurs de programmation (de 1 à 10 pour 1000 lignes de code, selon l'estimation de la référence 21).

A plus bas niveau, on trouve les erreurs sur les propriétés numériques chez les logiciels et librairies scientifiques. L'exécution d'un programme qui manipule des nombres flottants donne typiquement des résultats variables, indépendamment de toute erreur de programmation. Cela peut conduire à de grandes différences dans les résultats finaux, par exemple dans le cas d'erreurs d'arrondi quand de très nombreux calculs sont effectués à la suite.

Enfin, les langages de programmation communément utilisés dans la recherche scientifique comportent des ambiguïtés d'exécution. L'article cite D. Monniaux (référence 22) : ‘‘More subtly, on some platforms, the exact same expression, with the same values in the same variables, and the same compiler, can be evaluated to different results, depending on seemingly irrelevant statements (printing debugging information or other constructs that do not openly change the values of variables).’’ Je traduis : "Plus subtil encore, sur certaines plates-formes, la même expression exactement, avec les mêmes valeurs affectées aux mêmes variables, et le même compilateur, peut être évaluée différemment, cela dépendant de déclarations en apparence anodines (comme afficher les informations de débogage, ou d'autres concepts qui ne modifient pas ouvertement les valeurs des variables)." Complètement effrayant, n'est-ce pas ?

Maintenir la fermeture du code garantit que les possibles incertitudes ou erreurs trouvées dans les conclusions d'un papier ne pourront être dépistées comme provenant d'une description ambiguë, d'une question d'implémentation numérique, ou d'une question d'architecture des machines. Le non accès au code empêche donc aussi la reproductibilité indirecte.

Traiter le code comme une boîte noire freine (si ce n'est empêche) la validation, l'affinement de résultats. L'avancement scientifique est ainsi bridé.

Trouver des erreurs dans un code ne dévalorise pas ses auteurs. Consulter, vérifier le code se comprend comme la révision par les pairs, telle que pratiquée dans la publication scientifique. Il est normal de trouver des erreurs. Les programmeurs scientifiques sont des êtres humains.

Limites identifiées

Sur le principe de la reproductibilité, tout le monde est d'accord : mais comment la rendre possible en pratique ?

Il y a un manque d'outils et d'espaces pour mettre à disposition code et données.

Il y a un manque de culture commune sur les limitations du calcul scientifique. Par exemple, la recherche, pourtant très active, sur la variable flottante ne pénètre pas les communautés scientifiques non informaticiennes.

Le développement de programmes dans le calcul scientifique est sous-estimé ou considéré comme ne constituant pas la recherche scientifique en tant que telle.

Propositions concrètes

Que les agences de financement adoptent les services d'hébergement avec gestion de versions. Qu'elles s'inspirent pour cela des communautés open source.

Mettre en avant l'enjeu de la reproductibilité dans l'éducation et la formation.

Que les revues scientifiques adoptent un standard permettant d'identifier facilement le degré d'accessibilité du code source. Qu'une description du matériel (hardware) et de l'environnement soit aussi associés au code source. Je me permets alors de citer cette initiative exemplaire : http://lcav.epfl.ch/reproducible_research (LCAV, EPFL, Reproducible Research).

Il faut garder à l'esprit que malgré l'ouverture du code, des données et des informations sur l'environnement, la reproductibilité ne peut être garantie. Mais en s'engageant dans une démarche volontariste d'ouverture, on met les chances de son côté pour la reproductibilité, et donc plus de progrès scientifique.