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…
Posté par Psychofox (Mastodon) .
Évalué à 6.
Dernière modification le 27 août 2021 à 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.
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 ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
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.
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…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par QuietApe .
Évalué à 10.
Dernière modification le 27 août 2021 à 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.
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"?
À 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…
Posté par QuietApe .
Évalué à 4.
Dernière modification le 27 août 2021 à 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.
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é).
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.
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 ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
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.
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:
Bien que dans l’interface on voit le caractère de citation double ", dans le format interne c’est l’apostrophe droite simple ':
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
# Mouai...
Posté par ptit_poulet . Évalué à 5.
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 Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 7.
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 Psychofox (Mastodon) . Évalué à 6. Dernière modification le 27 août 2021 à 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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
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 ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Mouai...
Posté par anaseto (site web personnel) . Évalué à 7.
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7.
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…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Mouai...
Posté par QuietApe . Évalué à 10. Dernière modification le 27 août 2021 à 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 pulkomandy (site web personnel, Mastodon) . Évalué à 8.
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 THE_ALF_ . Évalué à 5.
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 QuietApe . Évalué à 4. Dernière modification le 27 août 2021 à 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 THE_ALF_ . Évalué à 10.
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 Guillawme (site web personnel, Mastodon) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 29 août 2021 à 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 ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Mouai...
Posté par barmic 🦦 . Évalué à 2.
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mouai...
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
En tout cas c’était déjà vrai en interne dans Works 1.05 pour DOS en 1988:
Bien que dans l’interface on voit le caractère de citation double
", dans le format interne c’est l’apostrophe droite simple':On voit bien la chaîne
'DLFP\0(et aussi le nombre 42 :*en ASCII,2aen hexadécimal). Le fichierDLFP.WKSest 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 eingrossfilou . Évalué à 3.
N'oublions pas que le problème a aussi existé aussi avec
Retpython, 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
pythondans certain cas (alias symbols):https://www.genenames.org/data/gene-symbol-report/#!/hgnc_id/HGNC:10583
[^] # Re: Mouai...
Posté par _kaos_ . Évalué à 5. Dernière modification le 28 août 2021 à 08:53.
Dans le cas de
R(aucune idée pourpython), c'est quand même pas mal la faute de l'utilisateur.On peut aussi nommer sa variable
cout, ou qui affecterFALSEà la variableTet avoir des surprises…Matricule 23415
# 'any text
Posté par steph1978 . Évalué à 2.
pour pas avoir de conversion automatique, faut utiliser
'(simple quote) avant de saisir un texte qui pourrait être interprétéSuivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.