Tuve que cambiar frecuentemente entre varias variantes de un modelo, cada una de ellas creada con distintos argumentos. Añadir variantes nuevas se volvió insostenible, pero el factory pattern mejoró todo.
Estoy trabajando en reconstruir un vídeo usando una representación neuronal implícita, que es simplemente un fully connected multilayer perceptron que recibe las coordenadas $x,y,t$ de un píxel y entrega la intensidad (o el color) del vídeo en esa coordenada. Hacer esto de forma directa entrega vídeos muy borrosos y sin detalles, por lo que se suele añadir un preprocesamiento a las coordenadas llamado Fourier Features (ver la página del proyecto para más detalles).
La fuente de los datos que uso ha cambiado más de una vez. A veces son datos generados sintéticamente a partir de un video de referencia, usando una función propia. A veces uso una librería. Ahora necesito sacarlos de una base de datos online, y ni siquiera
He estado trabajando en reconstruir un vídeo a partir de algunas frecuencias en el espacio de Fourier, usando una red neuronal. Necesito un vídeo de referencia, el que usaré posteriormente para comparar con el vídeo reconstruido y calcular algunas métricas. Para entrenar la red necesito obtener mediciones del vídeo en el espacio de Fourier. La fuente de los datos que uso ha cambiado más de una vez. A veces son datos generados sintéticamente a partir de un video de referencia, usando una función propia. A veces uso una librería. Ahora necesito sacarlos de una base de datos online, y ni siquiera
Tuve que cambiar el modelo que siempre usaba por uno ligeramente diferente y mis problemas de diseño vinieron a perseguirme. Mi entrenamiento dependía de detalles que deberían haberle sido irrelevantes. Así que era hora de aprender el concepto de Dependency Inversion.
En programación orientada a objetos hay cinco principios que ayudan a que el código no se vuelva infernal: SOLID. Single responsability , Open-closed, Liskov substitution, Interface segregation y Dependency Inversion suenan muy razonables en el papel (o en vídeo), pero en la práctica son súper fáciles de ignorar.
Hace poco descubrí Weights & Bias para trackear experimentos, y me pareció maravilloso. Y entonces dejó de funcionarme en Colab, el principal lugar donde corro experimentos (aún no entiendo por qué). Pero no estaba dispuesta a renunciar a la posibilidad de guardar mis experimentos, así que hice mi propio Logger.
Hace poco descubrí que existían herramientas para poder tener un mayor control de los experimentos (MLflow, Comet, Neptune). Un conocido que trabaja en Machine Learning en la industria me recomendó Weights & Bias, y una vez que aprendí a usarlo me encantó. Y entonces dejó de funcionar en Colab, el único lugar por ahora donde tengo acceso a GPUs para correr mis experimentos. No logré entender qué fallaba, así que me rendí y dejé de intentar arreglarlo. Pero la forma en que guardaban los experimentos me pareció súper inspiradora, así que, puesto que Colab se negaba a dejarme usar W&B, decidí crear mi propio módulo lunar logger con juegos de azar y mujerzuelas.
En mi última práctica profesional trabajé remotamente con Eduardo Graells-Garrido, arreglando el código de un algoritmo de visualización de grafos nodo-arista.
Necesitaba una última práctica profesional de Ingeniería Matemática y me encontré con el trabajo de Eduardo Graell-Garrido, quien hace visualización de datos de transporte. En ese momento me interesó porque en mi tesis estaba estudiando un modelo que incorporara el efecto de la movilización de la gente en la propagación del Covid, y Eduardo trabajaba con datos de la Encuesta Origen Destino que yo usaba. Le pregunté si estaba trabajando en algún proyecto en el que pudiera aportar, y me habló de que tenían una implementación de un paper de visualización de grafos nodo-arista (grafos tipo flecha, donde las aristas tienen un nodo de origen y uno de destino) que fallaba y no entendían por qué.
