Asunto: Número de caso 00060333
Breve conclusión: Solicito una función de arrastrar y soltar en Graph Builder para colapsar múltiples puntos de datos en una variable de interés seleccionada [por ejemplo, el "opuesto" de cubrir ], con el objetivo de informar más inteligente Barras de error SEM determinadas por el N del número restante de puntos de datos mostrados. Esto corrige múltiples visualizaciones estadísticamente engañosas o incorrectas y aumenta drásticamente la eficiencia que actualmente requiere numerosas soluciones que actualmente dificultan la exploración de conjuntos de datos complejos. Esta característica haría que JMP fuera increíblemente más poderoso.
¿Qué inspiró esta solicitud de lista de deseos?Mi nombre es Brian Sweis, MD, PhD. Soy psiquiatra y neurocientífico del comportamiento y trabajo en el Hospital Mount Sinai de la ciudad de Nueva York. Trabajo principalmente con datos de comportamiento del mouse generando conjuntos de datos muy grandes y complejos. Las tablas que creo en JMP para analizar mis datos tienen muchos tipos diferentes de datos, incluidos elementos simples como medidas diarias de peso corporal o medidas de desempeño de tareas más complejas, como tiempos de reacción de prueba probados en una tarea de toma de decisiones, donde a veces puedo tener 500 pruebas como filas separadas por ratón x 40 ratones x 60 días, llegando fácilmente a 1 millón de filas. A menudo analizo promedios entre ratones, dividiendo mis datos de muchas maneras diferentes, incluso limitando los análisis a una semana particular de pruebas, o tal vez solo a las primeras 10 pruebas de un día determinado o incluso a varios días, y así sucesivamente. Cuando genero cifras, la clave es explorar este vasto conjunto de datos con Graph Builder de manera fluida. A menudo necesito trazar el error estándar de la media en gráficos de barras o líneas, mientras que en la neurociencia del comportamiento, el término de error deseado para N muestras está al nivel del número de organismos/ratones. En conjuntos de datos donde tengo numerosas réplicas o muestras, particularmente si es una medida tomada varias veces dentro de un día o entre días, y quiero trazar promedios de grupo como se describe anteriormente, las barras de error SEM a menudo se subestiman incorrectamente porque N en el generador de gráficos es usando el número total de muestras en la pantalla (por ejemplo, a veces N = 5000 muestras si se agrupan en días cuando en realidad necesito que sean simplemente N = 40 ratones).
¿Cuál es la mejora que le gustaría ver?
Inicié una larga conversación con un miembro del equipo de soporte de JMP por correo electrónico. Finalmente decidimos juntos que la característica que me gustaría sería extremadamente valiosa si se implementara correctamente de forma nativa dentro de Graph Builder y actualmente no es posible sin numerosas soluciones que implican tener que generar muchos resúmenes de tablas adicionales, columnas de datos o scripts que rápidamente se vuelven insostenibles cuando el número de variables aumenta o si las formas en que se agrupan los datos deben seguir cambiando.
A continuación, ilustraré con una serie de capturas de pantalla datos de muestra, el problema y una posible solución.
Primero, aquí hay datos de ejemplo para el peso corporal de 10 ratones tomados cada día durante 10 días, por lo que N = 100 muestras en total.

A continuación, trazaré estos pesos corporales promediados en 10 ratones, divididos por día cuando se colocaron en el Grupo X en Graph Builder.

Puedes apreciar N=10 puntos por nivel diario. Aquí, las barras de error promedio y SEM son correctas y deseadas. Esto rápidamente se vuelve problemático a continuación.
Simplemente eliminando el día del Grupo X, todos los datos se reúnen y se colapsan en días, pero ahora tenemos las 100 muestras mostradas aquí. Cada ratón se muestra aquí 10 veces. Aquí, el promedio está bien, pero la barra de error SEM usa N=100 como término de error, y no n=10 ratones, lo que casi siempre debería ser el caso en la neurociencia del comportamiento. Es un problema simple y común que sería increíblemente útil si JMP construyera una solución nativa dentro del generador de gráficos. Vea a continuación cómo esto se vuelve más complejo y no se puede resolver fácilmente con las soluciones alternativas actuales.

Lo obvio es utilizar la función Resumen de tabla.

A menudo tengo que apoyarme en esto, pero normalmente tengo que hacer cientos de resúmenes de tablas a partir de mi conjunto de datos original cuando tengo variables más complejas. Al explorar mis datos, esto se sale de control muy, muy rápidamente. Y generalmente se combina con una disposición compleja que implica tener que aplicar filtros de datos, hacer resúmenes de resúmenes, etc., etc.
Uno de los miembros de soporte de JMP sugirió agregar nuevas columnas donde calcula el promedio de los 10 días por mouse, y puede ver a continuación que esto funciona, pero es bastante engorroso solo para una sola variable como el peso corporal, y no funcionaría bien. a una tabla que tiene, por ejemplo, otras 100 variables que son mucho más complejas, como medidas de desempeño de tareas conductuales. Solo eso agregaría 8 columnas x 100 variables y se volvería inmanejable. Incluso extraer la fórmula para dichas columnas y reemplazar la variable que utiliza la fórmula no es ideal y es extremadamente manual/laborioso.

Esto es especialmente cierto si quiero subdividir mis datos en varios niveles, especialmente si los niveles están formados por puntos de datos asimétricos. Y especialmente si estoy explorando mis datos en el generador de gráficos y a menudo cambio estos parámetros de agrupación sobre la marcha. Vea abajo.

Aquí hay otro caso de uso en el que también estoy usando filtros de datos locales para subconjuntos de mis datos. Esto se vuelve cada vez más problemático de implementar con scripts o nuevas columnas.

Puede ver que si subconjunto e incluyo solo los días 7 a 10, a la izquierda, cuando divido por día en los niveles del Grupo X, por supuesto muestra n=10 por barra solo para los días seleccionados como se esperaba, pero los datos agrupados a la derecha todavía tiene n=40.
Básicamente, la solución óptima sería implementar una forma de arrastrar y soltar una variable de interés en una nueva zona de colocación en el generador de gráficos. A continuación, describo dos posibles soluciones que estoy imaginando:
A la izquierda anotado en el rojo es un método centrado en la "identificación del mouse" , ya sea como una forma de colocar la ID del mouse en el generador de gráficos y/o como una opción para seleccionar en la opción de intervalo de error/estilo de error donde el objetivo sería reducir los 10 puntos de datos por mouse a un solo punto de datos por mouse de forma nativa. todo dentro del generador de gráficos aquí. Por lo tanto, podemos decirle a Graph Builder al final del día qué variable queremos para determinar el término de error (por ejemplo, mediante valores únicos, promediando los puntos restantes). A la derecha anotado en el verde es un método centrado en el "día" - la variable que no me importa en este ejemplo en particular y que quiero colapsar. Piense en esto como el "opuesto a superposición" - en lugar de dividir por esta variable, quiero colapsar los datos en esta dimensión específica (esencialmente lo mismo que dejar intencionalmente día fuera de la variable de agrupación Resumen de tabla). Tengo la sensación de que el método rojo tiene más sentido, pero es posible que el usuario quiera informar de alguna manera sobre qué variable estoy intentando colapsar explícitamente (por ejemplo, día). De todos modos, ambos lo llevarían al gráfico de barras idealizado con el término de error correcto (n = 10 puntos de datos totales, 1 por mouse). Al explorar datos visualmente en el generador de gráficos, esto podría resolver los ejemplos más complejos que describo anteriormente (por ejemplo, con niveles personalizados, filtros de datos, etc.).

¿Por qué es importante esta idea?
Tener una manera rápida de hacer que las barras de error se ajusten de manera más inteligente usando mi sugerencia haría que la exploración de conjuntos de datos complejos fuera altamente eficiente si se integra directamente en Graph Builder, de forma nativa. Esto corrige múltiples visualizaciones engañosas o estadísticamente incorrectas que a menudo no representan los análisis subyacentes que muchos científicos e investigadores realizan cuando utilizan organismos individuales como término de error supuesto. Esto evita numerosas soluciones que rápidamente se vuelven engorrosas, insostenibles o imposibles de gestionar con conjuntos de datos más grandes o complejos.Este nivel de control en Graph Builder no tendría precedentes y creo que sería una herramienta única e increíblemente poderosa.