Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans des études scientifiques

Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans plus d'une centaine d'études scientifiques publiées
depuis 2014

Les programmes informatiques sont devenus comme des pivots dans plusieurs domaines de la vie, et l’on peut parfois être amené à surestimer l’exactitude des résultats d’un programme. Cependant, il peut arriver que certains programmes comportent des bogues qui pourraient engendrer de faux résultats. Récemment, des scientifiques hawaïens ont découvert un bogue dans un morceau de code Python qui aurait pu donner des résultats incorrects dans plus de 100 études publiées qui ont cité l'article original. Le bogue entraîne une variation des résultats d’un calcul en fonction du système d'exploitation utilisé.

Les scientifiques d’Hawaii ont détecté un bogue dans un morceau de code Python qui aurait pu donner des résultats incorrects dans plus de 100 études publiées qui ont cité l'article original. Le bogue a fait varier les résultats d'un calcul chimique, commun à plusieurs études, en fonction du système d'exploitation utilisé, ce qui a entraîné des divergences entre les systèmes Mac, Windows et Linux. Mardi, les chercheurs ont publié leur découverte et une version déboguée du script (d'environ 1 000 lignes de code) dans la revue Organic Letters.

À l’origine de la découverte, Yuheng Luo, un étudiant diplômé de l'Université d’Hawaii à Mānoa. Il s’est rendu compte du problème cet été alors qu'il vérifiait les résultats des recherches menées par le professeur de chimie Philip Williams sur les cyanobactéries (un embranchement de bactéries, également appelées « algues bleues »), en utilisant un script écrit en Python qui a été publié dans le cadre d'un article de 2014 dans la revue Nature Protocols. Les procédés du chimiste Williams consistaient à trouver des composés qui sont efficaces contre le cancer.

Le script utilisé par Luo calcule les valeurs de décalage chimique pour la RMN, ou spectroscopie par résonance magnétique nucléaire, une technique couramment utilisée par les chimistes pour déterminer la composition moléculaire d'un échantillon. Seulement, ses résultats ne correspondaient pas aux valeurs de RMN que le groupe de Williams avait précédemment calculées, et lorsque d’autres élèves ont à leur tour exécuté le code sur leurs ordinateurs, ils ont réalisé que les différents systèmes d'exploitation produisaient des résultats différents.

Pièce jointe 509826

Rui Sun, professeur de chimie à l'université d'Hawaii à Mānoa et qui supervisait les calculs de Luo, a ensuite ajusté le script pour corriger le problème, qui avait rapport à la façon dont les différents systèmes d'exploitation trient les fichiers. Patrick Willoughby, le premier auteur de l'étude de 2014, et qui a écrit le script, a qualifié la nouvelle étude de « bel exemple de science qui travaille pour faire avancer le travail que nous avons présenté en 2014 ». « Ils ont rendu un service extraordinaire à la communauté en révélant ce problème », a-t-il déclaré.

Le script comportant le bogue fait partir des scripts Python baptisés « Willoughby-Hoye », permettant de calculer les valeurs de décalage chimique pour la RMN (résonance magnétique nucléaire). Ce qui inquiète le plus les chercheurs, c’est que la découverte de ce bogue dans le script remet en question les conclusions de plusieurs autres études qui ont cité ou ont utilisé les résultats des calculs chimiques effectués par Patrick Willoughby en 2014. Ils estiment que les auteurs de ces études devraient reprendre leurs calculs avec le script corrigé.

« Ce simple bogue dans le script original remet en question les conclusions de plusieurs articles sur un large éventail de sujets d'une manière qui ne peut pas être facilement résolue à partir d'informations publiées parce que le système d'exploitation est rarement mentionné », ont-ils écrit dans leur article publié mardi dernier dans la revue Organic Letters. « Les auteurs qui ont utilisé ces scripts devraient certainement revérifier leurs résultats et toute conclusion pertinente en utilisant les nouveaux scripts modifiés », ont-ils ajouté.

Les chercheurs estiment que le bogue a pu produire de graves effets en aval. Par exemple, si le code amenait Williams à mal identifier le contenu de son échantillon, les chimistes essayant de recréer la molécule à tester en tant que médicament potentiel contre le cancer seraient à la poursuite du mauvais composé. Le nombre d’articles qui ont pu être affectés par ce problème n’est pas connu, car les chercheurs ne divulguent généralement pas le système d'exploitation qu'ils utilisent pour leurs analyses, il ne devrait pas être pertinent.

Néanmoins, d'après les données de Nature Protocols, le document de 2014 a été consulté près de 1900 fois et cité dans 158 autres études. Toutefois, il est également possible que toutes les études qui ont cité l'article n'aient peut-être pas utilisé le script qui contenait le bogue. Rob Keyzers, professeur de chimie à l'université Victoria de Wellington en Nouvelle-Zélande, qui avait cité le protocole dans une étude publiée cette année, a déclaré qu'il n'était pas au courant du problème et qu’il ne pense pas que cela affecte ses résultats.

Rob Keyzers a déclaré qu'il n'était pas « indûment inquiet » de ses résultats puisque son groupe n'a pas utilisé le script contenant le bogue. Malgré cela, il pense bien vérifier ses différentes conclusions. « Je vais certainement vérifier soigneusement nos données pour m'assurer que nous ne faisons pas de réclamations injustifiées », a-t-il ajouté. Williams et Sun ont contacté les auteurs de l'article original, les avertissant du bogue. Williams espère qu’ils travailleront ensemble pour informer les chercheurs qui avaient utilisé le code de l'existence du bogue.

Willoughby et Thomas Hoye prévoient de mettre à jour leur étude publiée dans la revue Nature Protocols. Ils ont reconnu le problème et fourniront le correctif écrit par le professeur Sun. Un porte-parole de Nature Protocols a également déclaré qu'ils examinaient les questions soulevées dans la nouvelle étude (publiée mardi par Sun et ses collaborateurs dans la revue Organic Letters), mais que pour des raisons de confidentialité, ils ne pouvaient commenter les cas individuels.

Selon Williams, l'incident rappelle que la science est collaborative et qu'elle s'autocorrige idéalement, mais que rien ne peut être tenu pour acquis. « C'est une erreur minime et subtile. Nous pensons tous en quelque sorte qu'un programme informatique génère toujours la bonne réponse », a-t-il conclu.

Source : ACS Publications, Étude originale (2014)

Et vous ?

:fleche: Qu'en pensez-vous ?

Voir aussi

:fleche: Microsoft arrête le déploiement de Windows 10 October 2018 à cause d'un bogue qui provoque la suppression des fichiers des utilisateurs

:fleche: macOS : les langages de script tels que Python, Perl et Ruby ne seront plus préinstallés à partir de macOS Catalina pour plus de sécurité, dit Apple

:fleche: Bash 5.0 est maintenant disponible. La cinquième version majeure du shell du projet GNU apporte de nouvelles fonctionnalités et corrections de bogues

Le titre alarmiste de cet article indique que le souci vient de Python, mais le texte parle du script Willoughby-Hoye.
Difficile de trouver des infos là dessus.

Ni cet article, ni les sources n'indiquent la nature exacte du problème.
Souci de représentation des nombres flottants ? Problème de consommation mémoire ?

Un exemple de script problématique aurait bien illustré l'article, surtout sur Developpez.

Et quelles sont les différences entre les différents OS ?

J'avoue rester sur ma faim sur ce coup là.

Edit: J'avais mal lu la news, le souci est bien mentionné

Il est également possible que le problème ne vient ni d'une erreur de script, ni d'un bug de Python, mais découlant simplement d'une fonction au "comportement non défini", si cher à nos analystes de sécurité.
...vous souhaitez du code fiable ? --> listez tous les éléments du langage employé ayant un comportement "non défini", et gardez-vous de les utiliser.

Citation:

---

Envoyé par Daïmanu

Ni cet article, ni les sources n'indiquent la nature exacte du problème. Souci de représentation des nombres flottants ? Problème de consommation mémoire ?

---

D'après la rumeur, ce code faisait pour hypothèse que différents OS trient les fichiers de la même façon (même la documentation d'os.listdir prévient là dessus).
Ce qui en soit n'a rien à voir avec le langage.

Pour le reste, c'est pas parce qu'on code avec Python qu'un programme qui produits des résultats dans un environnement système produira les mêmes dans un autre: il faut qu'un plan de tests s'attache à vérifier les dépendances, que les tests détectent les inconsistances (et qu'on oublient pas de les faire tourner).
Néanmoins, c'est bien que la communauté scientifique s'alarme un peu de la difficulté qu'il y a à programmer correctement et prennent des précautions lorsqu'ils s'échangent des codes.

- W

Si un syseme X trie les fichiers differament d'un systeme Y, et que l'ordre des fichiers est important et peut changer le resultat final, c'est clair que ne n'est pas la faute au language. Souvant la partie fichier E/S è la partie qui doit etre adapté pour chaque systeme d'exploitation.

Il est écrit dans le post que le bug est une différence de tri de fichier entre OS.

Bon on est bien d'accord, quand une analyse scientifique dépend de la façon dont l'OS trie les fichiers le problème il est entre la chaise et le clavier.

Citation:

---

Envoyé par Daïmanu

Un exemple de script problématique aurait bien illustré l'article, surtout sur Developpez.

---

Bien sur on mentionne les codes sources dans les actualités en général, quand on les as, souvent par exemple des sources sur github, ou collé dans la news directement avec la balise code, mais dans ce cas précis je n'ai pas trouvé le code Python dans les articles sources. Si quelqu'un le trouve, il est bienvenu pour le poster à la suite ;)

Citation:

---

Envoyé par Bill Fassinou

je n'ai pas trouvé le code dans les sources. Si quelqu'un le trouve, il est bienvenu de le poster à la suite

---

çà devrait être(*):

Code:

---

1 2 3 4 5 6

def read_gaussian_outputfiles(): list_of_files = [] for file in glob.glob('*.out'): list_of_files.append(file) list_of_files.sort() # la correction. return list_of_files

---

Première ligne de la documentation de glob.glob:

Citation:

---

The glob module finds all the pathnames matching a specified pattern according to the rules used by the Unix shell, although results are returned in arbitrary order.

---

(*) trouvé par ailleurs car il faut des droits d'accès pour les sources.

- W

Ce genre de bogue explique les disparités des études, les unes prônant le bien fait du café et les autres qui "prouvent" ça nocivité. :mouarf:

J'ai bien lu l'article et les commentaires de chacun, mais je me demande si reporter la faute tantôt sur le langage, tantôt sur le système d'exploitation est bien raisonnable. Si j'ai une liste de fichiers à traiter dans un ordre précis, je vais définir cet ordre dans mon code au pire, dans un fichier annexe au mieux, et ne pas m'appuyer sur le tri que pourrait faire le système d'exploitation ou tout autre système de stockage (imaginons les fichiers sur un cloud, etc.)

J'imagine que ça offre une certaine souplesse d'ajouter/retirer des fichiers assez facilement que de s'en remettre au tri par le système d'exploitation mais ça me semble être là l'erreur première, d'avoir fait reposer sur le système d'exploitation un prérequis important pour le traitement des données, à savoir l'ordre de traitement des fichiers.

Personnellement, ce qui ressort de ma lecture, n'est ni la faute du langage, ni celle de l'OS, mais celle du savoir que détient le codeur.
Je suppose que ces scientifiques pissent pas mal de code, mais je doute qu'ils aient une maîtrise du langage aussi étendue qu'un développeur (qui varient déjà considérablement suivant le secteur). C'est typiquement ce genre de défauts que l'on retrouve constamment dans le projet d'un étudiant fraîchement sorti de l'école, mais qui apparaît moins souvent par un auteur "expérimenté".

Citation:

---

me semble être là l'erreur première, d'avoir fait reposer sur le système d'exploitation un prérequis important pour le traitement des données

---

Je n'aurais pas mieux résumé. : )

Effectivement, le problème dans l'affaire est la médiocrité du / des programmeur(s).

Et ce n'est pas de la faute de Python s'il est le langage préféré des nuls en prog.

Citation:

---

Envoyé par Xanareld

J'ai bien lu l'article et les commentaires de chacun, mais je me demande si reporter la faute tantôt sur le langage, tantôt sur le système d'exploitation est bien raisonnable

---

C'est pas le sujet, le sujet c'est que ce code n'est pas assez bon, qu'il est bugué, et qu'il a été utilisé sans vérifications. Donc après "les études sont faussées car elle sont financées par des intérêts privées" on a maintenant : "les études sont faussées car elle sont faites avec n'importe quel code pourri trouvé à gauche ou à droite".

Est-ce que les scripts, codes, et algo' dans le domaine de la recherche sont supervisés /vérifiés /approuvés par des codeurs professionnels ?
Parce qu'aux vues de la tendance générale des profils de moutons à 5 pattes dans le secteur IT, je vois très bien le même problème dans le secteur de la recherche ...où en plus, la formation de "programmation pratique" du cursus des moutons à 5 pattes (qui amène plus à être productif, que spécialisé), laisse penser au recruteur et sa hiérarchie, que ce mouton est compétant pour ce critère précis.

Quelqu'un du domaine aurait un avis à donner ? je ne fais que spéculer sur un cas que je ne connais que trop mal.

soyons clair c est arrivé et cela arrivera encore.
developpeur ce sont des formations compléte bac+5 avec des méthodologies complètes et maintenant industrielles.

Il faudrait soit plus de formation sur le dev aux autres sections soit des équipes de dev et d’autres disciplines avec de la ci et des fermes de build. il est évident que les tests auraient detectés ce bug.

Dire que développeur = bac+5 automatique, c'est être un peu sévère non ?
C'est nier l’existence assez courante de profil BTS, voir licence, ou autodidacte + e-learning.

Citation:

---

Envoyé par Steinvikel

Est-ce que les scripts, codes, et algo' dans le domaine de la recherche sont supervisés /vérifiés /approuvés par des codeurs professionnels ?
.....

---

Ayant durant 15 ans jouer le rôle d'interface entre sciences (modèles mathématiques) et applications (implémentation informatique), je suis sur que les "algo" ne sont pas vérifiés par des codeurs professionnels. Ce qui se fait en généralement ce sont des tests qui vérifient des domaines de validités. Pour être plus clair, je suis persuadé qu'il y a une énorme quantité de bugs dans les "codes" scientifiques tout simplement parce qu’il est humainement difficile d’être individuellement bon dans tous les domaines et que l'informatique ne permet pas une transcription parfaitement juste de solutions analytiques.

Citation:

---

Effectivement, le problème dans l'affaire est la médiocrité du / des programmeur(s).

Et ce n'est pas de la faute de Python s'il est le langage préféré des nuls en prog.

---

Je dirais que l'intervention n'a plus rien avoir avec le sujet... c'est plutôt une attaque visée. ... :lol: :lol:

Les résultats sont corrects sous Windows et pas sous Linux.
Nous pouvons en conclure que Windows est plus fiable que Linux.

...ou que le code est plus fiable sous Windows.
le code, ou bien le framework, ou bien le compilateur, ou bien...

Très bel exemple d'humilité et de collaboration! On reconnait ainsi de vrais scientifiques.

Citation:

---

Envoyé par _informix_

Ce genre de bogue explique les disparités des études, les unes prônant le bien fait du café et les autres qui "prouvent" ça nocivité. :mouarf:

---

Et les études du GIEC, c'est en python ??? :mrgreen:

Vous devenez un peu lourds.

C'est pas comme si un bug célèbre ne venait pas de temps en temps défrayer la chronique que ce soit dans le firmware des CPU, dans les OS: Windows, Linux, OSX, bibliothèques SSL,... tous y passent.

Les bugs font partie des risques de cette industrie.

Et lorsqu'on trouve un, on en parle histoire que ceux qui pourraient être impacté soient alertés et installent les corrections.
C'est juste ce qu'il se passe ici.

Après on peut toujours trouver "dommage" que seul quelques professionnels aient la rigueur nécessaire pour coder et puissent profiter des avancées de l'industrie du logiciel pour utiliser de la POO, écrire des suites de tests, des installations qui les tournent en continu pour s'assurer des non-régressions.

Est ce que toutes ces précautions nous affranchissent de découvrir un bug en production? Même pas. Il y en a toujours qui passent à travers.

Il ne faut pas oublier que si l'informatique à un intérêt, c'est pour ce qu'on en fait: les applications qu'elle permet de réaliser.

Et des applications, c'est d'abord des besoins utilisateurs qui vont souvent se débrouiller pour répondre à leurs besoins avec un code certes pourri mais qui le fait à peu près (regardez l'histoire de PHP).

Pas toutes auront la chance d'être vues comme des killers apps potentielles qui mériteraient d'être "industrialisées". Quand çà arrive, on fait appel a des professionnels pour les remettre d'équerre.

Comment croyez vous qu'ont démarré des monstres comme Exchange ou SAP?

Heureusement que c'est comme çà, car sans toutes des nouvelles applications (combien imaginées par les informaticiens?), beaucoup d'entre nous n'auraient pas de boulot.

Citation:

---

Envoyé par jpiotrowski

Et les études du GIEC, c'est en python ??? :mrgreen:

---

Le GIEC compile les résultats sortis de plusieurs modèles d'évolutions du climat qui tournent sur des super calculateurs.
Comme on a besoin de performances, on va utiliser des bibliothèques écrites en Fortran ou en C depuis des dizaines d'années (les lois de la physique changent moins vite que les modes informatique). Au dessus, il y a peut être une couche de Python histoire d'avoir une interface un peu plus facile (c'est à çà que sert un langage de script). Python n'est pas ici un sujet.

- W

Bonjour tout le monde,

Voici le lien du code source original de la publication : https://www.nature.com/articles/nprot.2014.042#s1

Cet article montre deux problèmes hélas aujourd'hui très courants :

1) le libre est bien souvent moins contrôlé que les produits d'éditeur et cela pour une raison simple. La vente engage la responsabilité de l'éditeur qui fait payer sa prestation, son objet, son bien... Et l'engagement de responsabilité implique des dommages et intérêts conséquents en cas de vice caché, et ici c'est bien d'un vice caché qu'il s'agit dans le cas de Python.
Or dans le libre, il n'y a pas de contrat commercial, donc pas de responsable, donc pas d'indemnisation possible.
Chez les éditeurs, cette problématique oblige à passer de nombreuses batteries de tests afin d'éviter de se retrouver pénalisé en cas de faute.... Dans le libre la pression étant inexistante, les bugs sont nombreux et les tests bâclés (lorsqu'il y en a !).... Il n'est qu'a voir le nombre incroyable, de bugs qui persistent dans MySQL/MariaDB (par exemple le fameux GROUP BY qui donne des résultats faux et jamais corrigé depuis l'origine) pour s'en convaincre...

2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent".... Autrefois on faisait un cahier des charges, on montait un projet avec un planning, des étapes de validation et des batteries de tests. Maintenant on développe à l'arrache en mode "quick and dirty" la plupart confondant méthode agile et bousculade !
par conséquent, là aussi les avant test, POC et autre garde fous n'existent plus et les tests finaux ne sont jamais réalisés. Il résulte de tout ceci des gâchis monstrueux qui, peut être, un jour, conduiront à une vision un peu plus réaliste, un peu plus élitiste et sans doute moins prolétaire du développement informatique, qui s'apparent plus, aujourd'hui à du pissage de code qu'à de la réflexion !

A +

Salut,

Citation:

---

Envoyé par SQLpro

1) le libre est bien souvent moins contrôlé que les produits d'éditeur[

---

Avant d'utiliser en production un logiciel libre, on prend quelques précautions comme de savoir ce qu'en font ses utilisateurs. On peut aussi regarder dans la buglist les problèmes soumis et les réponses apportées. Et comme on a les sources regarder un peu les cas d'utilisation qui ont été testé.
Après ben on teste (même pour les logiciels produits par les éditeurs) que çà produit les résultats attendu dans les cas d'utilisation qu'on souhaite.

Et s'il y a plein de bugs et que la communauté des utilisateurs râle ben on utilisera autre chose.

Libre = gratuit mais il y a un autre travail à faire

Citation:

---

Envoyé par SQLpro

Et l'engagement de responsabilité implique des dommages et intérêts conséquents en cas de vice caché, et ici c'est bien d'un vice caché qu'il s'agit dans le cas de Python.

---

Le problème est dans le code qui a été écrit avec Python et non dans Python.

Quand un chercheur ajoute une étape de traitement qui permet de sortir la fréquence des molécules qu'il réalise pour valider une étude... Il doit publier son code pour que d'autres puisse reproduire ses résultats.
Après si d'autres chercheurs réutilisent ce code pour leurs traitements, on n'est pas dans la production logicielle mais dans les échanges normaux d'une communauté scientifique.

Citation:

---

Envoyé par SQLpro

Or dans le libre, il n'y a pas de contrat commercial, donc pas de responsable, donc pas d'indemnisation possible.

---

La plupart des logiciels libres qui ont pignon sur rue peuvent être utilisés librement ou avec un contrat commercial.

Citation:

---

Envoyé par SQLpro

2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent"....

---

Si le client veut de la daube pas cher, on lui livre de la daube pas cher et pleine de bugs. Et si les commerciaux des SSII se couchent devant le client pour faire du chiffre plutôt que d'assumer leur rôle de conseil et dire au client qu'il faut mettre un peu les moyens en fonction la criticité de l'application pour sa production....
Sûr qu'avant on avait des techniciens tant du côté entreprise que développeurs, aujourd'hui un commercial rencontre le directeur des achats et çà discute pépète.

Mais c'est pas un problème de logiciel libre/éditeur, c'est juste des organisations et des patrons qui ont oublié qu'ils n'y a pas que des objectifs financiers...

Citation:

---

* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

---

Ah ces mecs du Sud, toujours dans l’exagération :mouarf:

- W

Citation:

---

Envoyé par SQLpro

Cet article montre deux problèmes hélas aujourd'hui très courants :

1) le libre est bien souvent moins contrôlé que les produits d'éditeur et cela pour une raison simple. La vente engage la responsabilité de l'éditeur qui fait payer sa prestation, son objet, son bien... Et l'engagement de responsabilité implique des dommages et intérêts conséquents en cas de vice caché, et ici c'est bien d'un vice caché qu'il s'agit dans le cas de Python.
Or dans le libre, il n'y a pas de contrat commercial, donc pas de responsable, donc pas d'indemnisation possible.
Chez les éditeurs, cette problématique oblige à passer de nombreuses batteries de tests afin d'éviter de se retrouver pénalisé en cas de faute.... Dans le libre la pression étant inexistante, les bugs sont nombreux et les tests bâclés (lorsqu'il y en a !).... Il n'est qu'a voir le nombre incroyable, de bugs qui persistent dans MySQL/MariaDB (par exemple le fameux GROUP BY qui donne des résultats faux et jamais corrigé depuis l'origine) pour s'en convaincre...

---

Et il y aura toujours des pékins pour dire que c'est normal qu'il y ait des bugs car c'est du libre, tout en étant sévères à l'extrême lorsque des logiciels propriétaires comportent des failles. Et ce sont ces mêmes personnes qui promeuvent l'usage du libre en entreprise et dans le milieu pro. Bref...

Citation:

---

2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent".... Autrefois on faisait un cahier des charges, on montait un projet avec un planning, des étapes de validation et des batteries de tests. Maintenant on développe à l'arrache en mode "quick and dirty" la plupart confondant méthode agile et bousculade !
par conséquent, là aussi les avant test, POC et autre garde fous n'existent plus et les tests finaux ne sont jamais réalisés. Il résulte de tout ceci des gâchis monstrueux qui, peut être, un jour, conduiront à une vision un peu plus réaliste, un peu plus élitiste et sans doute moins prolétaire du développement informatique, qui s'apparent plus, aujourd'hui à du pissage de code qu'à de la réflexion !

---

Il est vrai que l'Agile est parfois/souvent un prétexte pour ne pas s'enquiquiner (pour rester poli) à trop réfléchir et formaliser en amont et à traiter les sujets à vas-y comme je te pousse.
Il y a un article à rédiger sur la face sombre des méthodes dites Agile.

Tout cela me rappelle une anecdote où des résultats en chimie avaient été faussés parce que l'on utilisait des conteneurs en plastique au lieu de conteneurs en verre.
À qui la faute ?