R

El 1 de marzo de 2011 escribí esto anunciando un nuevo IDE multiplataforma (¡qué falta hacía!) para R. Trece años más tarde, la misma empresa nos provee de otro bien público, Positron.

Aún no he podido instalar la beta pública en mi Archlinux por un conflicto con VS Code —sí, Positron parece ser un VS Code tuneado—, pero prometo una captura de pantalla una vez se arregle el asunto.

En tanto, ¿qué espero de Positron? No otra cosa que la facilidad que ofrece RStudio para el análisis informal e interactivo de datos. Ni los IDEs habituales ni los notebooks ofrecen un mecanismo ágil para la exploración: ambos están enfocados en ofrecer un producto final cerrado: un software que funcione en el primer caso, un documento en el segundo. Si Positron nos permite hacer con Python lo que RStudio con R —y lo que he visto por ahí apunta en esa dirección: Positron parece una reconstrucción de RStudio sobre una plataforma distinta—, el mundo será un poquito más bello.

Si leéis algo y tropezáis con un gráfico como

es que lo que lo rodea vale la pena. En este caso, lo que lo rodea es este texto que algún LLM me ha resumido así:

• El texto analiza la importancia de evaluar el valor comercial de los modelos predictivos y las limitaciones de las métricas de evaluación tradicionales como la curva ROC.
• Presenta cuatro gráficos de evaluación (ganancias acumuladas, elevación acumulada, respuesta y respuesta acumulada) y tres gráficos financieros (costos e ingresos, ganancias y retorno de la inversión) que pueden ayudar a explicar el valor comercial de un modelo.
• El texto proporciona ejemplos de cómo utilizar el paquete R modelplotr para crear estos gráficos.

Motivado por esta entrada construí

usando

muns <- st_read("data/CifraPob2023.shp")
peninsula <- muns[muns$ccaa != 'Canarias',]
plot(peninsula["pob_23"])
peninsula <- st_transform(peninsula, 25830)


peninsula_dorling <- cartogram_dorling(
  x = peninsula,
  weight = "pob_23",
  k = 0.2,
  itermax = 100)

plot(peninsula_dorling["pob_23"])

sobre unos datos que ya no recuerdo de dónde bajé. La única línea no autoexplicativa del código es

peninsula <- st_transform(peninsula, 25830)

que transforma las coordenadas originales de los datos en coordenadas proyectadas (o, más bien, las coordenadas proyectadas que rigen en la zona peninsular). El 25830 en cuestión me lo chivó un LLM.

El otro día visité el museo de ciencias naturales de Madrid. Constaté que aún no he perdido mi extraño interés por esas pocas especies que dizque convivieron con los dinosaurios. MicrodatosEs es casi una criatura de esa época. No tanto, pero casi.

Me sorprende, de hecho, que tuviese algún usuario; que este, además, encontrase un bug y que, finalmente, diese noticia de él. La versión que lo soluciona es la que ahora figura y ocupa espacio en CRAN.

A la vista de los mapas

pocos habrán que no prefieran el de la derecha. Los mapas están extraídos de la entrada Improve your maps in one line of code changing map projections, cuyo título ha sido elegido muy acertadamente en tanto que los mapas han sido construidos usando

gd_n2_main_laea <- gd_n2_main %>%
    st_transform(crs = 3035)

a <- gd_n2_main %>%
    ggplot() +
    geom_sf(fill = "#F48FB1", color = NA)+
    geom_sf(data = bord, color = "#C2185B", size = .5)+
    coord_sf(crs = 3857)

b <- gd_n2_main_laea %>%
    ggplot() +
    geom_sf(fill = "#DCE775", color = NA)+
    geom_sf(data = bord, color = "#AFB42B", size = .5)

library(patchwork)

a + b + plot_annotation(tag_levels = "A")

y, por lo tanto, solo difieren en la línea

¿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.—, los ficheros se intercambiaban en disquette (¿se escribía así? ya no recuerdo bien) y casi todo el mundo usaba Windows. Era lo que había y hay que entenderlo; de otra manera, no se comprende casi ninguna de las decisiones de diseño del formato. Que, por otra parte, parece basado en la siguiente pareja de principios funcionales:

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. Aun asi, el libro sigue siendo fundamentalente agnóstico con respecto a ese dialecto.
• He incorporado algunas mejoras sugeridas por algún amable lector en el pasado.
• He comenzado —solo comenzado— a preparar soluciones para los casi 200 ejercicios planteados en el libro.

El enlace, ahora sí, aquí.

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.)

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.

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.