En faisant varier la quantite de memoire utilisee j’ai continue a faire des runs pour essayer de mieux comprendre ce qu’il se passe. Le probleme c’est que la composante aleatoire de l’experience rend l’interpretation des resultats difficile. Un coup ca a l’air de bien marche, un coup ca a l’air de trainer les pieds… Alors j’ai pris le taureau par les cornes et j’ai automatise une grosse serie de test pour ensuite calculer des moyennes en fonctions des variables. Precisement, j’ai fait ceci : sur l’experience de trackage de cible le long d’un axe d’une duree de 500.000 iterations, j’ai fait varier la quantite de memoire entre 1ko, 10ko, 500ko, 1mo, 3mo, et le nombre de variation du coefficient de deplacement (obligeant le mebius a se reconfigurer pour s’adapter) entre 0, 2, 4, 6, 8 et 10. En sortie j’ai recupere la moyenne de l’ecart a la cible sur tout le run, et la moyenne de l’ecart a la cible sur chaque deuxieme demi-periode entre deux variations de coefficient de deplacement (ca c’est pour mesurer la performance du mebius apres qu’il se soit reconfigure suite a un changement de coefficient en lui laissant le temps de se reconfigurer). Pour chaque combinaison memoire/nombre de variation de coeff de deplacement j’ai fait 10 run et ensuite calcule leur moyenne. Et roule ma poule !
Deja, ca fait un total de 150.000.000 d’iterations. Que ca ait tourne jusqu’au bout sans planter c’est plutot bon signe niveau stabilite du code. Ensuite j’ai aussi mesure le temps d’execution. Etant donne qu’il y a toute la partie simulation de l’environnement et calcul/stockage des resultats ca ne donne qu’une limite tres tres superieure a la vitesse d’execution des mebius seuls, mais on est a environ 20 microseconde par iteration (sur mon i3-2120 (3.30GHz × 4)). La aussi ca me satisfait pleinement. Au passage, a une telle vitesse d’execution, le rythme auquel j’impose une modification de son environnement est extremement eleve. S’il supporte ca je me dis qu’il serait largement capable d’encaisser d’importe quoi dans un systeme embarque lache dans le monde reel. Cote memoire c’est pareil ca semble peu gourmand a la vue des resultats qui suivent.
Et maintenant les resultats : 

A part pour la quantite de memoire minimum qui est un peu au dessus de 0.1, on est toujours inferieur a un ecart de 0.1, c’est pas mal du tout. Avec 1ko le mebius a vraiment pas beaucoup d’espoir, ca correspond a une configuration ou il oublie quasi immediatement … Pour autant il s’en sort quand meme pas mal, surtout s’il est dans un environnement stable (coefficient de deplacement ne variant pas ou peu). Ca c’est grace a un mecanisme d’extrapolation qui lui permet de ne pas oublier completement meme quand il « oublie », mais je ne donnerai pas plus de details. Avec 10ko c’est mieux mais ca reste un peu short, donc logiquement les performances sont meilleures. Avec 500ko, 1mo et 3mo, on obtient des performances equivalentes qui diminuent lentement au fur et a mesure que l’environnement est de plus en plus instable. Ca n’apparait pas sur le graphique, mais les moyennes totales sont tres tres proches des moyennes sur les demi-periodes sur tout les runs, indiquant qu’a chaque fois le mebius s’est reconfigure tres rapidement apres un changement  de coefficient de deplacement.
Conclusion, ca fonctionne de facon tres satisfaisante et je suis content. Passe une certaine quantite de memoire minimale necessaire pour faire son boulot (quelque part entre 10ko et 500ko sur ce cas de test) le mebius s’en sort tres bien (ecart moyen a la cible tres faible), independamment de la quantite de memoire dispo (ecart similaire quelque soit la quantite de memoire) et s’adapte visiblement avec succes a un environnement instable (ecart a la cible variant peu quand le nombre de modification du coeff de deplacement augmente).
Maintenant que j’ai confiance en mes mebius sur cet exemple je vais pouvoir me concentrer sur le deuxieme cas test, plus complexe, realiste et interressant. Juste avant ca je vais peut etre faire un petit truc pour le fun : comme pour les mebius de premiere generation, j’aimerai bien « visualiser » ce qu’il se passe « dans la tete » d’un mebius. J’ai eu une idee qui devrait donner un resultat esthetique pas degueu, alors je vais probablement prendre quelques heures pour la coder…

 

 

En fait, qu’ils soient plus lents me preoccupait tellement que je n’ai pas pu m’empecher de chercher a savoir pourquoi. Alors j’ai continue a faire plein de run sur le premier cas de test. Je n’ai toujours pas compris pourquoi mais aujourd’hui j’ai remarque quelque chose d’interressant. Dans cette nouvelle version, je peux controler la quantite de memoire qu’utilise les mebius. J’ai ajoute ca dans l’optique « embarque » ou j’aurai besoin de les faire tourner dans un environnement avec peu de memoire. Je peux donc maintenant dire au mebius via le fichier de configuration ‘debrouille toi avec 1ko’. Et aujourd’hui je me suis rendu compte qu’en lui imposant d’utiliser peu de memoire je retrouve exactement les meme resultats que dans la version precedente. Si je le laisse utiliser beaucoup plus de memoire, il converge plus lentement. Aussitot je me suis dit ‘bug !’, et puis plus prudemment je me dis que c’est peut-etre un comportement normal mais imprevu de ce nouveau modele. Dans les deux cas j’ai maintenant une piste a explorer pour corriger ce probleme…

 

J’ai fini de nettoyer les bugs dans cette nouvelle version des mebius et j’obtiens les memes resultats que precedemment sur le premier cas de test, a la difference qu’ils sont plus lents a converger. Je vais maintenant regarder ce que ca donne sur le deuxieme cas test.

 

Hier j’ai fini de demeler le sac de noeud et resolu mon bug, grace a valgrind. Maintenant je dois verifier que ca fonctionne toujours sur le premier cas test (track de cible en 2D). Au premier run ca ne marchait pas, mais pas de quoi s’inquieter pour l’instant, on va regarder tout ca tranquillement…

Je suis toujours en train de debugger ce que j’ai fini au debut de la semaine. J’ai un pointeur dans les choux et je n’arrive pas a trouver d’ou ca vient, grrrr… 

J’ai fini de reprogrammer les mebius. En fait ca changeait tellement de choses que j’ai completement efface le module mebius et le module cognit, et je les ai reecris de zero. Au passage, ca ne represente en fait que tres peu de code (un peu plus de 1000 lignes seulement !). Et ca ca me plait beaucoup parce que je suis sur que la solution est forcement un algorithme tres simple, tres petit. En plus c’est plus rapide a debugger, a ecrire, et ca prendra pas de place le jour ou je voudrais l’embarquer dans quelque chose (arduino ou autre).

A part ca j’ai commence a lire GEB de Hofstadter.