Closed ThibaultLeCorre closed 1 month ago
Merci pour ce retour !
Je n'ai pas eu de retour de ce type jusqu'ici. Effectivement, il est parfois impossible de typer une variable en "ratio" ou en "stock", mais c'est (normalement !) toujours parce que la colonne contient des valeurs non-numériques. Et lorsque qu'il est impossible de typer une variable comme "identifiant" c'est parce que celle-ci contient des valeurs en double (non-unique). Ne laissant donc plus que les types "catégoriel" et "inconnu".
Serait-il possible que tu partages un jeu de données d'exemple permettant de déclancher ce bug ?
Merci d'avance !
Alors tu viens sûrement de me donner la solution. Certaines absence de valeurs sont traduites par "NA". Je te mets le .csv qui pose problème. Mais je n’arrive pas à expliquer que l'erreur ne soit pas systématique.
emplois_airesdiffusion.csv
Merci beaucoup !
Merci, je vais investiguer sur la base de ton fichier, car normalement il y a du code (précisément ici : https://github.com/riatelab/magrit/blob/master/src/helpers/formatConversion.ts#L144-L146) pour gérer les valeurs NA dans les colonnes qui contiennent valeurs numériques + NA (pour remplacer les NA par la valeur null
en JavaScript et permettre ensuite que la variable soit reconnue comme une variable numérique avec valeurs manquantes).
Peut-être que ça ne fonctionne pas comme prévu (j'ai corrigé un autre bug dans la détection du type des champs cette semaine, peut-être que j'en ai introduit un nouveau au passage... et le fait que ça ne soit pas systématique traduit très probablement un problème dans la logique de détection que j'ai mise en place.).
C'était bien une erreur introduite hier ; le fait que ça ne soit pas systématique dépendait de si la colonne contenait ou non des zéros... :facepalm:
(sur ton jeu de données, ça fonctione pour la variable POPACT
où les NA sont correctement remplacés par des valeurs nulles, et où la variable est correctement typée comme un nombre, mais pas pour les autres variables car elles contiennent des 0).
Je corrige ça et je publie une nouvelle version très prochainement, désolé pour le désagrément !
Super, merci Matthieu ! Bonne fin de journée, Thibault
De: "Matthieu Viry" @.> À: "riatelab/magrit" @.> Cc: "Thibault Le Corre" @.>, "Author" @.> Envoyé: Jeudi 10 Octobre 2024 12:16:17 Objet: Re: [riatelab/magrit] Modification du typage des champs (Issue #143)
C'était bien une erreur introduite hier ; le fait que ça ne soit pas systématique dépendait de si la colonne contenait ou non des zéros... \uD83E\uDD26 (sur ton jeu de données, ça fonctione pour la variable POPACT où les NA sont correctement remplacés par des valeurs nulles, et où la variable est correctement typée comme un nombre, mais pas pour les autres variables).
Je corrige ça et je publie une nouvelle version très prochainement, désolé pour le désagrément !
— Reply to this email directly, [ https://github.com/riatelab/magrit/issues/143#issuecomment-2405538594 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AG3NGWUKWIHBW7FDSHZU5HDZ22R5DAVCNFSM6AAAAABPWYZZ32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBVGUZTQNJZGQ | unsubscribe ] . You are receiving this because you authored the thread. Message ID: <riatelab/magrit/issues/143/2405538594 @ github . com>
C'est corrigé et publié.
Par défaut les champs EMP0
, EMP1
, EMP7
et EMP8
restent typés en "catégoriel" par défaut, mais il est bien possible de changer le type en "stock" ou "ratio" (puisque que le type numérique est bien reconnu en interne, cf. screenshot).
S'ils sont quand même classés en "catégoriel" par défaut c'est parce que Magrit regarde s'il y a de nombreuses modalités qui se répètent et, si c'est le cas, en déduit que c'est probablement des catégories plutôt qu'un stock par exemple.
N'hésite pas en cas de nouveau problème !
Salut,
Un "bug" a été constaté par mes étudiants et celui-ci arrive de manière récurrente et aléatoirement. Il arrive que les champs ne peuvent pas être changés en d'autres types que "catégoriel" ou "inconnu". Pour un même jeu de données le typage impossible d'une colonne en ratio ou en stock n'est pas systématique, tant sur la version locale que sur la version en ligne, ce qui suscite mon incompréhension pour isoler l'origine du problème. J’imagine que ce n'est pas la première fois que cette issue est relevée mais je n'ai pas trouvé de trace. Merci !