En una entrada anterior hablé de la curva de Laffer y de la predisposición a trabajar en los últimos meses del año. En esta quiero abundar sobre el asunto ilustrando cómo evolucionan los tipos marginales del IRPF por mes.
Porque la idea de los impuestos progresivos es que pague más no solo en términos absolutos sino también relativos, quien más gane. Pero la gente no tiene todos sus ingresos el día 31 de diciembre sino que los va acumulando a lo largo del año.
El contexto es, esencialmente, la creación de modelos lineales —no necesariamente los clásicos—, aunque la discusión podría extenderse más allá. Una cosa que nos suelen enseñar los libros es que si en un modelo de la pinta
y ~ t + g (donde t es un tratamiento y g es algún tipo de grupo) nos da por introducir una interacción (en este caso solo cabe t*g) tenemos necesariamente que incluir los efectos individuales t y g so pena de incurrir en una larga retahíla de pecados estadísticos.
I. En primer lugar, no voy a hablar de números aleatorios sino seudoaleatorios. Resumiéndolo todo mucho, un generador de números seudoaleatorios (PRNG en lo que sigue) es una función que a partir de una secuencia fácilmente adivinable (p.e., 0, 1, 2,…) genera otra de números con apariencia aleatoria.
Los números de la secuencia adivinable constituirían los distintos estados del PRNG. En R, Python y otros lenguajes populares, el generador de números aleatorios hace dos cosas: generar un número aleatorio y actualizar el estado.
… muchas cosas serían muy distintas hoy en día. Hoy quiero elaborar sobre su artículo de 1900 X. On the criterion that a given system of deviations from the probable in the case of a correlated system of variables is such that it can be reasonably supposed to have arisen from random sampling famoso por nada menos que introducir el concepto de p-valor y el el uso de la $\chi^2$ para medir la bondad de ajuste.
¿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.
