Python

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, Julia 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 en 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 yo 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.

Así arranca este artículo, que presenta una extensión de XGBoost para predicciones probabilísticas. Es decir, un paquete que promete no solo una estimación del valor central de la predicción sino de su distribución. La versión equivalente de lo anterior en el mundo de los random forests está descrito aquí, disponible aquí y mucho me temo que muy pronto voy a poder contar por aquí si está a la altura de las expectativas.

Se acaba de publicar en GitHub el/nuestro Curso de python básico orientado al análisis de datos. Digo nuestro un tanto impropiamente: casi todo el material es de Luz Frías, mi socia en Circiter. Mía hay alguna cosa suelta. Como coinautor soy el comentarista menos creíble del contenido, lo dejo al juicio de cada cual. Y, por supuesto, se agradecen correcciones, comentarios, cañas y fusilamientos (con la debida caballerosidad, por supuesto, en lo de las atribuciones).

Este martes 17 de diciembre hablaré durante una hora sobre (cierto tipo de) big data y modelos adecuados para modelarlos en el CodingClub de la Universidad Carlos III. El contenido de la charla, entiendo, se publicará también después en el blog del CodingClub. Los detalles (sitio, hora, etc.) están en el enlace indicado más arriba. Obviamente, agradezco a los organizadores del CodingClub por haberme invitado. Es, además, el ciclo de charlas sobre cosas relacionadas con datos más serio y mejor organizado que conozco. Y con eso, prácticamente, cierro el 2019 para casi todos los efectos. En 2020, más.

Pensé que ya había escrito sobre el asunto porque tropecé con él en un proyecto hace un tiempo. Pero mi memoria se había confundido con otra entrada, Sobre la peculiarísima implementacion del modelo lineal en (pseudo-)Scikit-learn, donde se discute, precisamente, un problema similar si se lo mira de cierta manera o diametralmente opuesto si se ve con otra perspectiva. Allí el problema era que scikit-learn gestionaba muy sui generis el insidioso problema de la colinealidad. Precisamente, porque utiliza un optimizador ad hoc y no estándar para ajustar el modelo lineal. ...

Leyendo sobre si dizque PyTorch le siega la hierba debajo de los pies a TensorFlow, averigué la existencia de Pyro. Pyro se autopresenta como Deep Universal Probabilistic Programming, pero aplicando métodos porfirianos (ya sabéis: género próximo y diferencia específica), es, o pretende ser, Stan en Python y a escala. Aquí van mis dos primeras impresiones, basadas en una inspección superficial de los tutoriales. En primer lugar, aunque Pyro permite usar (distintas versiones de) MCMC, parece que su especialidad es la inferencia variacional estocástica. Que parece funcionar de la siguiente manera. En el MCMC tradicional uno obtiene una muestra de la distribución (a posteriori, para los amigos) de los parámetros de interés. Eso es todo: vectores de puntos. En la inferencia variacional estocástica, uno preespecifica la forma paramétrica de la posteriori y el algoritmo calcula sus parámetros a partir de los valores simulados. Por ejemplo, uno va y dice: me da que la distribución del término independiente de mi regresión lineal va a ser normal. Entonces, Pyro responde: si es normal, la mejor media y desviación estándar que encuentro son tal y cual. ...

Es una pregunta que surge reiteradamente. Por ejemplo, cuando se compara un clúster con el resto de la población y uno busca las variables que mejor lo caracterizan. Y crear gráficos como (extraído de aquí) donde las variables están ordenadas de acuerdo con su poder discriminador. Mi técnica favorita para crear tales indicadores es la EMD (earth mover’s distance) y/o sus generalizaciones, muy bien descritas en Optimal Transport and Wasserstein Distance y disponibles en R y Python.

Los modelos mixtos en Python son un bien público. El sector privado no produce suficientes bienes públicos (con excepciones tan notables como las búsquedas en Google o las páginas aún sin paywall de los periódicos). El sector público y los impuestos que lo financian argumenta la conveniencia de su propia existencia en términos de esa provisión de bienes públicos que dizque realiza. Pero ese subsector del sector público que debería implementar los modelos mixtos en Python se dedica a otra cosa. A cosas como estas. ...