Programación

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

Cada cierto número de años me reencuentro con la cuestión de BLAS, ATLAS y todas esas cosas por tratar de arañar un poco de eficiencia a R.

Existen el BLAS de toda la vida que, parece ser, viene de serie con R y uno puede optar por otras versiones optimizadas como ATLAS u OpenBLAS, cuyas ventajas relativas, de acuerdo con estos benchmarks, no parecen demasiado claras.

Lo novedoso en esta revisita al problema es que he aprendido que a los anteriores se han sumado en estos últimos años, cuando menos:

In illo tempore me llamaba mucho la atención encontrar métodos de ciencia de datos basados en factorización de matrices cuando la matriz a factorizar tenía nulos. Ocurre, por ejemplo, en sistemas de recomendación (cuando un usuario no ha visto o no nos ha dicho si le gusta determinada película).

Y claro, con un nulo en la cosa, te comes los apuntes de álgebra lineal con papas.

¿Cómo se hace? Si buscas $U$ y $V$ tales que $Y = UV^\prime$:

Tengo dos ordenadores, tiramisu y ede. Uno va conmigo y el otro me espera en casa.

Hasta hace 4 días, usaba OwnCloud para mantenerlos sincronizados y, de paso, gestionar mis backups: siempre tenía tres copias de mis datos en tres sitios distintos (mis dos ordenadores y un VPS). Pero:

• Alquilar un disco duro en la nube no es tan barato.
• OwnCloud es un coñazo: hay que actualizarlo cada que se te olvida cómo.
• OwnCloud es demasiado… aparatoso. Es más adecuado para organizaciones que para uso personal.

Buscando alternativas, llegué a una lista corta de dos:

Resumen:

• He decidido usar RStudio como IDE para Python. RStudio no es el mejor IDE para desarrollar, pero es incomparablemente mejor que cualquier otro IDE para explorar, etc. Funciona muy bien y solo puede mejorar.
• He decidido pasar de Jupyter. Los notebooks valen para lo que valen, pero no para lo que hago. En caso de necesidad, uso Rmarkdown con bloques de Python. De nuevo, funcionan muy bien y solo pueden mejorar.
• Finalmente, he decidido pasar de Anaconda. Tiene incompatibilidades con RStudio. Particularmente, cuando los módulos de Python tratan de cargar shared libraries. Los módulos de Anaconda tienen el vicio de buscarlos dentro del directorio de instalación, pero al lanzar el intérprete de Python a través de reticulate, en Linux parece que los busca en el sistema (por debajo de /usr/lib y similares). Y todo se rompe mucho. Mucho y muy, muy feo.

Así que uso los Python (3.7 cuando puedo, otras versiones cuando me obligan) del sistema. Pero la instalación del sistema es mínima. He creado varios environments ad hoc (y dentro de un directorio ad hoc para ellos) y obigo a reticulate a usarlos (vía use_virtualenv()) según conveniencia. En ellos tengo todas las dependencias (de numpy para arriba).

Así que si eres uno de ellos, lee esto. Todo. Completo. Incluidos los motivos por los que no se va a liberar tal cual.

Si te quedas con ganas de más, lee esto (un divertimento) o, más en serio, esto otro, donde se da cuenta de uno de los logros de GPT-2 que, a primera vista, pasa desapercibido: que ha logrado adquirir determinadas habilidades sin haber sido entrenado específicamente para ello.