IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

402PARTAGES

30  2 
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.


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 ?

Qu'en pensez-vous ?

Voir aussi

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

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

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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 14/10/2019 à 15:53
Citation Envoyé par Daïmanu Voir le message
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
12  0 
Avatar de Daïmanu
Membre émérite https://www.developpez.com
Le 14/10/2019 à 14:58
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é
10  0 
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 14/10/2019 à 16:43
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.
5  0 
Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 14/10/2019 à 19:17
Citation Envoyé par Bill Fassinou Voir le message
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 : Sélectionner tout
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:
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
5  0 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 15/10/2019 à 15:45
Citation Envoyé par Xanareld Voir le message
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".
4  0 
Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 18/10/2019 à 23:03
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 Voir le message
Et les études du GIEC, c'est en python ???
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
4  0 
Avatar de Bill Fassinou
Chroniqueur Actualités https://www.developpez.com
Le 14/10/2019 à 18:48
Citation Envoyé par Daïmanu Voir le message
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
3  0 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 15/10/2019 à 11:26
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é".

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é. : )
3  0 
Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 22/10/2019 à 19:35
Salut,

Citation Envoyé par SQLpro  Voir le message
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  Voir le message
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  Voir le message
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  Voir le message
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...

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

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

- W
2  0 
Avatar de laurent_ott
Rédacteur https://www.developpez.com
Le 23/10/2019 à 16:23
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 ?
2  0