Mauvais fractionnement ?Supposons que j'ai cette table :
| Catégorie |
Article |
Niveau |
| A |
1 |
delta |
| A |
2 |
fox-trot |
| A |
3 |
hôtel |
| B |
1 |
Juliette |
| B |
3 |
cinq |
Notez que la catégorie = B, l'élément = 2 est manquant.
Si j'essaie de « diviser » ce tableau avec « Diviser par » = Catégorie et « Diviser les colonnes » = Niveau, et « Conserver tout », cela renvoie ceci :
| Article |
A |
B |
| 1 |
delta |
Juliette |
| 2 |
fox-trot |
cinq |
| 3 |
hôtel |
|
Notez que sur la table nouvellement divisée, il est indiqué que Item=2,Category=B est « lima », mais c'est incorrect : cette cellule doit être vide et « lima » doit être sous Item=3,Category=B.
S'agit-il d'une erreur utilisateur ou d'un bug dans JMP ?
Fusion et nettoyage des donnéesRe : Mauvais empilement ?Bonjour @BHarris , essayez d'utiliser un élément dans un groupe. Le résultat sera celui escompté.
Meilleur,
Re : Mauvais empilement ?Oui, cela semble fonctionner.
Pouvez-vous m'expliquer ce qui se passe ? J'aimerais comprendre pourquoi l'étape de groupe était nécessaire.
Re : Mauvais empilement ?Bien sûr, le fractionnement sans groupe s'effectue littéralement par ligne et ne tient pas compte du fait qu'un élément manque pour la catégorie. Le groupe force le niveau à séparer par élément pour chaque catégorie en examinant d'abord l'élément, puis la catégorie.
Depuis l'aide en ligne ( https://www.jmp.com/support/help/en/18.2/?os=mac&source=application#page/jmp/split-columns-in-data-tables.shtml
Groupe
Spécifie une variable de groupe lorsque vous souhaitez que vos données soient réparties au sein de chaque groupe de la variable sélectionnée. Chaque groupe génère une ligne dans la table de sortie. Vous devez également spécifier les variables requises, « Répartir par » et « Répartir les colonnes ».
Remarque : si la variable que vous souhaitez regrouper contient des groupes inégaux ou est dans un ordre aléatoire, la spécifier comme variable de groupe garantit que vos données sont correctement restructurées et que toutes les valeurs manquantes sont attribuées aux emplacements appropriés.
Sinon, vous devrez ajouter une ligne supplémentaire et définir la catégorie et l'élément, mais laisser le niveau vide pour cette ligne.
J'espère que cela aide.
Re : Mauvais empilement ?Plus j'y réfléchis, moins cela a de sens. Je ne comprends pas pourquoi split se comporterait ainsi, quelles que soient les circonstances ; c'est comme si les développeurs avaient simplement imbriqué des boucles en espérant que les données tomberaient au bon endroit…
Je me demande si (a) je suis encore trop stupide pour comprendre la raison sous-jacente de ce comportement, (b) cela a été implémenté de cette manière pour offrir des performances élevées (divisions rapides sur de grandes tables) où les entrées sont entièrement factorielles et l'utilisateur est censé savoir que cette hypothèse est faite, ou (c) c'est vraiment juste un bug qui doit être soumis/corrigé.
(Je ne serai pas offensé si c'est (a).;) )
Re : Mauvais empilement ?Pouvez-vous développer vos pensées ?
Je dirais plutôt le contraire :
Si les données d'entrée sont bien structurées, vous pouvez les diviser sans aucun soin.
Si les données d'entrée ne sont pas bien structurées - mais contiennent en plus des informations de regroupement, il existe toujours la possibilité d'utiliser ces informations de regroupement pour indiquer à JMP ce qu'il doit faire.
Ce qui ne fonctionne pas :
l'utilisateur connaît les informations de regroupement (il y a la colonne) mais ne le dit pas à JMP (via l'interface graphique).
Il n’est donc pas étonnant que JMP n’utilise pas les informations de regroupement.
[il existe d’autres cas où JMP applique certaines suppositions | correction automatique - et l’utilisateur s’interroge sur la créativité].
Re : Mauvais empilement ?Que pensez-vous de l'ensemble de données fourni dans la question initiale ? Est-il « bien structuré » ?
Et que pensez-vous du comportement actuel de JMP lors du fractionnement de cette table ?
Je crois comprendre que les colonnes « Fractionner par » correspondent aux valeurs que vous souhaitez voir apparaître dans les en-têtes de colonne du nouveau tableau, et que les colonnes « Fractionner les colonnes » correspondent aux valeurs que vous souhaitez voir apparaître dans les cellules de ces nouvelles colonnes. Je ne comprends toujours pas ce que signifie « regroupement » dans ce contexte.
Re : Mauvais empilement ?Votre tableau de données initial est « bien structuré ».
Le concept de regroupement peut être pensé en termes de lignes de la table de données d'entrée qui doivent être regroupées pour définir une ligne de sortie spécifique.
Re : Mauvais empilement ?Une autre façon d'expliquer :
Vos colonnes « Catégorie » et « Niveau » (seules) ne sont pas bien structurées - il faut des informations supplémentaires comme
@BHarris a écrit : Notez que la catégorie = B, l'élément = 2 est manquant.
pour informer les autres du fait : entre la rangée n°5 et la rangée n°6, il manque quelque chose.
Cas n°1 :
L'utilisateur n'informe pas JMP de l'existence de la colonne « Item » (« Item » n'est pas utilisé dans l'interface graphique **)
JMP n’a alors pas suffisamment de connaissances pour faire le travail correctement.
Cas n°2 :
Il existe une troisième zone de largage. Elle permet à l'utilisateur d'utiliser
@BHarris a écrit : Notez que la catégorie = B, l'élément = 2 est manquant.
de manière structurée - comme une colonne de regroupement .
« Groupement » correspond très bien à ce que vous souhaitez :
Fournissez à JMP des informations supplémentaires afin que les entrées puissent être placées dans des lignes spécifiques, déterminées non pas par le rang (ligne (), catégories) des données d'entrée, mais regroupées via des colonnes de regroupement.
**) modifier:
« Élément » est utilisé dans l'interface graphique - implicitement via « Conserver tout »
mais c'est trop « passif » - voir ci-dessous.
Re : Mauvais empilement ?@hogi -- vous avez perturbé quelque chose ici, l'idée que je n'incluais la colonne Item nulle part dans l'interface, et donc il y a une implication que peut-être l'algorithme Split n'est même pas vraiment conscient de son existence.
Je pensais que *toutes* les colonnes étaient importantes dans l'opération de fractionnement, et j'essayais de conserver toutes les relations autant que possible, par exemple, que « lima » n'était également associé qu'à l'élément « 3 ». Maintenant, je me demande si toutes les autres colonnes doivent regrouper des colonnes si je fais « Conserver tout »…
J'espère un jour atteindre le statut de JMP-Master et être pleinement éclairé. Peut-être comprendrai-je alors pourquoi JMP n'utilise pas implicitement toutes les autres colonnes « Conservées » du rôle Groupe. En attendant, il continuera probablement à me rendre nerveux, car son comportement dans ces conditions n'est pas évident, produit des données de sortie erronées dans des conditions parfois difficiles à identifier et n'est pas suffisamment bien documenté pour que je puisse le comprendre. Au moins, cette nervosité me permettra d'être plus vigilant à l'avenir.
Merci.
Re : Mauvais empilement ?Vous l'avez mentionné, mais il est peut-être utile de l'écrire explicitement :
JMP applique la règle :
- Groupe : Conserver et utiliser pour regrouper
- Garder : garder (~ ne pas laisser tomber)
@BHarris a écrit :
Maintenant, je dois essayer de déterminer si toutes les autres colonnes doivent être des colonnes de regroupement si je fais « Conserver tout »...
Je suppose que oui.
Vous pouvez essayer les deux méthodes, vérifier les différences, puis décider.
Le groupe vous aide à structurer vos données. Si elles sont déjà structurées, cela ne pose aucun problème. Si elles ne le sont pas, cela garantira un résultat pertinent.
Avec Keep, vous devez savoir précisément ce que vous faites. Voici quelques exemples.
Ces petites discussions au sein de la communauté aident beaucoup à comprendre, à remettre en question et à peaufiner les connaissances de l'utilisateur.
Voici un recueil de questions amusantes pour débutants sur JMP, soulevées lors de nos sessions de coaching utilisateur. Je les ai rassemblées pour aider les autres utilisateurs à comprendre JMP. Nombre de ces questions sont purement rhétoriques : elles illustrent que parfois, c'est juste le jargon JMP qui rend la compréhension de la logique JMP complexe.
@BHarris a écrit :
D'ici là, il continuera probablement à me rendre nerveux, car son comportement dans ces conditions n'est pas évident, produit des données de sortie erronées dans des conditions difficiles à identifier et n'est pas suffisamment bien documenté pour que je puisse le comprendre. Au moins, cette nervosité me permettra de rester plus vigilant à l'avenir.
Je suis d'accord. Il est essentiel de savoir ce que fait JMP, et de le connaître avec suffisamment de détails pour que l'utilisateur se sente capable de faire ce qu'il faut. Sans inquiétude, sans surprise. Si un imprévu survient, l'utilisateur commence à s'inquiéter. Où sont les autres situations où JMP fait quelque chose d'inattendu ?!?!
Il y a peut-être une fonctionnalité intéressante dans JMP, mais elle agace ou effraie les utilisateurs - du moins ceux qui ne s'attendent pas à ce que fait JMP...
Disposer d'une carte de ces pièges peut aider les utilisateurs à y échapper. Chaque utilisateur JMP devrait disposer d'une telle carte pour se sentir en sécurité lorsqu'il travaille avec JMP.
Même si les détails sont bien documentés - JMP est tellement puissant -, en même temps il y a trop peu et trop de documentation !
Il est donc difficile de trouver les bonnes informations. Le LearnBot simplifie grandement la tâche, mais il ne connaît pas encore tous les détails.
Re : Mauvais empilement ?Un cas extrême pour Split avec Garder sans Regroupement
Garder : nom (le nom n'est pas utilisé pour le regroupement)
lorsque 2 lignes sont fusionnées en une seule ligne, de nombreux « noms » sont perdus.
Le premier élément *) gagne, nous commençons donc par les noms féminins, tous les noms masculins sont abandonnés.
Tous les noms sont masculins ? Non, à la fin, il reste quelques étudiants masculins.
*) Il n'existe AUCUNE règle universelle pour toutes les plateformes de tables : quelle valeur sera conservée et quelle valeur sera perdue.
Join conserve également la première valeur (et ne se soucie pas des valeurs suivantes).
La mise à jour essaie de conserver chaque valeur et la dernière « colle » - c'est pourquoi Tables/Update est si lent (l'exécution de la commande peut prendre des heures) : Accélérer Tables/Update
Re : Mauvais empilement ?
@hogi a écrit :
Le premier élément *) gagne
oups... c'est juste vrai pour les colonnes ajoutées via Garder .
Pour les colonnes fractionnées , Split se comporte comme Update : la dernière « colle ».
J'ai essayé d'illustrer cela avec cet exemple où j'ai marqué les entrées « nom » et les entrées de séparation H/F qui se retrouvent dans l'ensemble de données final. On peut voir :
- colonnes ajoutées via Garder (comme le nom) : Rang=1 (prendre la première, ignorer les suivantes)
- lignes ajoutées via Split Columns (hauteur --> M/F) : RankReverse=1 (la dernière « colle »)
Re : Mauvais empilement ?Le comportement suit une logique, mais on peut se demander si la logique est simple / attendue par chaque utilisateur : )
Je me demande si « Conserver tout » est le bon choix par défaut ? Si JMP commence par
... alors un utilisateur qui active l'option Garder tout peut consulter la documentation pour être sûr qu'elle fait ce qu'il veut.
JMP pourrait même afficher un avertissement : « Êtes-vous sûr de vouloir utiliser Keep ? Il vaut mieux utiliser Group ? »
Sous la ligne : Pas de surprises | anxiété pour les utilisateurs qui n'utilisent pas l'option.
Bien plus dangereux que Split : Tables / Mise à jour
L'interface par défaut commence également par « Tous »
a) pour ajouter des colonnes
b) pour Remplacer les colonnes (!)
Il y a quelques années, j'ai considéré qu'il était suffisamment dangereux d'écrire un AddIn qui remplace les paramètres par défaut par :
L'avantage supplémentaire : avec ce changement, la plateforme ne démarre pas avec un paramètre qui tente de mettre à jour des milliers de colonnes.
Cela le rend beaucoup plus rapide que l'original 
https://community.jmp.com/t5/JMP-Wish-List/Speed-up-Tables-Update/idc-p/653334/highlight/true#M4531
Re : Mauvais empilement ?J'ai ajouté le sujet à Attention : Endroits où Jmp fait quelque chose d'inattendu
Re : Mauvais empilement ?J'aimerais bien voir un jour une animation montrant le fonctionnement du fractionnement (et de l'empilement). J'imagine les valeurs des colonnes fractionnées transférées vers les en-têtes de colonnes, et les colonnes fractionnées transférées vers les cellules de ces nouvelles colonnes. (J'ai été surpris d'apprendre que si plusieurs colonnes fractionnées sont créées pour une même colonne fractionnée, de nouvelles colonnes numérotées sont créées.)
Mais le plus intéressant se produit lorsqu'il y a des conflits, par exemple lorsque plusieurs valeurs se retrouvent dans la même cellule. JMP émet un avertissement (ce qui est formidable !), mais cet article provient d'un ensemble de données qui semblait correctement divisé. Après l'avoir étudié en profondeur, j'ai réalisé que ce n'était pas le cas et j'avais ignoré cet avertissement, car je ne le comprenais pas.
Mon avis : l'avertissement devrait être modifié : « Plusieurs lignes, potentiellement avec des valeurs différentes, des colonnes à conserver sont mappées vers la même ligne dans le tableau fractionné. Une seule valeur de chaque colonne est conservée. » ---> : « Plusieurs valeurs sont mappées vers la même cellule ; une seule est conservée. »
Re : Mauvais empilement ?
@BHarris a écrit :
J'ai été surpris tout à l'heure d'apprendre que s'il existe plusieurs colonnes fractionnées pour une colonne fractionnée donnée, de nouvelles colonnes numérotées sont créées.
si plusieurs colonnes fractionnées sont utilisées, JMP crée les noms de colonnes comme une combinaison du nom de la colonne fractionnée et de l'entrée de la colonne fractionnée :
Si une seule colonne est sélectionnée comme colonne fractionnée, le nom de la colonne fractionnée n'est pas inclus dans le nom de la colonne :
Mes collègues lèvent les yeux au ciel lorsque je commence à utiliser Big Class pour expliquer une fonctionnalité de JMP.
Mais c'est une astuce merveilleuse d'utiliser un ensemble de données alternatif pour jouer avec les paramètres :
avec « M » et « F », il est évident ce que fait JMP, pas besoin de s'interroger sur les « chiffres » qui apparaissaient avec l'ensemble de données d'origine.
Big Class semble très simple, mais il est suffisamment compliqué pour expliquer de nombreux détails.
Il ne manque que les colinéarités...
