¿Dejar morir pxR? He ahí la cuestión.
pxR es un paquete de R en CRAN en el que figuro como mantenedor. Es un subproducto de mis antiguas inclinaciones hacia el procomún. Me fue útil para alguna que otra actividad inútil.
El paquete sirve para importar a R datos en el formato Px. Este formato fue concebido en una época en la que aún no existían cosas mejores y mejor pensadas —XML, JSON, datos tidy, etc.
Este soy yo hoy mismo:
Este es mi script:
carlos@tiramisu:~$ wordle señor Intento 1 -> seria Quedan 2 opciones. Las más populares son: señor : 228.79 segur : 0.23 Intento 2 -> señor Solución en 2 intentos: señor Mi pequeño script tiende a ganarme. Lo cual me satisface enormemente.
En caso de que a alguien le interese, puede bajárselo de aquí. Existen dos versiones que implementan el mismo algoritmo, una en R y otra en Python.
Acabo de subir —que suena menos pomposo que publicar— la primera versión de la segunda edición de mi libro de R. Los cambios con respecto a la primera son:
He migrado a Quarto. Algunas correcciones, sobre todo en bloques de código que dejaron de funcionar por hacer llamadas a servicios que han desaparecido (o, como Google Maps, han cambiado el método de suscripción). Algún material nuevo, sobre todo relacionado con dplyr y el tidyverse.
Después de publicar Una regresión de Poisson casi trivial con numpyro me riñeron por usar la identidad como función de enlace en la regresión de Poisson. Es decir, por especificarlo como
$$\lambda_t = a + b t$$
en lugar del estándar
$$\lambda_t = \exp(a + b t).$$
Hay varias cosas bastante bien conocidas y una que lo es bastante menos —y que resulta mucho más paradójica— que decir al respecto.
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).
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.
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.
[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.
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$.
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).
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.
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.
