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.
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.
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.
El otro día hubo, parece, cierto interés por modelar la siguiente serie histórica de datos:
Notas al respecto:
El eje horizontal representa años, pero da igual cuáles. 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. Se especulaba con un posible cambio de tendencia debido a una intervención ocurrida en alguno de los años centrales de la serie.
[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.
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.
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 como minicoautor 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 modelizarlos 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. Espero no estar arrepentido el martes por la tarde de lo siguiente: es el ciclo de charlas sobre cosas relacionadas con datos más seria y mejor organizada que conozco.
