Petit test pour voir si les mebius arrivent a converger en partant de cognits non initialises et en utilisants un mecanisme de SRM (selection/reproduction/mutation).

 

Je reprend la meme experience que dans l’article precedent avec une puissance qui ne varie pas (courbe bleue) et une puissance qui varie aleatoirement toutes 4000 iterations, et je trace l’age du plus vieux mebius parmi une population de 10 mebius. Quand la puissance ne varie pas, il suffit que les cognits actor convergent vers la reponse adaptee a cette puissance. Quand la puissance varie, il faut egalement que les cognits teacher convergent vers une reponse permettant au mebius de se reorganiser a chaque variation de puissance, sans quoi les cognits actors ne peuvent evoluer que par mutation, autrement dit en mourant, ce qui limite la duree de vie maximale a a peu pres la duree entre deux variations de puissance. J’ai fait plusieurs runs d’au maximum 1.000.000 iterations mais il donne tous des resultats similaires a celui du graphe ci dessus. Si la puissance ne varie pas (courbe bleue) on converge rapidement vers deux cognits actors optimaux qui donnent des resultats equivalent au mebius configure a la main de l’article precedent. Si la puissance varie (courbe rouge), les mebius convergent vers la duree de vie maximale pour la vitesse de variation de l’experience mais a partir de la ils stagnent (la courbe s’arrete vers 30.000 iterations, signifiant qu’aucun mebius plus performant n’est apparu durant les 970.000 iterations suivantes). Avec une population plus importante, un nombre d’iteration beaucoup plus eleve, un algorithme SRM plus evolue on verrait sans doute apparaitre a un moment ou a un autre des mebius capables de s’adapter a une puissance variante. Mais ce n’est pas mon but ici (au moins pour l’instant), je preferre continuer a configurer a la main mes cognits et voir ce que les mebius sont capables de faire dans l’absolu. Plus tard je reflechirai a une solution ne necessitant pas d’algo SRM, et en fait j’ai deja pas mal d’idee pour ca. Disons que ce sera la 3e generation !
Je commence maintenant une nouvelle experience, toujours dans l’idee trackage de cible, mais en 2d et en simulant un systeme de deplacement plus complexe et surtout plus realiste.

Au passage, j’ai decouvert il y a quelques jours l’arduino et je suis tres emballe. Ca serait assez immediat de porter mes mebius dessus et les confronter au monde reel 🙂

http://arduino.cc/

 

Aujourd’hui repos, j’ai donc pu pas mal me concentrer sur les Mebius et bien avancer. Les fichiers de configurations commencent a avoir une belle tete, les cognit actors ca roule mais il faut que je remette en place le systeme d’interpolation sur les valeurs de sortie comme l’annee derniere car ca booste vraiment bien les resultats), et j’ai fait la moitie des cognits teachers. Avec juste des cognits actors definis tres simplement via le fichier de config j’obtiens deja des mebius capable de trouver et suivre une cible en 1D (de facon tres peu efficace). J’ai fait en passant une petite routine pour m’afficher en clair le contenu d’un mebius a partir de son fichier de config, et des que je finis les cognits teacher, j’ajoute une interface pour utiliser un mebius dans un programme tiers (du genre : init(fichier de config), setInput(), process(), getOutput(), terminate() ). Avec les teachers je devrais obtenir des mebius qui traquent la cible efficacement, je commencerai a afficher des resultats ici a partir de la. Ensuite faire evoluer le niveau de complexite et voir jusqu’ou on peux aller.

 

En ce moment j’avance en particulier sur le format du fichier de definition des Mebius. Dans l’optique Mebius=outil/nouveau langage de programmation, ca revient a definir la syntaxe du langage, le programme etant l’interpreteur de ce langage.

Aussi, j’avais besoin de tracer quelques surfaces 3D vite fait alors j’ai cherche un outil, et finalement j’ai trouve GNU Octave qui fait ca tres bien :

http://www.gnu.org/software/octave/

 

 

Je continue a coder, un petit peu quasiment chaque soir… Ca avance et pour l’instant tout va bien. Mais j’ecrirai plus en detail plus tard.

Ce soir j’ai avance sur l’implementation des cognits. Ayant deja implemente une premiere version et grace a de long mois a ne pas pouvoir coder mais a y reflechir en tache de fond, j’ai les idees claires sur ce que je veux faire et du coup ca avance vite. Mais etant donne le peu de temps que je peux y consacrer ca va encore prendre quelques jours avant de voir les Mebius bouger a nouveau… En tout cas je suis tres optimiste sur les futurs resultats.

 

Bon finalement a bien y reflechir ca ne m’apporte pas grand chose d’avoir fait une architecture multiprocessus, alors plutot que de passer du temps la dessus je suis revenu a une architecture mono processus. Donc la ca tourne en mode texte, mono processus, sous valgrind, et ca amrche. A partir de demain, je commence a implementer les cognits.

A part ca, pendant mes pauses je fouine souvent sur youtube entre autres avec des mot cles genre IA, automate, neurones, … Dans 99% du temps c’est totalement ininterressant mais aujourd’hui j’ai trouve un chouette montage video d’une serie de configuration interressante dans le jeu de la vie de Conway :

http://www.youtube.com/watch?v=C2vgICfQawE

 

Le mecanisme de creation de cognit est presque en place mais je me suis rendu qu’il y avait parfois des problemes de blocages dans la communication inter processus, classique. Je suis donc en train d’arranger ca.

 

Ce soir j’ai fini de valider l’interface en mode texte. Par contre si je laisse tourner tout le temps sous valgrind ca me gene car l’architecture etant devenue multi processus a la fin de chaque processus (a la mort de chaque mebius) valgrind m’affiche son compte rendu qui vient se melanger a l’affichage de mon interface, c’est du plus mauvais effet… Je vais pas regarder ca ce soir mais j’aimerai bien que valgrind utilise le flux stderr pour son affichage, ca me permettrait de le rediriger vers un fichier et de le piper dans un deuxieme terminal si je veux voir en simultanee, ou simplement fouiller dedans plus tard quand necessaire. Ceci dit c’est un detail et a partir de demain soir, ENFIN, je m’attaque a l’implementation des Mebius.

 

J’ai fini la gui en mode texte, et comme j’avais resorti valgrind j’en profite pour en passer un coup sur la nouvelle architecture de simulation comme ca j’aurai une base bien clean pour coder les Mebius, plutot que d’attendre que ca crashe et passer des jours a tout nettoyer comme pour la premiere version. En plus avec ma nouvelle machine, vu la difference de vitesse je pense que je vais toujours faire tourner sous valgrind a partir de maintenant pour tout de suite detecter le moindre probleme. Je l’enleverai une fois que le developpement sera termine et que je serai convaincu d’avoir un code stable.

Avec bien de la peine je suis arrive a faire fonctionner GTK hier soir, mais ca a vite crashe juste apres. J’ai donc resorti valgrind pour debugger, et il m’a pointe une fonction gdk. Prudent, je me dis que ca doit etre un effet de bord d’un bug dans mon programme, mais legerement remonte contre GTK je commence par tester sous valgrind un petit programme d’exemple downloader de leur site web. Comme je le craignais valgrind me sort un message de violation de memoire dans chaque appel de fonction gtk/gdk. Bon allez ca va j’ai compris, je ne me pose pas plus de question, j’ai tout vire et ce soir j’ai fait une interface en mode texte a la place. Ca fait un peu prehistoire mais ca au moins ca marchera, ca sera plus rapide (a programmer et executer), ca tournera sur mes vieux portables sans avoir a faire de portage, etc… Pour les graphiques, ca sera comme avant, des fichiers de donnees bruts traites par un tableur (LibreOffice Calc). Pendant l’execution, des donnees textes me suffisent pour savoir ce qu’il se passe. Reste le cote fun des videos que je postais sur ce blog via youtube, mais bon ca on pourra toujours les regenerer d’une facon ou d’une autre plus tard a partir des fichiers de donnees…