Quién me conoce sabe que siento debilidad por el análisis de datos categóricos, en particular por técnicas como el análisis de correspondencias simple o múltiple o por las cosas más modernas que hay. No en vano se me dió especialmente bien en la universidad, en parte debido a que por fin me centré después de unos años locos, y en parte debido a algún buen profesor. El caso es que en el curro utilizamos este tipo de técnicas para encontrar relaciones entre variables categóricas que quizá hayan pasado desapercibidas en un primer análisis.
Recuerdo siendo yo más bisoño cuando escuché a los marketinianos hablar del A/B testing para acá , A/B testing para allá. En mi ingenuidad pensaba que era alguna clase de rito que sólo ellos conocían, y encima lo veía como requisito en las ofertas de empleo que miraba.
Mi decepción fue mayúscula cuando me enteré que esto del A/B testing no es más que un nombre marketiniano para hacer un contraste de proporciones o contrastes de medias, vamos, un prop.
Nota: He cambiado la parte final para que hiciera lo mismo que el código de python, gracias a mi tocayo José Luis Hidalgo
El otro día por linkedin, mi jefe compartió el siguiente artículo recomendable por otro lado. El repo con el código y datos está aquí.
En el artículo hacen referencia a que una forma de ver el CATE (Conditional Average Treatmen Effect) cuando hay variables categóricas puede ser construirse los términos de interacción de alto orden entre las variables categóricas y calcular la diferencia entre la media de la variable de interés antes del tratamiento y después del tratamiento, en cada una de las variables de interacción consideradas.
Siguiendo con el tema de los dos ejes de ordenadas, a mi no me gustan especialmente este tipo de gráficos, pero puedo entender que se use y, cómo dice mi amigo Raúl Vaquerizo, lo importante es que se entienda.
Veamos un ejemplo que nos comentó Jesús Lagos dónde se suele aplicar este tipo de gráficos, se trata de los climogramas, dónde se presentan en el eje X los meses del año y en los dos ejes de ordenadas la precipitación y la temperatura.
Anoche me iba a ir a la cama tras escuchar un podcast, pero al final estuve entretenido debatiendo con Raúl Vaquerizo, Alberto González Almuiña y Jesús Lagos , sobre los gráficos con dos ejes de ordenadas. Aquí os dejo el tweet que puso Raúl.
Pues yendo al post que puso Raúl construía el siguiente gráfico.
library(tidyverse) library(magrittr) library(ggplot2) url='http://www.businessandeconomics.mq.edu.au/our_departments/Applied_Finance_and_Actuarial_Studies/acst_docs/glms_for_insurance_data/data/claimslong.csv' df <- read.csv(url) resumen <- df %>% group_by(period) %>% summarise(pct_exposicion = n(), frecuencia = sum(claim)/n()) g2 <- ggplot(resumen,aes(x = period)) + geom_col(aes(y = pct_exposicion), fill="yellow",alpha=0.
Introducción ¿Qué os parecería tener un modelo guardado y un binario en linux que tomando como parámetros el modelo y el dataset a predecir guardara las predicciones en un csv?
Y todo eso que funcione en cualquier Linux, de forma que puedas copiar esa aplicación de un Ubuntu a un EC2 con amazon linux (un centos) y que funcione igual sin tener que tener Julia instalado en el EC2.
A pesar del título, no voy a hablar sobre la excelente canción de los Suaves, sino del lenguaje de programación Julia. Ya en otra entrada del blog de hace un par de años comparé glmer con INLA y la librería MixedModels. Por aquel entonces la versión de Julia era la 1.0.3, ya va por la 1.6.2. Debido a reciente entrada de Carlos dónde apostaba por Julia para el larguísimo plazo, he decidido echarle un vistazo un poco más en profundidad.
Voy a empezar este post con un par de citas.
El análisis de datos es básicamente encontrar la matriz correcta a diagonalizar.
Quien renuncia a la estructura, deja dinero encima de la mesa.
La primera no recuerdo dónde la leí, pero es de la escuela francesa de estadística, la segunda es del blog hermano datanalytics.
Y bueno, ambas tienen parte de razón.
Y seguimos dando vueltas a los datos de post anteriores. Siempre hay quien dice que el bayesiano no sirve para big data y qué se acaba el universo antes de que termine de ajustar tu modelo (esto último creo que se lo he dicho yo alguna vez a Carlos).
Pero ya hemos visto en los dos post anteriores que podemos condensar los datos en menos filas sin perder información, así que , ¿por qué no utilizar un modelo bayesiano?
Bueno, pues voy a ampliar el ejemplo del último día, como es viernes, estoy cansado y me iré a tomar una birra pronto, intentaré ser breve.
Levantamos una sesión de spark y leemos los mismos datos del otro día. Ya de paso voy a probar el operador pipe nativo en R base |>. Si tienes la nueva versión de R instalada y la versión de Rstudio preview, en global options puedes poner para que al hacer Ctrl + Shift +M aparezca el nuevo operador o el antiguo.