Objet : numéro de dossier 00060333
Bref à retenir : Je demande une fonctionnalité glisser-déposer dans Graph Builder pour réduire plusieurs points de données sur une variable d'intérêt sélectionnée [par exemple, le "contraire" de recouvrir ], dans le but d'informer plus intelligent Barres d'erreur SEM déterminées par le N du nombre restant de points de données affichés. Cela corrige plusieurs visualisations statistiquement trompeuses ou incorrectes et augmente considérablement l'efficacité qui nécessite actuellement de nombreuses solutions de contournement qui rendent actuellement difficile l'exploration d'ensembles de données complexes. Cette fonctionnalité rendrait JMP incroyablement plus puissant.
Qu'est-ce qui a inspiré cette demande de liste de souhaits ?Je m'appelle Brian Sweis, MD, PhD. Je suis psychiatre et neuroscientifique comportemental et je travaille à l'hôpital Mount Sinai de New York. Je travaille principalement avec des données comportementales de souris générant des ensembles de données très volumineux et complexes. Les tableaux que je crée dans JMP pour analyser mes données contiennent de nombreux types de données différents, y compris des éléments simples comme les mesures quotidiennes du poids corporel ou des mesures de performance de tâches plus complexes comme les temps de réaction aux essais testés sur une tâche de prise de décision, où je peux parfois avoir 500 essais comme lignes séparées par souris x 40 souris x 60 jours, atteignant facilement 1 million de lignes. J'analyse souvent des moyennes sur des souris, en découpant mes données de différentes manières, notamment en limitant les analyses à une semaine de tests particulière, ou peut-être aux 10 premiers essais d'une journée donnée ou même de plusieurs jours, et ainsi de suite. Lorsque je génère des chiffres, il est essentiel d’explorer de manière fluide ce vaste ensemble de données avec Graph Builder. J'ai souvent besoin de tracer l'erreur standard de la moyenne sur des graphiques à barres ou linéaires, alors qu'en neurosciences comportementales, le terme d'erreur souhaité pour N échantillons est au niveau du nombre d'organismes/souris. Dans les ensembles de données où j'ai de nombreuses répétitions ou échantillons, en particulier s'il s'agit d'une mesure prise plusieurs fois au cours d'une journée ou sur plusieurs jours, et que je souhaite tracer les moyennes de groupe comme décrit ci-dessus, les barres d'erreur SEM sont souvent sous-estimées à tort car N dans le générateur de graphiques est en utilisant le nombre total d'échantillons affichés (par exemple, parfois N = 5 000 échantillons s'ils sont regroupés sur plusieurs jours alors qu'en réalité j'en ai simplement besoin pour être simplement N = 40 souris).
Quelle est l’amélioration que vous souhaiteriez voir ?
J'ai regardé une longue conversation avec un membre de l'équipe d'assistance JMP par e-mail. Nous avons finalement décidé ensemble que la fonctionnalité que je souhaitais serait extrêmement utile si elle était correctement implémentée de manière native dans Graph Builder et n'est actuellement pas possible sans de nombreuses solutions de contournement impliquant la nécessité de générer de nombreux résumés de tableaux supplémentaires, des colonnes de données ou des scripts qui deviennent rapidement intenables lorsque le nombre de variables augmente ou si la manière dont les données sont regroupées doit continuer à changer.
Je vais illustrer avec une série de captures d'écran des exemples de données, le problème et une solution potentielle ci-dessous.
Tout d’abord, voici un exemple de données pour le poids corporel de 10 souris prélevées chaque jour pendant 10 jours, donc N = 100 échantillons au total.
Ensuite, je tracerai ces poids corporels en moyenne sur 10 souris, répartis par jour lorsqu'ils sont déposés dans le groupe X sur Graph Builder.
Vous pouvez apprécier le niveau N = 10 points par jour. Ici, les barres d'erreur moyenne et SEM sont correctes et souhaitées. Cela devient vite problématique ci-dessous.
En supprimant simplement le jour du groupe X, toutes les données sont interrogées et s'effondrent sur plusieurs jours, mais nous avons maintenant les 100 échantillons affichés ici. Chaque souris apparaît ici 10 fois. Ici, la moyenne est correcte, mais la barre d'erreur SEM utilise N=100 comme terme d'erreur, et non n=10 souris, ce qui devrait presque toujours être le cas en neurosciences comportementales. Il s'agit d'un problème simple et courant qui serait incroyablement utile si JMP intégrait une solution native dans le générateur de graphiques. Voyez ci-dessous comment cela devient plus complexe et ne peut pas être résolu facilement avec les solutions de contournement actuelles.
La chose évidente à faire est d’utiliser la fonction Résumé du tableau.
Je dois souvent m'appuyer sur cela, mais je dois généralement faire des centaines de résumés de tableaux à partir de mon ensemble de données d'origine lorsque j'ai des variables plus complexes. Lorsque j’explore mes données, cela devient très, très rapidement incontrôlable. Et cela est généralement associé à un arrangement complexe consistant à devoir appliquer des filtres de données, à faire des résumés de résumés, etc.
L'un des membres du support JMP a suggéré d'ajouter de nouvelles colonnes dans lesquelles il calcule la moyenne sur 10 jours par souris, et vous pouvez voir ci-dessous, ce genre de travail, mais est assez fastidieux juste pour une seule variable comme le poids corporel, et ne s'y prêterait pas bien. à un tableau contenant par exemple 100 autres variables beaucoup plus complexes comme les mesures comportementales de performance des tâches. Cela seul ajouterait 8 colonnes x 100 variables et deviendrait ingérable. Même extraire la formule pour de telles colonnes et remplacer la variable utilisée par la formule n'est pas idéal et extrêmement manuel/laborieux.
Cela est particulièrement vrai si je souhaite subdiviser mes données mais en plusieurs niveaux, surtout si les niveaux sont constitués de points de données asymétriques. Et surtout si j'explore mes données dans le générateur de graphiques et que je modifie souvent ces paramètres de regroupement à la volée. Voir ci-dessous.
Voici un autre cas d'utilisation dans lequel j'utilise également des filtres de données locaux pour sous-ensembler mes données. Cela devient de plus en plus problématique à mettre en œuvre avec des scripts ou de nouvelles colonnes.
Vous pouvez voir que si je sous-ensemble et inclut uniquement les jours 7 à 10, à gauche, lorsque je divise par jour en niveaux du groupe X, bien sûr, il affiche n = 10 par barre uniquement pour les jours sélectionnés comme prévu, mais les données regroupées à droite a toujours n=40.
Essentiellement, la solution optimale serait d'implémenter un moyen de glisser-déposer une variable d'intérêt dans une nouvelle zone de dépôt dans le générateur de graphiques. Ci-dessous, je décris deux solutions possibles que j'imagine :
A gauche annoté en le rouge est une méthode centrée sur "l'identification de la souris" , soit comme moyen de déposer l'ID de la souris sur le générateur de graphiques et/ou comme option de sélection dans l'option intervalle d'erreur/style d'erreur, l'objectif étant de réduire les 10 points de données par souris en un seul point de données par souris de manière native. le tout dans le générateur de graphiques ici. Ainsi, nous pouvons indiquer à Graph Builder en fin de compte quelle variable nous voulons déterminer le terme d'erreur (par exemple, via des valeurs uniques, en faisant la moyenne sur les points restants). A droite annoté dans le vert est une méthode centrée sur le « jour » - la variable qui ne m'intéresse pas dans cet exemple particulier et sur laquelle je souhaite réduire. Considérez cela comme le "à l'opposé de la superposition" - au lieu de diviser par cette variable, je souhaite réduire les données sur cette dimension spécifique (essentiellement la même chose que si je quittais intentionnellement jour hors de la variable de regroupement Tableau Résumé). J'ai le sentiment que la méthode rouge a plus de sens, mais que l'utilisateur peut vouloir indiquer d'une manière ou d'une autre sur quelle variable j'essaie explicitement de réduire (par exemple, le jour). Quoi qu'il en soit, les deux vous mèneraient au graphique à barres idéalisé avec le terme d'erreur correct (n = 10 points de données au total, 1 par souris). Lors de l'exploration visuelle des données dans le générateur de graphiques, cela pourrait résoudre les exemples plus complexes que je décris ci-dessus (par exemple, avec des niveaux personnalisés, des filtres de données, etc.).
Pourquoi cette idée est-elle importante ?
Disposer d'un moyen rapide d'ajuster les barres d'erreur plus intelligentes à l'aide de ma suggestion rendrait l'exploration d'ensembles de données complexes très efficace si elle est directement intégrée à Graph Builder, de manière native. Cela corrige plusieurs visualisations trompeuses ou statistiquement incorrectes qui ne représentent souvent pas les analyses sous-jacentes que de nombreux scientifiques et chercheurs effectuent lorsqu'ils utilisent des organismes individuels comme terme d'erreur supposé. Cela évite de nombreuses solutions de contournement qui deviennent rapidement lourdes, intenables ou impossibles à gérer avec des ensembles de données plus volumineux ou plus complexes.Ce niveau de contrôle dans Graph Builder serait sans précédent et je pense que ce serait un outil unique et incroyablement puissant.
