• # Mouai...

    Posté par  . Évalué à 5 (+6/-2).

    J'avais vu un article il y a une 10aine de jours concernant cette info. Il en ressort qu'il s'agit surtout d'utilisateur qui ne savent pas utiliser leur outil de travail comme on le trouve dans la plus part des jobs. Mais c'est bien sûr la faute du logiciel…

    • [^] # Re: Mouai...

      Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

      Ben oui, l'idée est que ces logiciels sont tellement intuitifs qu'il n'est pas nécessaire d'avoir une formation dessus :-)

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: Mouai...

      Posté par  . Évalué à 6 (+3/-0). Dernière modification le 27/08/21 à 14:23.

      Oui, je suis tout à fait nul avec excel et libroffice calc, et réalise souvent mes manipulations de données de tableau via awk, d'autres outils en ligne de commande ou si ça devient bien gruik numpy ou pandas. Mais je sais très bien que si je me plante mes résultats peuvent être totalement à l'ouest.

      Et je connais pas mal de gens dans le monde médical utilisant python parce que c'est ce qu'on leur a montré comment faire mais qui sont conscients être de piètres programmeurs et adepte du copier/coller et de stackoverflow.

    • [^] # Re: Mouai...

      Posté par  . Évalué à 6 (+5/-0).

      Bah oui, des logiciels qui sont poussés avec force en arguant que c'est vachement simple et intuitif et à porté des nouveaux nés. Et du coup des entreprises qui en attendent une utilisation immédiate et surtout pas de formation dessus (tellement c'est censé s'utiliser les doigts dans le nez.) Alors faut-il du coup blâmer des usagers qui les prennent facilement et ne sont pas des ingénieur-e-s qualifié-e-s de l'outil ?

    • [^] # Re: Mouai...

      Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

      La faute est partagée, en effet. Cela dit, j'ai du mal à comprendre la pertinence d'avoir l'auto-correction activée par défaut (si j'ai bien compris, j'utilise pas Excel) pour les applications courantes d'un tableur. C'est le truc qui ne surprend pas dans un traitement de texte, mais pour un tableur, c'est pas forcément très intuitif.

      • [^] # Re: Mouai...

        Posté par  . Évalué à 7 (+6/-0).

        C'est sensé rendre la chose simple et intuitif pour M. Michu : ça corrige ses fautes d'orthographe, ça reconnait les cellules de nombres pour le lui formater différemment des cellules de texte, ça reconnait même les dates et les montants, etc.
        Même pour le traitement de texte, j'ai jamais pu accrocher ces trucs qui savent mieux que vous ce que vous pensez (manque de bol leur corrections se trompe trop souvent en ce qui me concerne) et comment vous devez le présenter. Cette tendance se trouve maintenant dans les messageries en tout genre et les réponses toutes faites…

    • [^] # Re: Mouai...

      Posté par  . Évalué à 10 (+9/-0). Dernière modification le 27/08/21 à 14:33.

      L’article parle d’erreurs bien plus systématiques liées à excel (conversion de gènes en date, mois, etc.) que du fait d’un utilisateur isolé.
      Et comme ils le mentionnent, la pertinence d’utiliser un tableur pour des analyses approfondies est sérieusement à questionner, surtout avec l’existence de langages comme R ou Python qui sont bien plus adaptés et deviennent la norme en biologie.
      Par exemple, en écologie, qui est mon domaine, c’est R qui est largement enseigné et utilisé pour faire du traitement de données un peu sérieux.

      • [^] # Re: Mouai...

        Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

        Le problème est de savoir quand on est en train de faire un truc "un peu sérieux" ou un truc "vite fait et jetable".

        Ça m'est arrivé plusieurs fois de me dire "ça va je peux faire ça en 3 lignes de bash" et de me retrouver des mois plus tard à regretter de pas avoir fait du Python. Maintenant, j'arrête d'écrire du bash dès que le script dépasse 3 lignes, c'est le moment ou il est encore facile de le convertir en Python avant qu'il ne soit trop tard.

        À partir de quand un traitement de données devient-il "un peu sérieux"?

        • [^] # Re: Mouai...

          Posté par  . Évalué à 5 (+4/-0).

          À partir de quand un traitement de données devient-il "un peu sérieux"?

          Facile. À partir du moment où tu commences à te maudire de ne pas avoir utilisé Python, justement ☺

          L'idéal serait de toujours supposer qu'un traitement de de donné risque de devenir sérieux à un moment où à un autre,et donc de toujours utiliser l'outil adéquat, juste au cas où, même si cela semble overkill sur le moment. Malheureusement, il est difficile d'avoir ce genre de réflexe, je le reconnais…

        • [^] # Re: Mouai...

          Posté par  . Évalué à 4 (+3/-0). Dernière modification le 27/08/21 à 16:32.

          Vu que l’article parle d’utilisation d’excel pour des analyses dans des publications scientifiques, je pense qu’on peut supposer qu’il s’agit de traitement de données « un peu sérieux » :)
          Après, c’est complètement ok d’utiliser des outils plus simples si c’est juste pour explorer les données, mais pour un article destiné à être publié, il me semble préférable d’utiliser des outils plus robustes.

      • [^] # Re: Mouai...

        Posté par  . Évalué à 10 (+9/-0).

        Tout à fait. Il s'agit surtout de la conversion automatique de ce que tu rentre en un format donné. Du genre tu tapes "1", il reconnait que c'est un nombre, si tu tape "un", il reconnait que c'est du texte, et dans chaque situation, le type de la cellule est automatiquement choisi.

        Et effectivement, c'est très pénible dans un certain nombre de cas, et je ne suis pas sur que ce soit désactivable (mais je serais heureux d'avoir tord…). Le pire de la détection est justement celle qui reconnait (ou croit reconnaître) une date. Dans un des problèmes rencontré, tu veux le texte "MARCH-1", tu te retrouve avec la date du premier mars.

        J'ai testé avec libreoffice (la seule chose que j'utilise, mais j'imagine que c'est pareil avec excel), tu as beau désactiver la correction automatique, la détection automatique du type n'est pas désactivable globalement, elle. La seule solution est de régler le type de la cellule avant d'y écrire. C'est un point à savoir, qui n'est pas forcément évident, et je ne suis pas sur que grand monde ne le sache.

        L'exemple donné dans l'article montre bien le problème. Si on ne force pas le type de la cellule en avance, la seule manière que j'ai trouvé de rentrer le texte "MARCH-1", c'est de taper 'MARCH-1 (avec un ' avant le texte). Mais il y a une subtilité: si on tape 'MARCH1, on se retrouve avec le texte "'MARCH1"… le ' est conservé dans le texte! Ici, MARCH1 n'est pas vu comme une date, donc la logique retenue est que l'on voulait conserver le ' devant le MARCH1. Bref, si on veut entrer "MARCH1", il faut l'entrer tel quel, sans le '… simple non? Et bien entendu, je pense que tout cela dépends de la localisation du tableur (que je force en anglais, sinon c'est trop le merdier pour faire reconnaître correctement les nombres, à cause de la différence entre l'utilisation du point ou de la virgule décimales en fonction des situations).

        Question subsidiaire: comment rentrer le texte "'MARCH-1" dans une cellule, sans forcer au préalable le format de la cellule en "texte"? (personnellement, je n'ai pas trouvé).

        • [^] # Re: Mouai...

          Posté par  (site Web personnel) . Évalué à 2 (+2/-1).

          Tout à fait. Il s'agit surtout de la conversion automatique de ce que tu rentre en un format donné. Du genre tu tapes "1", il reconnait que c'est un nombre, si tu tape "un", il reconnait que c'est du texte, et dans chaque situation, le type de la cellule est automatiquement choisi.

          Et effectivement, c'est très pénible dans un certain nombre de cas, et je ne suis pas sur que ce soit désactivable (mais je serais heureux d'avoir tord…). Le pire de la détection est justement celle qui reconnait (ou croit reconnaître) une date. Dans un des problèmes rencontré, tu veux le texte "MARCH-1", tu te retrouve avec la date du premier mars.

          Pour moi le problème c’est surtout que la détection automatique de type dans les tableurs se fait individuellement pour chaque cellule. Avec R, pandas et sûrement d’autres implémentations d’une structure de dataframe, il y a aussi une détection automatique de type, mais elle opère par colonne (donc si une cellule ressemble à une date dans une colonne où toutes les autres cellules sont clairement du texte, toute la colonne sera typée texte). Si les tableurs encourageaient une organisation « tidy data » (les colonnes sont des variables, les lignes sont des observations), ils pourraient aussi faire la détection automatique de type sur les colonnes entières. Mais si on laisse l’utilisateur choisir ce que les colonnes et lignes signifient, la détection de type ne peut pas être autrement que par cellule, parce qu’on ne sait pas si ce sont les colonnes ou les lignes qui représentent les variables.

          • [^] # Re: Mouai...

            Posté par  . Évalué à 3 (+0/-0).

            Il faudrait une ligne de type pour le tableau en dessous. J'imagine que la limite est quand plusieurs tableaux sont présent dans la feuille.

            "La première sécurité est la liberté"

        • [^] # Re: Mouai...

          Posté par  . Évalué à 4 (+3/-0). Dernière modification le 29/08/21 à 23:47.

          Noter que le problème se pose aussi quand bien même on veut un nombre : les zéros initiaux sont toujours supprimés et, à partir d'un certain nombre de chiffres, les entiers sont transformés en flottants… Parfois on veut l'inverse

          Sinon, il semble que c'est bien l'apostrophe pour débuter la saisie en temps que texte. À voir si c'était ainsi dans Quattro Pro et Lotus 1-2-3, mais quasiment tous font ça maintenant.
          Mais quand on veut vraiment insérer l'apostrophe il faut faire des acrobaties… (dont la double apostrophe… et la manip inverse… autant de trucs qui sont normalement abordés dans les formations ?)

          Vous avez dit simple ?

          • [^] # Re: Mouai...

            Posté par  . Évalué à 2 (+0/-0).

            Je crois que personne ne pense que excel est simple. Il est abordable. On peu commencer à faire des trucs avec plus facilement qu'avec R par exemple, mais c'est tout.

          • [^] # Re: Mouai...

            Posté par  (site Web personnel) . Évalué à 3 (+0/-0).

            Sinon, il semble que c'est bien l'apostrophe pour débuter la saisie en temps que texte. À voir si c'était ainsi dans Quattro Pro et Lotus 1-2-3, mais quasiment tous font ça maintenant.

            En tout cas c’était déjà vrai en interne dans Works 1.05 pour DOS en 1988:

            Microsoft Works 1.05 pour DOS

            Microsoft Works 1.05 pour DOS

            Bien que dans l’interface on voit le caractère de citation double ", dans le format interne c’est l’apostrophe droite simple ':

            $ hexdump -C DLFP.WKS 
            00000000  00 00 02 00 04 04 05 54  02 00 00 00 25 54 00 00  |.......T....%T..|
            00000010  06 00 08 00 00 00 00 00  00 00 01 00 02 00 01 00  |................|
            00000020  ff 03 00 01 00 00 04 00  01 00 00 05 00 01 00 ff  |................|
            00000030  01 54 0c 00 00 00 00 00  00 00 01 00 01 00 00 00  |.T..............|
            00000040  07 00 1f 00 00 00 00 00  f1 00 0a 00 07 00 13 00  |................|
            00000050  00 00 00 00 00 00 00 00  00 00 00 00 04 00 04 00  |................|
            00000060  4a 00 00 31 00 01 00 01  24 00 01 00 00 24 54 04  |J..1....$....$T.|
            00000070  00 00 00 18 00 23 54 16  00 89 05 6e 04 6e 04 6e  |.....#T....n.n.n|
            00000080  04 c7 41 83 2e 01 00 00  00 00 00 c4 02 c4 02 26  |..A............&|
            00000090  00 f2 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
            000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
            *
            00000180  00 00 00 00 00 25 00 f2  00 50 61 67 65 20 2d 20  |.....%...Page - |
            00000190  26 70 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |&p..............|
            000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
            *
            00000270  00 00 00 00 00 00 00 00  00 00 00 0f 00 0b 00 f1  |................|
            00000280  00 00 00 00 27 44 4c 46  50 00 02 54 02 00 a5 00  |....'DLFP..T....|
            00000290  0d 00 07 00 f1 00 00 01  00 2a 00 01 00 00 00     |.........*.....|
            0000029f
            

            On voit bien la chaîne 'DLFP\0 (et aussi le nombre 42 : * en ASCII, 2a en hexadécimal). Le fichier DLFP.WKS est ici. Note: le surlignage rouge est le pointeur de la souris, et oui LibreOffice sait toujours les importer.

            ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Mouai...

        Posté par  . Évalué à 3 (+2/-0).

        N'oublions pas que le problème a aussi existé aussi avec R et python, dans une moindre mesure.

        Le symbol de ce gène a causé pas mal de soucis avec R:
        https://www.genenames.org/data/gene-symbol-report/#!/hgnc_id/HGNC:7625

        Celui-ci avec python dans certain cas (alias symbols):
        https://www.genenames.org/data/gene-symbol-report/#!/hgnc_id/HGNC:10583

        • [^] # Re: Mouai...

          Posté par  . Évalué à 5 (+3/-0). Dernière modification le 28/08/21 à 08:53.

          Dans le cas de R (aucune idée pour python), c'est quand même pas mal la faute de l'utilisateur.

          On peut aussi nommer sa variable c ou t, ou qui affecter FALSE à la variable T et avoir des surprises…

  • # 'any text

    Posté par  . Évalué à 2 (+0/-0).

    pour pas avoir de conversion automatique, faut utiliser ' (simple quote) avant de saisir un texte qui pourrait être interprété

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.