R

I. Motivación e introducción

Denoising diffusion —DD en lo que sigue— es uno de los principales ingredientes del archipopular stable diffusion. Es un algoritmo que se usa fundamentalmente para generar imágenes y que funciona, a grandes rasgos así:

• Se parte de un catálogo de imágenes, que son vectores en un espacio (de dimensión alta).
• Esos vectores se difuminan utilizando un proceso concreto —piénsese en una especie de movimiento Browniano— hasta que su distribución es aproximadamente una normal (en ese espacio de dimensión elevada).
• A partir de valores aleatorios de esa distribución normal, invirtiendo el proceso de difusión, se obtienen muestras del espacio original (de las fotos).

Subyace a todo este tinglado la conocida como hipótesis de la subvariedad. Todas las fotos son, en el fondo, vectores en $R^N$ donde si las fotos son, digamos, $1000 \times 1000$, $N$ es 3M (número de píxeles por el número de canales). La hipótesis de la subvariedad dice que la distribución de las fotos que reconocemos como tales —piénsese que la mayoría de las fotos de $R^N$ no dejan de ser manchas grises— residen en una subvariedad de dimensión baja incrustada en $R^N$. Generar imágenes equivale entonces a muestrear dicha subvariedad, con el problema de que no sabemos ni qué forma tiene ni dónde está. Lo que proporciona DD es un caminito para llegar a ella desde un punto cualquiera del espacio.

Entrada breve solo para anunciar el curso/libro/manual gratuito y en línea R para visualización de datos de Luz Frías —de quien todo lo que diga será poco—.

(Hubo un tiempo en el que única tecnología disponible para hacer llegar conocimiento a la gente era escribiendo libros. Había libros buenos y libros malos pero todos costaban dinero. Así que algunos escribían reseñas sobre ellos que permitían al potencial lector hacerse una idea de si valía o no la pena hacerse con él. Pero la distribución gratuita de de contenido por internet, debería hacer morir el viejo género del escribir sobre lo que otros han escrito. Basta aquí una recomendación —encarecida— y el enlace para que el interesado lo hojee en menos tiempo que costaría leer lo que sobre él pudiera contarse.)

Entrada breve solo para anunciar el curso/libro/manual gratuito y en línea R para visualización de datos de Luz Frías —de quien todo lo que diga será poco—.

(Hubo un tiempo en el que única tecnología disponible para hacer llegar conocimiento a la gente era escribiendo libros. Había libros buenos y libros malos pero todos costaban dinero. Así que algunos escribían reseñas sobre ellos que permitían al potencial lector hacerse una idea de si valía o no la pena hacerse con él. Pero la distribución gratuita de de contenido por internet, debería hacer morir el viejo género del escribir sobre lo que otros han escrito. Basta aquí una recomendación —encarecida— y el enlace para que el interesado lo hojee en menos tiempo que costaría leer lo que sobre él pudiera contarse.)

[Antes de nada, un aviso: léase la fecha de publicación de esta entrada. Es fácil estés visitándola en algún momento futuro en el que ya esté más que caduca.]

Soy muy partidario de las ETL en memoria. Cada vez es menos necesario utilizar herramientas específicas (SQL, servidores especializados, Spark, etc.) para preprocesar datos. Casi todo cabe ya en memoria y existen herramientas (hoy me concentraré en R y Python, que son las que conozco) que permiten realizar manipulaciones que hace 20 años habrían resultado impensables.

En esta entrada voy a comparar los sistemas de coordenadas WSG84, ETRS89, ED50 y el vetustísimo Madrid 1870. Además, lo voy a hacer mal y luego voy a explicar no solo por qué sino por qué no es culpa mía.

Primero, las coordenadas de Sol (el Kilómetro 0, para ser más precisos) en WGS84 (EPSG:4326):

library(sf)
options(digits = 10)
sol_wsg84 <- st_sfc(st_point(
    c(40.416634493768065, -3.703811417868093)),
    crs = 4326)
st_coordinates(sol_wsg84)
#             X            Y
# 1 40.41663449 -3.703811418

Ahora, en ETRS89 (EPSG:4258):

Esta es la tercera entrada de la serie sobre diagramas causales hiperbásicos, que, como la segunda, no se entenderá sin —y remito a— la primera que define el contexto, objetivo e hipótesis subyacentes de la serie completa. Además, sería conveniente haber leído la segunda.

Esta vez, el diagrama causal es una pequeña modificación del de la anterior:

Ahora, la variable $X$ influye sobre $Y$ por dos vías: directamente y a través de $Z$. Variables como $Z$, conocidas como mediadores son muy habituales. Uno podría pensar que, realmente, ninguna $X$ actúa directamente sobre ninguna $Y$ sino a través de una serie de mecanismos que involucran a variables intermedias $Z_1, \dots, Z_n$ que constituyen una cadena causal. Puede incluso que se desencadenen varias de estas cadenas causales que transmitan a $Y$ la potencia de $X$. Que hablemos de la influencia causal de $X$ sobre $Y$ es casi siempre una hipersimplificación de la realidad.

Esta es la segunda entrada de la serie sobre diagramas causales hiperbásicos. No se entenderá sin —y remito a— la entrada anterior que define el contexto, objetivo e hipótesis subyacentes de la serie completa.

El diagrama causal objeto de esta entrada es apenas una arista más complejo que el de la anterior:

Ahora la variable $Z$ afecta tanto a $Y$ (como en la entrada anterior) como a $X$ (esta es la novedad). Es una situación muy común en el análisis de datos. Algunos ejemplos:

Comienzo hoy una serie de cuatro entradas (¡creo!) sobre diagramas causales supersimples que involucran a tres variables aleatorias: $X$, $Y$ y $Z$. En todos los casos, estaré argumentaré alrededor de en las regresiones lineales Y ~ X e Y ~ X + Z porque nos permiten leer, interpretar y comparar rápida y familiarmente los resultados obtenidos. En particular, me interesará la estimación del efecto (causal, si se quiere) de $X$ sobre $Y$, identificable a través del coeficiente de $X$ en las regresiones. No obstante, quiero dejar claro que:

Voy a comenzar con una simulación inofensiva,

set.seed(1)
n <- 10000
sigma <- .1
x <- runif(n)
# coeficientes:
indep <- -1
b_0 <- .5
# variable objetivo:
error <- rnorm(n, 0, sigma)
y_0 <- indep + x * b_0 + error
# modelo:
modelo_0 <- lm(y_0 ~ x)
summary(modelo_0)

que da como resultado

Call:
lm(formula = y_0 ~ x)

Residuals:
     Min       1Q   Median       3Q      Max
-0.42844 -0.06697 -0.00133  0.06640  0.37449

Coefficients:
             Estimate Std. Error t value Pr(>|t|)
(Intercept) -1.001951   0.001967  -509.5   <2e-16 ***
x            0.500706   0.003398   147.3   <2e-16 ***

Residual standard error: 0.0989 on 9998 degrees of freedom
Multiple R-squared:  0.6847,	Adjusted R-squared:  0.6846
F-statistic: 2.171e+04 on 1 and 9998 DF,  p-value: < 2.2e-16

Me he limitado a construir el típico conjunto de datos que cumple las condiciones de libro para poder aplicar la regresión lineal y he reconstruido los parámetros originales a través del resultado de esta: el término independiente (-1), la pendiente (.5), la desviación estándar del error (.1), etc.

El otro día publiqué un minihilo en Twitter que terminaba con una encuesta. Proponía el siguiente problema:

1. Quiero, abusando del lenguaje, estimar el efecto de $x$ sobre $y$ usando el modelo lineal clásico $y = a_0 + a_1 x + \epsilon_1$.
2. Pero no puedo medir $x$ con precisión. Solo tengo una medida ruidosa/aproximada de $x$, $z = x + \eta$, donde $\eta$ es normal, independiente de $\epsilon_1$, etc.
3. Uso el modelo $y = b_0 + b_1 z + \epsilon_2$.

La pregunta que planteé consistía en elegir entre las siguientes tres opciones:

Perdóneseme haber usado lenguaje causal en el título de esta entrada siendo así que no encontrará el lector indicios sólidos de respuesta en lo que sigue. Y, sobre todo, que no se confunda y me tome por un sociólogo a la violeta o un economista posmo: no, soy matemático.

Quiero simplemente hacer constar un pequeño ejercicio de análisis espacial usando los paquetes sf y terra de R motivado, eso sí, por una pregunta que se planteó en cierto foro a raíz de esta captura de la Wikipedia:

[Menos mal que se me ha ocurrido buscar en mi propio blog sobre el asunto y descubrir —no lo recordaba— que ya había tratado el asunto previamente en entradas como esta, esta o esta.]

El problema de la propagación de errores lo cuentan muy bien Iñaki Úcar y sus coautores aquí. Por resumirlo: tienes una cantidad, $latex X$ conocida solo aproximadamente —en concreto, con cierto error— e interesa conocer y acotar el error de una expresión $latex f(X)$.

• Larguísimo, arriba, significa algo así como 10 o 20 años. Vamos, como cuando comencé con R allá por el 2001.
• R es, reconozcámoslo, un carajal. Pocas cosas mejores que esta para convencerse.
• No dejo de pensar en aquello que me dijo un profesor en 2001: que R no podría desplazar a SAS porque no tenía soporte modelos mixtos. Yo no sabía qué eran los modelos mixtos en esa época pero, desde entonces, vine a entender y considerar que “tener soporte para modelos mixtos” venía a ser como aquello que convertía a un lenguaje para el análisis de datos en una alternativa viable y seria a lo existente. Y mirad esto.
• Obviamente, lo de los modelos mixtos no es más que una metáfora. Realmente significa algo así como “el sistema X tiene muchas cosas y su alternativa, Y, es un mero juguete”. Pero no hay nada que impida que Y comience a implementar todo aquello que le falta. Además, mucho más rápida y eficientemente. P.e., ¿cuánto tardó R en dotarse de su gramática de los gráficos? Pues bien, Juilia ya los tiene. (¿Cómo se dice leapfrog en español?)
• Dicho de otra manera, R ha sido el estado del arte en computación estadística en los últimos años. Ha avanzado por prueba y error. Pero ahora, cualquier rival ya sabe qué tiene que hacer exactamente para llegar a donde está R.
• Julia corre sobre LLVM. Es decir, que se beneficia automáticamente de cualquier mejora realizada sobre la máquina virtual (si es que se me permite llamar así a LLVM).
• Esta semana he estado programando en C unas rutinas que tienen que ser llamadas desde R. Pero, ¿no sería el mundo más hermoso no tener que cambiar de lenguaje para tener rendimiento de C?
• Arriba comparo R y Julia como extremos de un arco (en el que a la izquierda de R quedan aún irrelevancias como SAS o SPSS). Python ocupa una posición intermedia entre ambos. Desde un punto de vista meramente técnico, si alguna dimensión es Python mejor que R, Julia es todavía mejor que Python. Salvo, de nuevo, la cantidad de flecos y cascabeles de los que ya dispone Python y que todavía no están presentes en Julia. Pero, como se ha dicho arriba, desde la perspectiva del larguísimo plazo, es una objeción irrelevante que apunta a un estado transitorio de las cosas.

Y supongo que podría seguir.