R

Mi paquete MicroDatosEs ya forma parte de rOpenSpain. Sin embargo, está falto de ciertas mejoras a las que aspiran los paquetes que forman parte de dicho repositorio.

Una de ellas es la de migrar la documentación del paquete a roxigen2. Lo podría hacer yo, pero es muy aburrido. Sin embargo, entiendo que puede ser entretenido (además de sencillo) para alguien que:

• No sepa de qué va eso de roxigen2 pero me tome la palabra en eso de que es importante.
• No sepa mucho de cómo va git, GitHub, etc. pero me tome la palabra en eso de que es importante.
• Quiera disfrutar de una oportunidad real y significativa de aprender practicando.
• Quiera aparecer en la lista de contribuyentes a dicho paquete.

Así que si alguien está dispuesto a pasar unas cuantas horas aprendiendo, que avise y le cuento cómo proceder. Eso sí, por simplificar, va a ser uno y no más.

Uno de los modelos más útiles potencialmente y que menos atención recibe es el de los modelos de conteos autoexcitados. Es decir, aquellos en los que un evento incrementa durante cierto tiempo la probabilidad de que ocurra otro. Creedme, ocurre así muy a menudo en muchas aplicaciones.

Por eso se pone uno muy contento cuando descubre paquetes de R como este.

Pero el hecho de que unos académicos lo hayan creado y puesto ahí por mor de las neonormas (administrativas, morales o de señalamiento) de reproducibilidad, no significa que lo hayan desarrollado para los usuarios finales. O pensando en ellos.

De vez en cuando pruebo paquetes promisorios. No es infrecuente que cosas que he intentado hace años, algún ejemplo más o menos sencillo que he publicado aquí, acabe convirtiéndose en la piedra angular de algo facturable. Incluso de algo facturable por mí.

geozoning podía haber sido uno de esos. La promesa del paquete es que puede ayudarte a segmentar regiones del espacio de acuerdo con alguna variable, una especie de clústering para información de tipo espacial.

Pues sí, acabo de enterarme de que se organiza la tal cosa. Toda la información, escasa de momento, aquí.

Cayeron en mis manos unos datos que no puedo publicar, pero me atreveré a presentar algunos resultados anonimizados. Se trata de una tabla de puntuaciones numéricas (18 en total, cada una en su columna) proporcionadas por unos cuantos centenares de sujetos (filas). Era de interés un estudio cualitativo de las posibles relaciones de dependencia entre las variables.

La manera más rápida de comenzar, un heatmap(cor(dat)), para obtener

Y luego PCA y todas esas cosas.

Con motivo de fin de año se ha hablado de fallecidos en accidentes de tráfico como por ejemplo en El Mundo o en El País. Y sí, parece que el número observado de muertos ha aumentado.

Lo cual es mucho menos relevante de lo que se da a entender. Si tiras una moneda al aire 100 veces y sacas 48 caras y luego repites el experimento, podrías sacar 53 (y habría aumentado el número observado de caras) o 45 (y habría disminuido). Lo relevante es si ha cambiado o no la probabilidad de cara de la moneda. De lo cual, y volviendo al caso de la siniestralidad, ya me ocupé en su día.

Imagínate que quieres estabilizar la varianza (¡para qué!) de una distribución de Poisson. Los libros viejunos te dirán que saques la raíz cuadrada de tus valores.

Si en lugar de mirar en libros viejunos prestas atención a tus propios ojos, harás algo parecido a:

lambdas <- -10:10
lambdas <- 2^lambdas
res <- sapply(lambdas,
    function(lambda) sd(sqrt(rpois(1e5, lambda))))

para obtener

y averiguar dónde funciona y dónde no.

Si usas la transformación $latex f(x) = x^{2/3}$, como recomiendan en cierto artículo que no viene a cuento identificar, harás

Primero, una simulación:

n <- 100
delta <- 0.2
n.iter <- 10000

p_valores <- function(n, delta){
  tmp <- replicate(n.iter, {
    x <- rnorm(n)
    y <- rnorm(n, mean = delta)
    t.test(x, y)$p.value
  })

  res <- tmp[tmp < 0.05]

  hist(res, freq = FALSE, xlab = "p value", ylab = "", col = "gray", main = "histograma de p-valores publicables")

  res
}

null_effect_p_values <- p_valores(n, 0)
some_effect_p_values <- p_valores(n, delta)

Lo que simula son n.iter experimentos en los que se comparan n valores N(0,1) con otros n valores N(delta, 1) y se extrae el correspondiente p-valor. Luego se grafican los publicables (<0.05).

El otro tropezamos con el siguiente artefacto:

a <- list(aa = 12, bb = 14)
is.null(a$a)
#[1] FALSE
a$a
#[1] 12

No es un bug de R, por que la documentación reza:

x$name is equivalent to x[[“name”, exact = FALSE]]

Y se pueden constrastar:

a[["a", exact = FALSE]]
a[["a", exact = TRUE]]

Comentarios:

• Odio muchísimo los bugs que no son bugs porque están documentados en el la nota ‡2.a.(c), párrafo §23.3 de la sección 14 de un manual oscuro.
• Odio mucho al os gilipollas que se complacen en mandarte a leer manuales.
• Odio mucho las violaciones del principio de mínima sorpresa.
• Soy consciente de que R es, fundamentalmente, una plataforma de análisis interactivo y no (o solo subsidiariamente) un lenguaje de programación.
• Soy consciente de que muchos de los defaults de R se decidieron antes de que se popularizasen los completadores de comandos.

Cuando tienes una serie temporal al uso (sin entrar a definir qué es eso), uno puede aplicar descomposiciones tmabién al uso, como stl, para extraer tendencia y estacionalidad, de la forma

como en esta entrada previa.

Lluvia.

La serie de la lluvia es otra cosa. Uno ve si llueve o no llueve (típicamente no). Lo que uno no ve es la probabilidad, que varía a lo largo del año, de que llueva. Pasa lo mismo con monedas (uno ve caras o cruces, no la probabilidad de cara), clientes que compran (uno ve si compra o no, no la probabilidad de compra), etc. Pero la probabilidad existe y en estimarla consiste frecuentemente el trabajo de algunos.