¿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.
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)$.
Esta semana he descubierto el PCA robusto. En la frase anterior he conjugado el verbo en cursiva porque lo he pretendido usar con un significado que matiza el habitual: no es que haya tropezado con él fortuitamente, sino que el PCA robusto forma parte de esa inmensa masa de conocimiento estadístico que ignoro pero que, llegado el caso, con un par de clicks, una lectura en diagonal y la descarga del software adecuado, puedo incorporarlo y usarlo a voluntad.
Existe un viejo truco —mas no por ello conocido— para que R vuele. Lo aprendí en una conferencia de uno de los padres de R (aunque ya no recuerdo quién era) en la primera década del siglo. El problema que tenía entre manos era el de ajustar unos cuantos miles de regresiones logísticas. Además de hacer uso de los métodos de paralelización, aún muy rudimentarios en la época, uno de los trucos más efectivos que utilizaba era el de desnudar las funciones.
He sido fan del análisis de los eventos recurrentes desde antes incluso de saber que existía tal cosa formalmente.
Es una extensión del análisis de la supervivencia donde resucitas y vuelves a morirte a lo Sísifo. Es decir, en el análisis de la supervivencia, te mueres y ya; por eso, si quieres extender el análisis de la supervivencia a asuntos tales como compras de clientes es necesario usar el calzador muy heterodoxamente.
Sí, es un ejemplar de mi colección de rarezas estadísticas, técnicas que no entran dentro del currículo estándar pero que pudieran resultar útiles en algún momento, para algún caso particular.
Hoy, perfiles matriciales para series temporales, una técnica que sirve esencialmente, para identificar formas que se repiten en series temporales, como
Entiendo además que, como consecuencia, también para señalar aquellos ciclos en que se produzcan perfiles anómalos, para su evaluación. Pero dejo que consultéis la información en, por ejemplo, aquí y aquí.
Imputación (que es algo en lo que muy a regañadientes estoy trabajando estos días).
Si de verdad tienes que imputar datos en una tabla (y solo en ese caso), solo hay un criterio: construye un modelo para predecir los valores faltantes en función del resto y reemplaza el NA por la su predicción.
El modelo puede ser tan tonto como
lm(my_col ~ 1, na.rm = T)
que resulta en la popular estrategia de reemplazar los NAs por la media del resto de las observaciones.
He intentado replicar los resultados de la entrada de ayer con GAM (vía mgcv) así (véase el enlace anterior para la definición de los datos):
library(mgcv) modelo_gam <- gam( y ~ x + s(id, bs = "re"), data = datos, method = "REML", family = "poisson") Y nada:
Error in gam(y ~ x + s(id, bs = "re"), data = datos, method = "REML", : Model has more coefficients than data
Abundo sobre mi entrada del otro día. Usando números aleatorios hirsutos,
n <- 200 x <- runif(n) plot(cumsum(x - .5), type = "l") produce
mientras que
library(randtoolbox) s <- sobol(n, 1, scrambling = 3) plot(cumsum(s - .5), type = "l") genera
que tiene un cariz totalmente distinto.
Contemplando y comparando
y
se me han venido a la mente los adjetivos hirsuto y pocholo para calificar las respectivas formas de aleatoriedad que representan. La primera es el resultado del habitual
n <- 200 x <- runif(n) y <- runif(n) plot(x, y, pch = 16) mientras que la segunda exige el más sofisticado
library(randtoolbox) s <- sobol(n, 2, scrambling = 3) x <- s[,1] y <- s[,2] plot(x, y, pch = 16) Se ve que Sobol quería rellenar más armoniosamente el espacio.
Una de los proyectos en los que estoy trabajando últimamente está relacionado con un problema de optimización no lineal: tengo un modelo (o una familia de modelos) no lineales con una serie de parámetros, unos datos y se trata de lo que no mercería más explicación: encontrar los que minimizan cierta función de error.
Tengo implementadas dos vías:
La nls, que usa un optimizador numérico genérico para encontrar esos mínimos. (Nótese que uso nls y no nls porque esa función me queda muy corta).
Estoy aquí analizando datos para un cliente interesado en estudiar si como consecuencia de uno de esos impuestos modennos con los que las administraciones nos quieren hacer más sanos y robustos. En concreto, le he echado un vistazo a si el impuesto ha encarecido el precio de los productos gravados (sí) y si ha disminuido su demanda (no) usando CausalImpact y me ha complacido mucho que la salida de summary(model, "report") sea, literalmente, esta:
