« Ouverture du code informatique dans la recherche » : différence entre les versions
mAucun résumé des modifications |
|||
(4 versions intermédiaires par 3 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
= Textes de référence = | |||
# [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 ] | |||
# [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 ±) : | |||
[http://igm.univ-mlv.fr/~teresa/logicielsLIGM/documents/Laboratoire/talkLaboDec2007.pdf PDF1] | |||
[http://igm.univ-mlv.fr/~teresa/logicielsLIGM/documents/Mathrice/talkmathriceOct2007.pdf PDF2] | |||
et | |||
[http://igm.univ-mlv.fr/~teresa/logicielsLIGM/documents/Laboratoire/ArticlePresentationPlan-Dec2007.pdf l'article associé] | |||
cet article n'est pas publié, mais il apparaît dans la liste de [https://www.projet-plume.org/relier documents de 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]] |
Dernière version du 6 janvier 2013 à 11:40
Textes de référence[modifier]
- The Case for Open Computer Programs
- Article du framablog : Toute recherche scientifique digne de ce nom doit ouvrir son code informatique
- 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 ±) : PDF1 PDF2 et l'article associé cet article n'est pas publié, mais il apparaît dans la liste de documents de RELIER.
Notes de lecture sur le texte 1[modifier]
- 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é)[modifier]
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é[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
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.