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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Python Discussion :

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


Sujet :

Python

  1. #21
    Membre régulier
    Profil pro
    Responsable développement
    Inscrit en
    septembre 2007
    Messages
    66
    Détails du profil
    Informations personnelles :
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Responsable développement

    Informations forums :
    Inscription : septembre 2007
    Messages : 66
    Points : 114
    Points
    114
    Par défaut
    Très bel exemple d'humilité et de collaboration! On reconnait ainsi de vrais scientifiques.
    Practice makes perfect !
    C'est par la pratique que l'on parvient à la perfection !
    --------------------------------------------------------------
    Artificial Intelligence Ph.D. Student, Bircham International University (BIU) - Madrid
    Civilian in Côte d'Ivoire, Developer, Network Engineer & Machine Learning Engineer

  2. #22
    Invité
    Invité(e)
    Par défaut Ca chauffe
    Citation Envoyé par _informix_ Voir le message
    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é.
    Et les études du GIEC, c'est en python ???

  3. #23
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    juin 2008
    Messages
    18 417
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 18 417
    Points : 31 833
    Points
    31 833
    Par défaut
    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  4. #24
    Nouveau Candidat au Club
    Profil pro
    ceo
    Inscrit en
    janvier 2010
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : ceo

    Informations forums :
    Inscription : janvier 2010
    Messages : 1
    Points : 1
    Points
    1
    Par défaut code source
    Bonjour tout le monde,

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

  5. #25
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 902
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 902
    Points : 49 641
    Points
    49 641
    Billets dans le blog
    1
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #26
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    juin 2008
    Messages
    18 417
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 18 417
    Points : 31 833
    Points
    31 833
    Par défaut
    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  7. #27
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 317
    Points : 8 277
    Points
    8 277
    Billets dans le blog
    43
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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...

    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.
    Tutoriels et FAQ TypeScript

  8. #28
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2013
    Messages
    662
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : août 2013
    Messages : 662
    Points : 3 056
    Points
    3 056
    Par défaut
    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 ?

Discussions similaires

  1. Réponses: 1
    Dernier message: 09/08/2019, 08h46
  2. Code python dans html
    Par Loenix dans le forum Réseau/Web
    Réponses: 2
    Dernier message: 29/11/2010, 13h31
  3. Exécuter du code python dans un string (python -c cmd)
    Par piloupy dans le forum Général Python
    Réponses: 2
    Dernier message: 14/11/2010, 01h10
  4. executer du code python contenu dans une variable
    Par awalter1 dans le forum Général Python
    Réponses: 6
    Dernier message: 11/11/2010, 21h22
  5. conversion d'indentation dans un code python
    Par KINENVEU dans le forum Général Python
    Réponses: 2
    Dernier message: 26/02/2009, 04h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo