Re: nn_lib & gmd

On pouvait s'attendre à cette question :)
Il y a plusieurs raisons :

• Pour nn_lib:

  1. En ce qui me concerne : Se plonger dans l'algorithmique des réseaux de neurones permet de bien comprendre tous les détails et astuces d'implémentation pour que ces réseaux fonctionnent en pratique. C'est très instructif et intellectuellement très profitable quand on fait en parallèle de la recherche dans le domaine du traitement d'images (ce qui est mon cas).
  2. En ce qui concerne l'utilisateur : les bibliothèques existantes d'apprentissage machine sont assez grosses en taille, pour ne pas dire énormes. Par ailleurs, il y avait déjà quasiment tout ce qu'il fallait comme fonctionnalités de base en traitement d'images dans G'MIC (convolutions, redimensionnement d'images, etc.), pour que le travail demandé puisse être vu comme suffisamment incrémental pour ne pas nécessiter de réintégrer toute une bibliothèque, qui aurait doublé beaucoup de fonctionnalités déjà existantes. La réalité, c'est qu'à l'heure actuelle, toutes les fonctions de la bibliothèque nn_lib tiennent en seulement 164 lignes de code G'MIC. C'est très (très!) peu et ça n'alourdit donc aucunement la taille du projet (attention, je ne dis pas que ces 164 lignes ont été simples à écrire :) ).
  3. Le projet G'MIC a l'intention de rester relativement léger, et donc n'a pas vocation à utiliser de "gros" réseaux de neurones (qui peuvent occuper plusieurs centaines de Mo voire plusieurs Go chacuns...), donc être obligé d'utiliser une bibliothèque externe énorme pour gérer de petits réseaux n'a pas un intérêt fou. Les différents réseaux utilisés pour le débruitage tiennent chacun dans moins de 300 Ko par exemple.

• Pour le moteur Markdown:

Au départ, nous utilisions un moteur Markdown classique pour générer les pages de documentation, mais on s'est aperçu assez vite qu'on avait des besoins spécifiques que ne proposait pas le Markdown classique. Et écrire un parseur/générateur Markdown n'est pas très difficile. Là encore, ça a été écrit en langage G'MIC, en un peu plus de 1000 lignes, donc en pratique ça prend très peu de place mémoire (moins de 100Ko) par rapport à la solution d'avoir à intégrer une bibliothèque Markdown (et une n-ième dépendance...). Ca prend un peu plus de temps à développer, c'est sûr, mais c'est avantageux au final.