En la entrada de api y docker con R parte I veíamos que es muy fácil construir una api y dockerizarla para tener un modelo bayesiano en producción. Pero hay un pequeño incoveniente, el docker que hemos creado se base en rocker/verse que se basan en ubuntu. Y ubuntu ocupa mucho. Pero gracias a gente como Gabor Csardi (autor entre otras librerías de igraph), tenemos r-hub/minimal, que permiten tener una imagen de docker con R basadas en alpine, de hecho una imagen de docker con R y dplyr son unos 50 mb.
Todo el mundo anda haciendo apis para poner modelos en producción, y oye, está bien. Si además lo complementas con dockerizarlo para tener un entorno controlado y que te valga para ponerlo en cualquier sitio dónde esté docker instalado pues mejor.
Aquí voy a contar un ejemplo de como se puede hacer con R usando plumber y docker, en siguentes post contaré como hacerlo con vetiver que es una librería que está para R y Python que tiene algún extra, como versionado de modelos y demás.
No, este post no va sobre la canción de Medina Azahara sino de comparar un par de librerías para lectura y procesamiento de datos. A saber, polars escrita en Rust y con api en python versus vroom en combinación con librerías como data.table o collapse en R. Estas últimas usan por debajo C++, así que tanto por el lado de python como por el de R el principal mérito se debe a usar Rust y C++.
Allá por el año 1997 más o menos andaba yo estudiando Investigación Operativa en la Universidad de Granada. Recuerdo aprender el archiconocido algoritmo del simplex y algo también sobre programación entera (dónde el dominio de las variables está en \(\mathcal{Z}\)). No se me daba muy bien al principio, pero si recuerdo que luego me acabó gustando y el día que encuentre mis apuntes os pondré una demostración que desarrollé para un teorema que tenía algo que ver con la relación entre espacio primal y el dual.
Continuando con la serie sobre cosas de inferencia causal y full luxury bayes, antes de que empiece mi amigo Carlos Gil, y dónde seguramente se aprenderá más.
Este ejemplo viene motivado precisamente por una charla que tuve el otro día con él.
Sea el siguiente diagrama causal
library(tidyverse) library(dagitty) library(ggdag) g <- dagitty("dag{ x -> y ; z -> y ; x -> z }") ggdag(g) Se tiene que z es un mediador entre x e y, y la teoría nos dice que si quiero obtener el efecto directo de x sobre y he de condicionar por z , y efectivamente, así nos lo dice el backdoor criterio.
Ando viendo los vídeos de Richard McElreath , Statistical Rethinking 2022 y ciertamente me están gustando mucho. En la segunda edición de su libro hace hincapié en temas de inferencia causal. Cuenta bastante bien todo el tema de los “confounders”, “forks”, “colliders” y demás. Además lo hace simulando datos, por lo que entiende todo de forma muy sencilla. Un par de conceptos que me han llamado la atención son por ejemplo cuando dice que condicionar por una variable no significa lo mismo en un modelo de regresión al uso que en uno bayesiano, en el segundo caso significa incluir esa variable en la distribución conjunta.
Hace un par de días un amigo mío me preguntaba por temas de que quería paralelizar un proceso con R, y no acababa de ver claro cómo. A falta de que mande un ejemplo creí entender que tiene un dataframe dónde tiene un proceso que encuentra para cada fila un conjunto de n filas parecidas y sobre ese conjunto de n filas hace cosas, como estimar algo y tal.
Leo por ahí estimaciones de que hay en España más de 1 millón de contagiados y la verdad es que no tengo ni idea. Pero no se me ocurre ir poniendo ese dato por ahí como verdad absoluta, como hacen algunos .
Hagamos un ejercicio simple y muy burdo, lo reconozco. Supongamos que el número de fallecidos por coronavirus está bien recogido, lo miro en mi dashboard que para eso lo hice y me dice que hoy 29 de Marzo hay un total acumulado de 6528 fallecidos.
En estos tiempos tan asépticos ya no estamos acostumbrados (en algunos países), a tratar con agentes patógenos altamente contagiosos como el que llena los titulares de periódicos y televisiones estos días.
Sin más, vamos a comparar los datos de España e Italia, plagiando con total descaro a mi amigo Carlos Gil que puso este post de ayer y en este de hoy.
Ay, la nube.. que bien suena ¿verdad? Si, hasta que te toca pelearte con amazonlinux y versiones viejunas de R. Total, que me ha tocado lidiar un poco con la versión de R 3.4.1 de hace ya 3 años y tener que compilar en mi máquina un montón de librerías para amazon linux (que viene siendo un centos 7 modificado por aws)
Así que lo primero es montarse un Dockerfile dónde id diciendo qué librerías de sistemas hay que añadir, y alguna ñapa por problemas con el compilador de C.
Volviendo al ejemplo de lo de las proporciones pequeñas, se trataba básicamente de que se tenía una población con una prevalencia de cierto evento del 4 x 1000 más o menos y en post anteriores veíamos cómo calcular tamaños de muestra y tal para ver cómo detectar un incremento de un 15% en esa proporción.
Ahora vamos a suponer que tenemos una población de 1.5 millones, pero que hay 5 grupos diferenciados, con prevalencias del 6, 5, 4, 3 y 2 por mil respectivamente y todos del mismo tamaño.
Quién nos los iba a decir, allá por 2009 cuándo recién creada la lista de correo r-help-es nos llegó el mensaje de que iban a celebrarse las primeras jornadas.Creo que soy, salvo que me corrija Emilio o Carlos, el que a más jornadas ha ido (sólo falté a las míticas de Mieres), jejejeje.
Hoy en día hay muchos eventos relacionados con software libre, analítica, big data, machine learning etcétera. Sin quitar méritos a ninguno de ellos, en mi humilde (y sesgada) opinión las jornadas de R-Hispano son uno de los mejores eventos.
Pues eso, hoy en el trabajo alguien (a quien respeto) me ha hablado de la existencia de Rstudio Cloud, https://rstudio.cloud/ , dónde te logas con tu usuario de Google y ya tienes un rstudio andando. Parece una alternativa interesante a la hora de dar clase y similar, además, por defecto levanta una instancia con 30 gb de RAM y un procesador Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz con 16 hilos de ejecución (puedes comprobarlo con parallel::detectCores() )
Voy a comentar por encima lo que se viene llamando “codificación por impacto”, la idea es codificar una variable categórica predictora usando la información del “target”, evidentemente este tipo de codificación sólo sirve cuando tenemos un modelo en mente y dicen que es útil si tenemos variables categóricas con alta cardinalidad.
La idea es muy sencilla, para cada nivel de la variable categórica le asignamos su media de target, por ejemplo, (o la media(u otra medida) menos la media general)
Hablábamos el otro día mi amigo Carlos y yo sobre los modelos mixtos y el uso de lme4, Stan o INLA. Total, que el problema es que queríamos un atajo que permitiera tener una estimación de los efectos aleatorios en un tiempo menor que lo que queda hasta el fin del universo.
Pues nada, investigando vi que existía una librería en Julia llamada MixedModels y que es del autor de lme4 así que me puse a probar a ver si es verdad el lema de Julia, “tan rápido como C, tan fácil como Python”.
Voy a hacer una serie de entradas sobre codificación de variables categóricas, mi idea es pasar desde la codificación parcial (OneHot Encoders para los modernos), hasta utilizar embeddings. Vamos al lío.
Tradicionalmente, si tenemos una variable categórica con 5 niveles se codifica en tantas variables cero uno como niveles menos uno, puesto que uno de los niveles se toma como referencia y se codifica con todo 0’s en las varaibles indicadoras.
La verdad es que no sé como traducir el término “lookup table”, en fin, vamos al grano.
Supongamos que tengo un factor con 3 niveles o un vector de caracteres con 3 letras únicas y 20 valores.
set.seed(43) vector_largo <- sample(c("a","b","c"), size = 20, replace = TRUE) vector_largo ## [1] "b" "c" "a" "c" "a" "b" "c" "b" "a" "c" "b" "a" "b" "a" "b" "c" "a" ## [18] "a" "a" "a" Y que en otro sitio tengo un vector “con nombres” dónde tengo el valor que asigno a “a”, “b” y “c”
Un amigo mío suele comentar que si no tienes en cuenta la estructura, palmas pasta. Así que hoy estoy leyendo capítulos sueltos de Doing Bayesian Data Analysis.
El libro está bastante bien y me encanta la foto de portada, lo único que está más enfocado a usar JAGS y de Stan no cuenta mucho, pero para eso ya está la completa documentación de Stan.
Sigo con la lectura, buen domingo.
Iba a escribir una cosa chula que hiciera honor al nombre del blog, algo sobre muestreo, postestratificación y demás, pero he llegado a casa tarde y no tengo ni tiempo ni ganas.
Así que voy a poner una serie de librerías que tengo pendiente de probar y que creo reducirían la brecha idiomática entre los científicos de datos, los ingenieros y los arquitectos de datos y big data (si es que en tu organización tienes la suerte de que exista este perfil)
Vivimos en la era del big data según dicen por esos lares, también tengo algún amigo que dice que el big data son los padres, no le falta razón. La mayoría de las cosas que hacemos se pueden hacer sin big data, porque en primer lugar ni en el 95 % de las veces se requiere y porque en el 5% restante podríamos hacer muestreo. Si no hay señal en 20.