Python

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, en el título, squared errors, pero lo que se cuenta debajo aplica a cualquier 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 y que, típicamente trataban de estimar el número futuro de casos, hospitalizaciones y defunciones. Fueron desarrollados por la crème de la crème: MIT, Columbia, Harvard, Google, etc. Todos, sobre el papel, tenían RMSEs 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 y ha colgado en la persiana el siguiente cartelito (con mi traducción):

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.

Una de mis aficiones más excusables es la de participar en el mercado de predicciones de Hypermind. Una de las preguntas que se suele plantear anualmente —y en la que, gracias a apostar contra el común/apocalíptico sentir, logré pingües beneficios el año pasado— tiene que ver con cuándo nos vamos a morir todos. De otra manera:

Este año también quiero participar, pero como no sabía por dónde empezar, he bajado los datos. En su perspectiva más relevante, tienen este aspecto:

El otro día hubo, parece, cierto interés por modelar la siguiente serie histórica de datos:

Notas al respecto:

1. El eje horizontal representa años, pero da igual cuáles.
2. El eje vertical son números naturales, conteos de cosas, cuya naturaleza es poco relevante aquí, más allá de que se trata de eventos independientes.
3. Se especulaba con un posible cambio de tendencia debido a una intervención ocurrida en alguno de los años centrales de la serie.

Lo que se ve es el resultado del ajuste de un modelo de Poisson casi trivial. Es casi trivial porque utiliza el tipo más simple de splines para modelar una tendencia quebrada en un punto desconocido, uno de los parámetros del modelo.

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

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

Hoy me he retrasado en escribir por haber estado probando (y estresando, como hay quien dice), software para resolver problemas de programación lineal. En total, nada, unos diez millones de variables unos treinta millones de restricciones.

Nota: es un problema LP puro, nada de enteros, nada de pérdidas no lineales, etc.

• Primera opción: Python + PuLP + CBC (de COIN-OR), que es el optimizador por defecto de PuLP. Rendimiento aceptable para el tipo de uso que se le acabaría dando. Se ha convertido en el benchmark.
• Segunda opción: Python + OR-Tools (de Google), y en particular, Glop. Un tanto decepcionante: aunque ne términos de velocidad no es apreciablemente inferior a CBC, en muchos casos desistía y no encontraba ninguna solución.

Este tipo de problemas y yo nos reencontramos indefectiblemente cada cinco años. Así que, de una vez a otra, se me ha olvidado casi todo. De modo que si alguien tiene el asunto más fresco y le da rabia que algún diletante como opte por soluciones subóptimas y/o viejunas y esté entre asombrado e indignado de que ignore el último grito de la cosa, tiene la posibilidad de enmendarme a mí y enseñarnos, de paso, a todos, en los comentarios.

Así vendría a traducirse el título de este artículo, que trata de taxonomizar y sistematizar una serie de técnicas muy recientes para explicar modelos de caja negra.

Tal vez no acabe siendo la manera pero, sin duda, acabará habiendo una.