Programación

El “bee-bot” es un juego infantil educativo no particularmente barato. Así que he construido una versión web de la cosa en poco rato. En particular, le he dicho a Claude:

I want to create a webpage to play a version of the bee-bot game for children. In the main canvas there is a grid. In two random squares of the grid, there are a bee and a flower. The interface are four buttons with numbers 1-4, four arrows and a go button. The child needs to type the sequence of numbers and arrows and when the go button is pressed, the bee will move. Say, if the sequence is 2, up, 4, right, 2, the bee will move two squares, then turn up, advance 4 squares, turn right, and move two squares.

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.

Mnemo es una pequeña aplicación que he construido para ayudarme a recordar esas cosas que me consta que se me van a olvidar: palabras, conceptos simples, nombres de personas, etc. Externamente se ve como un canal (privado) de Telegram en el que un par de veces al día me aparecen notificaciones con un resumen de la cosa.

Internamente, es la combinación de tres cosas:

• Una base de datos en Notion.
• Un bot de Telegram.
• Un workflow de n8n que corre en mi servidor local y que orquesta todo el proceso.

La base de datos la actualizo manualmente. Cada vez que tropiezo con algo que merece la pena ser recordado, añado un registro con información básica: un rótulo, una breve descripción, un enlace para indagar más.

I. El problema original

• Tienes dos cuentas en Twitter, llámense @trabajo y @personal.
• Tienes una única cuenta de desarrollador en Twitter. Supongamos que está vinculada al usuario @trabajo.
• Quieres usarla para tuitear también en nombre de @personal.

Lo suyo sería disponer de dos cuentas de desarollador, una para cada usuario. Sin embargo, Twitter parece estar dando acceso a tu plataforma de desarrollador con cuentagotas y ni siquiera está claro si conceden más de una cuenta a una misma persona que maneje varios usuarios.

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. Las instrucciones de uso están en el repo.

SE significa arriba_squared errors_, pero lo que aplica a cualquier otro tipo de error, incluso los que son más apropiados que los cuadráticos. El problema de los SE es que se tienden a considerar iguales y por eso se los promedia en engendros como el RMSE y similares. Pero incluso entre los SE hay jerarquías, como evidencia la siguiente historia.

Con lo del covid se pusieron en marcha muchas iniciativas. Una de ellas fue la del COVID-19 Forecast Hub. En ese hub se consolidaron los resultados de muchos modelos relacionados con el covid (relacionados con casos, hospitalizaciones y defunciones) desarrollados por la créme de la créme: MIT, Columbia, Harvard, Google, etc. Todos, sobre el papel, tenían RMSE’s envidiables. Pero ninguno valía para gran cosa. Al final, se ha impuesto la cordura y la página que recogía los resultados de los modelos ha chapado con el siguiente cartelito:

Hoy me voy a limitar a publicar una imagen de mi flamante home server corriendo la versión 0.1 de mi panel para el seguimiento del mi consumo eléctrico en tiempo real:

Sin duda, iré desgranando los detalles técnicos del sistemita en próximas entradas.

Esta entrada tiene una doble (o triple) motivación. Por un lado, servir de de introducción a otra en la que se tratará la sicología de la estadística y la ciencia de datos. Por otro, plantear una serie de cuestiones —sin intención de aportar solución alguna— relevantes sobre el asunto. Y si se me permite, una tercera: dejar constancia que en su día semileí el librito The Psychology of Computer Programming, que fue el que me ha hecho pensar de vez en cuando sobre estos asuntos y prestarles atención desde entonces.

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

IBM ha desarrollado una iniciativa, Uncertainty Quantification 360, que describe así:

Uncertainty quantification (UQ) gives AI the ability to express that it is unsure, adding critical transparency for the safe deployment and use of AI. This extensible open source toolkit can help you estimate, communicate and use uncertainty in machine learning model predictions through an AI application lifecyle. We invite you to use it and improve it.

En la página del proyecto hay documentación abundante pero recomiendo comenzar por la demo.

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

Ayer leí este resumen de este artículo que propone y discute un algoritmo novedoso y basado en ciencia de datos para ordenar datos y hacerle la competencia a quicksort y demás. Reza y promete:

The results show that our approach yields an average 3.38x performance improvement over C++ STL sort, which is an optimized Quicksort hybrid, 1.49x improvement over sequential Radix Sort, and 5.54x improvement over a C++ implementation of Timsort, which is the default sorting function for Java and Python.

Está aquí y creo que no se le puede quitar ni poner una coma. Es particularmente oportuna porque trata todas esas cosas que nunca se enseñan y que la mucha gente, en el peor de los casos, malaprende.