C'est bien à LISP ou SCHEME que je pensais. />/>/>
J'ai un peu répondu sur un souvenir de cours, mais je viens de relire l'OP, je vais donc essayer de re-contextualiser ma réponse. En fait, ce type de langage (fonctionnelle) est intéressant pour faire évoluer les programmes : la régularité dans la syntaxe permet d'échanger deux bouts de code sans générer des syntax error. Je m'explique :
...

Attention, les deux exemples que tu donne dans les 2 langages n'ont pas du tout la même portée.
Pour ce code en lisp:

gen_1 : (x (+ 3 5) capteur_mesure)
gen_2 : (ET obstacle_dist avancer_dist)

Ce code implique que x soit un fonction dont une des arité est 2 et que ET soit une fonction d'arité variable (en lisp c'est le cas, toute la parenthèse est sommée) et permuter le premier composant plantera si l'arité de la fonction x n'est pas bonne.

on a ce code en c, en utilisant tout le sucre syntaxique que permet c:

gen 1 : x(3 + 5, capteur_mesure)
gen 2 : obstacle_dist & avancer_dist

ou, ce qui est strictement équivalent et tout aussi correct syntaxiquement en c

gen 1 : x(add(3, 5), capteur_mesure)
gen 2 : et(obstacle_dist, avancer_dist)

Ce code implique les mêmes contraintes syntaxiques que le code précédent en lisp, mis à part la position des parenthèses et l'ordre des mots du langage. Et oui, ça le rends plus compliqué à manipuler que celui en Lisp (du moins dans celui de la première versrion), mais en même temps de forcer à permuter dans des morceaux de syntaxe équivalents (par exemple les paramètres de 2 fonctions) peut donner un meilleur contrôle sur ce que tu fait, ça dépends de comment tu gère tes permutations, et même en lisp tu n'a pas intérêt à le faire de manière totalement aléatoire, mais à les diriger pour maintenir la consistance du programme. Donc c'est discutable, ce qui est mieux. Je pense que c'est un choix personnel après.

Ensuite, l'exemple que tu donne de code en C est instranscriptible directement en lisp (la seconde ligne n'existe pas comme brique élémentaire, affecter, puis muter une var est impossible en lisp). Attention, on peut faire en lisp un programme équivalent à celui en C qui utilisera ton extrait en C, mais on passe alors à un paradigme de liste splitée et de la réccurence, comme pour tout ce qui n'est pas trivial comme opération dans ces langages. La puissance syntaxique n'étant pas la même, c'est difficile de comparer la pertinence du sous ensemble du programme traité. En fait, on ne joue pas avec les mêmes briques élémentaires. Après, c'est peut être intéressant aussi de ne pas avoir de variables a manipuler... Là encore, c'est à voir.

Enfin, le problème de c, c'est surtout que ce code ne fonctionnera pas sans avoir construit la déclaration des variables idoine avant, mais c'est un problème que tu n'aurais pas par exemple, en python, tout en gardant tout le reste (plus le garbage collecting, etc...).

L'ordre de la notation – préfixe (opérateur var var - par ex LISP ou SCHEME), postfixe (var var opérateur - comme FORTH ou RPL) ou infixe (var opérateur var - comme les maths) – ne change pas la complexité structurelle en fait, ton arbre aura toujours le même nombre de nœuds, c'est l'ordre des branches au sein de l'arbre et leur sens de lecture qui change.

Sortir la parenthèse – (func, arg1, arg2) au lieu de func(arg,arg2) – en revanche, ça peut peut-être faciliter la génération plus automatique du code parce que tu généralise ta notation. Du coup un nœud commencera par "(".

Enfin, utiliser un langage fonctionnel, c'est à dire remplacer des variables par des données fixes, ça implique parfois d'avoir au lieu d'une variable plusieurs données, ou une syntaxe accumulant la même donnée (la liste manipulée). Ce qui est intéressant c'est que tu sors effectivement de la linéarité artificielle de l'exécution du code, ta structure est donc un peu plus libre, mais tu risque de devoir plus charger ton arbre de compilation pour un résultat équivalent.
en scheme :

(define (map f lst)
    (cond ((null? lst) lst)
          (else (cons (f (car lst))
                      (map f (cdr lst))))))

en python :

def map(func, liste):
    res = []
    for elt in liste:
        res.append(func(elt))
    return res

ou (plus pythonique mais strictement équivalent)

def map(func, liste):
    return [func(elt) for elt in liste]

en c++ :

template < class InputIterator, class OutputIterator, class UnaryOperator >
  OutputIterator transform ( InputIterator first1, InputIterator last1,
                             OutputIterator result, UnaryOperator op )
{
  while (first1 != last1)
    *result++ = op(*first1++);  // or: *result++=binary_op(*first1++,*first2++);
  return result;
}

En python ou on C, tu passes par une boucle et tu remplace chaque élément par le résultat de la fonction.
En scheme (le fonctionnel), tu doit faire un appel récursif sur chaque elt de la liste séparé de la liste, donc tu : sépare un élément de la liste, calcule le reste de la liste séparée récursivement, et recolle la liste. Ça me parait un tantinet plus complexe comme arbre de compilation, même si ça supprime effectivement le besoin des nœuds de type 'for' ou 'while' en les remplaçant par des récurrences.


Je ne suis pas certain que tu y gagnes au final.

En revanche, ça peut être intéressant de regarder les langages fortement mais non déclarativement typés, comme le Caml. Imagine la surcharge de devoir gérer la cohérence entre le type d'une var lors de sa déclaration et lors de son usage, alors que tu peut utiliser des typages dynamiquement calculés. Bref, c'est à voir et à soigneusement étudier avant de commencer à te plonger dans du code.

Après, je ne connait que le principe des algo gens et n'en ait jamais programmé moi-même, alors je me trompe peut-être du tout au tout, hein, je ne fais que donner mon humble avis sur comment je commencerais. />

Alors je vais te parler un peu de compilation (programmation de compilateurs):
Un programme vu par un compilateur, c'est un arbre d'instructions dont chaque bloc de code (typiquement les fonctions, ce qui est dans les clauses if, then et else, et ce qui est dans les boucles) est un nœud et dont les branches d'un même nœud sont ordonnées. Toi, ça te paraît linéaire, parce que tu le lit dans un fichier texte qui est linéaire, mais pas pour le compilateur ou l'interpréteur. Et je ne parle pas non plus de la complexité de l'exécution d'un programme, qui est encore un problème différent.

Bref, un simple

if A or B then {
   foo
   bar
}

c'est déjà un arbre avec 4 feuilles (A, B, foo, bar) et 3 nœuds (if-then, or, {}). La complexité de cet arbre augmente assez vite (et encore je n'ai pas défini foo et bar, qui sont probablement eux-même des arbres). C'est ce genre de choses que tu devra manipuler si tu veut faire un "programme" génétique. Pas question par exemple de dire "tiens, choisi 20 instructions parmi celles-là". Le 20 est lui même une chose qui devra être testée mais surtout rendue cohérente avec la recherche.

Si je prends un langage au hasard, par exemple python qui possède une notation relativement allégée par rapport à d'autres et que je compte le nombre de "statement", c'est à dire de mots du langage, j'en ai facilement 20. Les opérateurs y'en a facilement 30, et encore je ne parle pas de l'analyse syntaxique des noms de variable et de fonctions. Bref, un pool de 50 composants qui articulent le programme, plus les variables. Soit 50 type de possibilité pour chaque nœud (un 'or', qui possède une arité de 2 peut contenir 2 feuilles aussi bien que 2 nœuds qui peuvent être n'importe quelle expression bien construite du langage, un '.' bien que son arité soit 1 peut faire appel à n'importe quel attribut ou propriété d'un objet...).

Donc pour un nœud, 50 possibilité de valeur du nœud à multiplier par l'arité du type de nœud et encore à multiplier par la complexité des possibles expressions bien construites qui en découlent...

Je ne cherche pas à te décourager, mais à te faire réaliser la complexité de ce à quoi tu t'attelles. Faire une recherche aléatoire mais dirigée dedans est possible, mais c'est très complexe. Tu devra probablement le faire sur un langage que tu aura construit toi-même, ce qui veut dire un langage qui n'est pas forcément complet...

Après, y'a des astuces pour gérer moins d'instructions, comme par exemple de ne placer les opérateurs logiques que dans les clauses if. Mais ne perds pas de vue que tu auras 2 complexités à gérer, celle de l'univers dans lequel tes créatures évoluerons, et celle du langage qui supportera ton programme génétique.

À mon avis, commence par très petit pour le simulateur et pour le langage, puis quand tu auras un truc qui complet qui tournera (un programmateur génétique ET le simulateur qu'il utilise) alors tu pourra chercher à augmenter les capacités du langage, avant d'augmenter celles de l'espace de simulation. Courage !

Alors tu es bien dans le paradigme de l'intelligence dans le comportement collectif mais pas de l'évolution d'individus intelligents (ce qui n'étais pas clair vu que tu partait de l'intelligence humaine, qui est individuelle).

Le système que tu décrit me fait plus penser à un système de tableau noir qu'à de la programmation génétique. Une liste de règles (ce que tu appelles méthodes élémentaires) posées et appliquées selon un ordre et un poids. L'ordre et le poids pouvant évoluer avec l'apprentissage. Si ton algo n'est qu'une liste de commandes, sans structures de boucles et de tests, ce n'est plus a proprement parler un programme (bien que le système qui gère cela soit lui un algo gen).

Il existe déjà des systèmes qui permettent de fournir (entre autres) tous les composants de la simulation d'agents basée sur de telles règles (par exemple DIMA, du lip6 (en java), j'y ai intégré un système pour gérer les règles durant mon DEA), mais a ma connaissance ils n'intègrent pas encore les algos gen comme sélecteurs de priorités/poids. Cela dit ils te faciliteraient grandement le travail pour tes simulations, tu devrais y jeter un coup d'œil !

Et sinon, et ça n'a rien à voir :
J'ai entendu hier une émission sur la façon dont les abeilles communiquaient entre elles dans la ruche sur leurs zones de butinage. C'était comme un apprentissage, avec un individu faisant une danse codée traduisant pour les autres la position du cite intéressant, sa richesse, son danger, etc... Bref, un beau système multi-agents. Et comme dans tout système d'apprentissage, y'a une part d'exploration (certaines abeilles) et une part d'exploitation (certaines abeilles collectent). C'est souvent un point problématique dans un système d'apprentissage, comment déterminer la part d'exploration par rapport à celle d'exploitation. Et j'ai trouvé la solution des abeilles très élégante, parce qu'adaptable. Ce sont les butineuese les plus vieilles de la ruche, qui, passées un certain âge, deviennent exploratrices (et donc celles qui ont le mieux survécues aux péripéties de la collecte toute une vie d'abeille durant.

Bref, à noter : dans un système d'apprentissage ou les individus peuvent mourir à des ages différents, pour résoudre le problème de la part d'exploration par rapport à la part d'exploitation, faire exploiter tous les individus dans leur jeunesse, puis faire explorer les individus à partir d'un peu avant qu'ils n'atteignent l'espérance de vie moyenne de la population.

Vu ton projet, il est possible que ça te serve.

C'est même de la programmation génétique, et pas seulement des algos génétiques dont tu parles.

Un algo génétique fait évoluer une population de chromosomes-solutions à un problème. Ces solutions sont fixes en taille et généralement linéaires dans leur application immédiate (Par exemple les valeurs des connexions d'un réseau de neurones, dont le nombre est déterminé. Pour chaque individu, tu attribues ces valeurs une fois à ta grille de neurones et tu en excites les entrées une ou plusieurs fois, selon ton modèle, pour en mesurer les résultats). Permuter 2 gènes, c'est permuter 2 chiffres. ça reste trivial, même si en canaliser les conséquences sur un apprentissage évolutif par un algo gén peut en rendre les conséquences très influentes.

En programmation génétique, c'est un cas particulier : c'est une population de programmes qu'on fait évoluer. Un programme n'est pas délimité par sa taille ni par sa linéarité (même si sa représentation codée est linéaire, ce n'est pas le cas de sa complexité). Il est délimité par un espace d'instructions possibles et la façon dont celles-ci s'imbriquent. Permuter 2 lignes de code, ou 2 lettres dans le nom d'une variable, ça mènera dans la quasi totalité des cas à un plantage syntaxique... Bref, ça reste faisable, mais déterminer un espace d'évolution du programme pertinent est une autre paire de manches. Et je ne te parles pas de l'univers dans lequel ce programme évolue, hein, soyons clairs, mais bien de la matière première que tu vas donner à ton algo gén comme chromosomes.

Tu veut créer de nouveaux individus "intelligents" (trouver de nouvelles "structures de programme" d'intelligence), pourquoi pas, mais tes individus seront-ils intelligents ou appliquerons-t-il seulement un programme, comme un programme joueur d'échec ? Est-ce que l'intelligence ne sera pas dans ton système de programmation génétique au lieu d'être dans les individus ? Est-ce que créer de cette façon des individus réellement intelligents (capables de s'adapter et de s'améliorer par eux même) n'implique pas qu'ils soient eux même capable d'apprendre, donc nécessitant un apprentissage long (lui même sur plusieurs millier d'itérations) à chacune des itération (individu) de ton programme ? comment gérer cette complexité (complexité de l'apprentissage d'un individu × complexité de l'apprentissage évolutif de ton système) ?

ben... après, ça dépends ce qu'il entends par "intelligence", hein :Þ

Oulalala... J'ai l'impression que vous mélangez tout la !

Alors concernant le C/C++ :
Arduino EST DU C++, vous avez donc acces à toutes les librairies STANDARD C++. Et j'ai bien dis STANDARD, or la libpthread, n'est pas un standard C++ c'est un standard POSIX qui a été implémenté entre autre pour le C++. Or le standard POSIX nécessite un OS qui supporte ce standard.
Comme vous le savez tous, une arduino n'a pas d'OS, donc pas de POSIX, donc pas de libpthread.
Par contre vous aurez accés aux trucs standard de C++ (pratiquement tout il me semble) et la libC.

Merci pour ces éclaircissements, comme je l'ai dit, je n'ai jamais utilisé arduino. Y'a vraiment la STL c++ dessus ?

Concernant maintenant les threads :
Ce que l'on appelle thread ce sont des parties de code indépendantes, qui peuvent se "préempter" les unes les autres (souvent avec des priorités).
Il n'est pas obligé d'utiliser la libpthread pour creer des threads.

C'est tout à fait ça. D'ailleurs il existe d'autres librairies de threads à ce qu'il me semble.

Sur un microcontroleur comme arduino, il existe des timers que l'on peut utiliser, ou des interruptions externes. Certaines fonctions sont alors appellées à ce moment la uniquement et on peut appeller ça un thread (car ne faisant pas parti d'une boucle et s'executant sur une interruption).

Perso dans l'arduino j'ai un "thread" principale qui tourne dans la loop() qui fait des trucs, et j'ai un autre thread qui se lance toutes les X millisecondes (sur un reveil de timer) et qui s'execute en mettant en pause la loop.

On a donc 2 parties de codes totalement differentes qui s'executent totalement indépendament. Ce sont donc des threads.

2 threads, c'est encore gérable "à la main", mais quand on commence à en avoir plus, ça devient vite un vrai casse-tête de gérer entre autres les interblocages.

Mais ces bibliothèques, on peut les faire soit meme je crois non ? Pas moyen de retranscrir pour arduino ?

Autant réinventer la roue, et il n'est pas certain que l'embarqué d'arduino ait des capacités suffisantes pour en réinventer toutes les formes disponibles ailleurs.

Selon toi quels éléments manqueraient au langage arduino pour etre aussi efficace que le c++ ?

Dans un langage de programmation, tu a 2 composantes : la syntaxe, c'est la structure qui décrit la programmation (les if/then/else, les boucles, comment définir une variable, etc...) et les bibliothèques, qui sont des collections de fonctions qui représentent l'ensemble de tout ce qui a été écrit génériquement pour faciliter la tache du programmeur avec des outils de haut niveau.

D'après ce que j'ai aperçu du langage arduino, c'est une surcouche de contrôle spécifique aux composants qui s'appuie donc sur la composante syntaxique du c. En gros : le langage arduino, c'est du c minimaliste + une bibliothèque pour les composants arduino. Et c'est tout. Tu n'auras pas les bibliothèques de threads, par exemple.

Le langage c++, c'est au contraire l'accès à tout ce qu'on peut faire en informatique, y compris le plus complexe. Mais pour cela il faudra les bibliothèques correspondantes à tes besoins, donc du c/c++ embarqué sur un linux.

Ce qu'il manque à arduino, c'est donc toutes les bibliothèques standard du c/c++.

miq75, d'aprés ton lien c'est la fonction "void" qui introduit le tread ? Si c'est ça alors c'est ce que je fais déja. Il faut juste que j'évite d'utiliser "delay()" pour éviter le ralentissement de la lecture des treads:
par exemple si je veux faire clignoter 2 leds à des fréquances différentes, si j'utilise "delay()" le programme va faire clignoter les leds l'une aprés l'autre et non simultanément.

Non, c'est "pthread_create" qui introduit le thread (qui sépare l'execution en deux branches, c'est à dire la ligne suivante de code d'un coté, et le contenu de la fonction passé en argument de l'autre coté). Le "void* ma_fonction(void* data);" est la fonction qui décrit ce que fera le thread, et son nom, c'est "ma_fonction". "void*", c'est le type de retour de la fonction du thread (en gros un pointeur sur un type indéfini).

En gros, tu écrit une fonction de la forme
void* couche_numero_x(void* data);
qui va contenir une boucle infinie : le traitement de ta couche.
et tu fais un appel à
pthread_create(&thread, NULL, couche_numero_x, (void*)&valeur);
par thread (= couches) que tu veut gérer.


De toute façon, si tu veut mettre un semblant "d'intelligence", c'est à dire des algos te permettant l'apprentissage, tu aura besoin de passer par c ou c++, alors autant l'apprendre tout de suite.

miq75, je programme avec le langage d'arduino. Par contre pour l'histoire du multitreads je vois pas du tout comment faire^^

voilà un lien pour les threads, en c (donc qui devrait à priori être accessible avec arduino qui est basé dessus ?) : http://www.siteduzero.com/tutoriel-3-3291-les-threads-et-les-mutex.html

Sinon comme le dit Black Templar, directement en c++ ce sera plus facile...

On pourrait faire aussi des petites fonctions intermédiaires, qui rassembleraient plusieurs informations vennant de différents capteurs, et qui les traiteraient pour justement en ressortir une donné symbolique ? Ca permetterait de ne pas surcharger les couches de lignes de codes.

ben, oui, c'est même à priori avec ça que tu fera la couche 1.

J'aimerai coder en "dur" pour pouvoir fixer moi meme son comportement général, mais aussi lui donner un système d'apprentissage.

Fais toutes les couches en dur, sans apprentissage, puis quand tu aura un programme fonctionnel complet, remplace le codage en dur d'une des couches par de l'apprentissage.

Le problème c'est comment lui faire apprendre, c'est à dire ajouter qqch de nouveau à la structure du programme..
Peut etre en créant des tas de variables et fonctions vièrges, le tout triés par catégories.

Pour faire de l'apprentissage automatique, il te faut une structure rigide de contrôle (exemple A réseau de neurone : une matrice de connexions (synapses) entre différentes cases (neurones) – exemple B algos génétiques : un ensemble des bouts de code élémentaires prédéfinis (des gènes) dans une population d'individus limitée) dans laquelle certaines choses vont évoluer (exemple A : les pondérations des synapses, plus leur poids est fort, plus elle transmettrons l'excitation de leurs neurones en amont à leurs neurones en aval – exemple B : le programme (ou l'adn) de chaque individu, c'est à dire l'ordre dans lequel vont êtres exécutés ces bouts de codes et les structures entre elles (tests, boucles, etc.)).

Dans cette structure rigide définie, ces composants évolutifs vont être "dirigés" alternativement par 2 choses : l'exploration (on change au hasard) et on évalue l'amélioration du résultat, et le renforcement (on reteste ce qui a déjà fonctionné plus tôt, éventuellement avec des modifications minimes, et on évalue l'amélioration du résultat. Dans les 2 cas, il faut évaluer le résultat (donc il faut une fonction d'évaluation, de satisfaction ou quelque chose qui s'y assimile) et en fonction de ce résultat on oriente en retour les prochains renforcements (exemple A : on augmente les poids des synapses utilisées quand le retour est positif – exemple B : on privilégie la reproduction des individus performants).

Ça a ses limites, à savoir : la rigidité de la structure de contrôle, dont on fixe arbitrairement la taille et la forme, la difficulté de doser la part d'exploration par rapport à la part renforcement, et la complexité de la pertinence de la fonction d'évaluation.

Et aussi lui introduire l'oublie :

C'est intégré : (exemple A : avant chaque passage, le poids de chaque synapses est rapproché de zéro de manière infime, afin que la somme des poids des synapses soit constante après altération des poids – exemple B : le nombre d'individus étant constant, pour créer de nouveaux ADN, il faut se défaire d'anciens, les moins efficaces). Il ne peut pas y avoir "apprentissage" sans une forme d'"oubli". Après, si tu parles d'oubli volontaire de solutions efficaces, pour introduire une propension à l'erreur/créativité, c'est un autre problème bien plus complexe encore. Je te déconseille de t'y arrêter pour l'instant...

Pour le partage de taches j'en ai aucune idée.
Je vais déja remplacer mes "delay" par le système similaire qu'on retrouve dans "BlinkWithoutDelay" dans les exemple sur le logiciel; apparement c'est pour éviter que le programme attende la fin du delay pour lire les lignes suivantes, non ??
Sinon je n'ai pas d'autre piste.

Et que fait le programme selon toi en attendant ? C'est exactement ça (le principe, hein, je ne sais pas quel langage tu utilise). Il laisse alors la main à d'autres processus (ou threads). Ceux du programme s'il en existe, sinon ceux de l'OS.
Chaque thread est indépendant en terme d'exécution des autres (ils s'exécutent en parallèle – c'est à dire un pas chez l'un, puis un pas chez l'autre, puis un pas le suivant, etc – mais comme leur contexte est chargé de manière invisible par l'ordi, pour toi, tu a l'impression que chacun fait ce qu'il veut de son coté, comme si tu avais plusieurs programmes qui tournent en même temps). Après, c'est à toi de gérer leurs interactions et de t'assurer que deux threads différents ne vont pas s'empêcher mutuellement de travailler ou se corrompre (imagine 2 personnes différentes écrivant le même poème, il ne faut pas que l'un modifie la fin de la première rime en même temps que l'autre écris la rime qui correspond, ça risque de poser problème...).

Au début de ton programme, tu as intérêt à créer un thread pas couche avec la structure qui te permet de les contrôler tous. Après, il te reste à faire un "programme indépendant" pour chaque couche. (Et à bien penser à éviter les interblocages et à fermer tes threads/process quand tu termine l'exécution.)

Et pour la communication entre les couches, pourquoi pas la faire avec des variables :
La couche 1 inscrit tel valeur dans la variable V
La couche 2 lit a valeur de V, et traite l'info

C'est exactement ça. Mais utilise des structures plus complexes que les variables simples, car il faudra à un moment définir quelles sont les variables partagées et entre certaines couches elles seront symboliques (leur sens fera partie de la variable elle-même). Et fait attention à bien définir de manière visible ET respecter les ensembles de variables en fonction des couches qui ont autorité pour y écrire ou y lire.

Salut.

Ton programme va devoir avoir plusieurs couches. La première sera la couche matérielle; celle qui te donnera les résultats des capteurs (du genre "luminosité à gauche = 35"). La seconde sera une couche symbolique; qui transformera ces données physiques en données symboliques, comme dit plus haut (du genre "il fait jour"). Il te faudra au moins une troisième couche, décisionnelle. C'est celle-ci qui déterminera le but actif. (Comme il fait jour et que mes batteries faiblissent, je décide de faire la sieste au soleil). Et encore une 4ème couche, applicative (quelles actions élémentaires correspondent à cette décision ?)

D'une manière générale, plus tu ajoutera de couches abstraites (par exemple, un niveau 3,5 "prévisionnel", ou un niveau 2,5 de "mémoire"), plus ton robot sera "intelligent".

La première couche est facile à faire, elle est linéaire, la seconde est déjà plus complexe. Est-ce que tu veut faire un apprentissage ou est-ce que tu veut coder en dur la détermination de symboles ? Coder en dur est beaucoup plus facile, mais cela introduit un énorme biais dans l'intelligence, c'est ton analyse qui déterminera beaucoup de choses. La troisième couche, ben.... à toi de choisir le système de décision, un système expert (ensemble de règles dont l'ordonnancement est déterminé par apprentissage) ça peut être pas mal pour un début (un système de but par fonction objectif globale ne te mènera à rien d'intéressant, il n'y aura aucune "intelligence"). Et la 4ème couche ? À peu près comme la seconde plus la première, dans l'autre sens.

Si tu sépares bien tes couches, tu pourra quand tu aura un résultat changer le contenu de l'une d'elle indépendamment des autres pour améliorer ton robot. C'est pas forcément évident à faire au début mais tu y gagnera beaucoup plus tard.

Enfin, un des problèmes à résoudre c'est comment partager le temps d'exécution de ton proc entre les différentes couches. Si tu peut faire un thread ou un processus par couche, ce sera bien. (Je n'y connait rien en robotique, je ne sais pas ce qu'il est possible de faire au niveau du multithreading, mais presque tout les langages gèrent ça maintenant en info, donc j'imagine que ça devrait pas être un problème).

Et pour finir, le dernier problème : comment vas tu faire communiquer tes couches entre elles ? Un système de mémoire des résultats internes des couches, écrites par la couche n et lus par la couche n+1, me parait pas mal, mais y'a certainement d'autres solutions.

Bon courage, y'a du taf....

Bon, c'est moi qui raccroche le wagon.

J'ai repensé au problème exposé ici et je l'ai formulé ainsi :

Pensée :
Qu'est ce que la pensée ?
Est-ce juste une voix qu'on entends dans sa tête et qui précède (parfois) ce que l'on dit ?
Est-ce simplement un mécanisme constructif des idées ? Est-ce plus complexe que cela ?

Mots :
Quel est le rôle d'un mot, dans le mécanisme de la pensée ?
Est-ce LA brique élémentaire ?
Peut-on penser sans mots ?
Un mot est-il un attribut permettant l'identification, ou encore une définition qu'on associe à un sens, à une idée ? C'est uniquement ça ?

Prenons un exemple simple au sens conceptuel : une pomme. "pomme" est une référence à un objet tangible, palpable. Une construction des caractères/souvenirs de ce que constitue une pomme est une "notion de pomme". C'est une agrégation d'autres "notions" partagées (couleur rouge, texture lisse au toucher, odeur et goût sucrée, élasticité craquante sous la dent, ... des stimuli électriques classés selon leur source, leur forme ?) en une situation précise, celle de la présence de l'objet "une pomme". Le mot sera entendu, puis associé à cette agrégation. Et ce mot reviendra à chaque fois qu'on pensera à cette agrégation. Le mot est-il donc une clé primaire de cette agrégation, de ce concept ? Une idée manipulable de manière unitaire, sans faire appel à l'ensemble des concepts, mais en les gardant à porté en cas de besoin ?

À la relecture de ce fil, j'ai envie d'ajouter les points suivants à la nouvelle ébauche que je viens de reproduire ici.
Effectivement, il faut associer également aux stimuli ressentis des actions correspondantes : la notion de "texture lisse au toucher", ça va avec l'idée de saisir l'objet. Donc l'idée action/ressenti, au lieu de l'idée ressenti.
Effectivement aussi, le mot semble n'être que complémentaire de l'agrégation d'idées action/ressenti qui devrait être réalisée par la machine. Mais si le mot ne vient qu'après la construction de l'agrégation, comment évaluer extérieurement cet apprentissage tant que le mot (clé primaire ?) n'est pas appris ? Est-ce faisable seulement par l'observation extérieure des connections réalisées, jusqu'à un point de complexité ou le mot devient possible ? En fait, plus j'y pense, plus je pense que oui.

Maintenant, ce qui ne me paraît plus si important ni compliqué que ça, c'est tous les modules dont je parlais. Finalement, si on cherche à réaliser une vrai "intelligence" indépendante, est-ce que ces modules ne vont pas tous se décomposer en stimuli/actions et en la construction d'associations entre nœuds conceptuels initialement vierges, comme je suppose que le fait un enfant humain ? Par exemple, la couleur rouge. Est-ce que le concept couleur rouge ne va pas simplement venir de la corrélation trouvée entre les représentations machines de deux images perçues contenant du rouge ? Est-il nécessaire d'écrire un module spécifique pour coder cela, ou celui-ci est-il "appris" simplement en suivant les recherches de similarités ? Est-ce que ce n'est pas cela la clé pour gagner encore un niveau d'abstraction du mécanisme de la pensée, par rapport au paradigme des mots/briques unitaires ? Est-ce que ça marcherais avec tous les modules dont on à parlées avant ? (par exemple l'idée/mot "politique", ça se construirait une fois les mots de base appris, sur des agrégations ayant déjà associées un mot, justement.)

La machine associée devra effectivement disposer de plusieurs interfaces avec le monde extérieur.
-Confort/douleur : niveau de batterie faible = douleur ?
-Vue : pas lue comme une vidéo, lue plutôt en cercles concentriques à partir du centre d'une image capturée (grandissants jusqu'à ce que l'attention soit relâchée ?) sous forme de stimuli élémentaires RGB ?

-et déplacement physique et orientation de "l'œil", toujours selon des mouvements chiffrés ;

-Toucher : l'action, donc un bras/main articulé ?

-et sensation tactiles (codées numériquement, résistance chiffrée sur une durée déterminée, puis grilles plus complexes quand la coordination chiffre de commande de la main/mouvement de la main apparaitra ?

-Odorat et gout ? Est-ce nécessaire ?
-Ouïe : retranscrite en sons (durée, hauteur, longueur et timbre(sinusoïdale complexe, mais ce n'est pas le plus utile à décrypter pour l'apprentissage), sont des données purement chiffrables qui définissent totalement un son). Coder une augmentation du stimuli douleur pour les volumes trop forts peut s'avérer utile...

-et haut parleur.

Voilà pour les modules purement "physiques", auxquels j'ajouterai néanmoins, et ce dans un registre totalement "physique" au sens de la machine aussi.
-une ligne de commande ?

-avec des commandes actions directes sur ses données internes, dans un premier temps
-avec une possibilité de module de dialogue formel, quand on jugera bon d'intégrer des mots sous forme informatique directement sur des concepts ? Est-ce que ce sera nécessaire ? Est-ce que ce sera intéressant en terme de développement ?

Au niveau "cérébral": une structure de développement de connaissances permettant
-la détection de similarité dans des stimuli/actions indépendants ou croisés
-l'enregistrement (création de nœuds identifiants ces similarités pluri-stimuli/actions) lors de ces détections
-un mécanisme de renforcement de ces nœuds lors de leur redétection
-un mécanisme d'oubli progressif si ceux-ci ne sont jamais redétectés
-un mécanisme d'agrégation/généralisation de ces nœuds par similarités entre eux
-un mécanisme de correction ?


Bon, dernier point, je n'ai pas (et n'aurais probablement jamais) la machine qui me permettrai de faire ça, et je n'y connait rien en robotique (d'ailleurs, est-ce nécessaire de donner corps, ou est-ce que l'extraction de donnée accessibles massivement sur internet ne serait pas suffisant ?), mais l'aspect logiciel/intelligence qui est derrière est mon domaine de compétence et m'intéresse particulièrement (et la programmation des filtres tels que celui de l'œil que j'ai décrit, c'est je pense une peccadille). Je pense que j'essaierai de mettre en place un tel système un jour ou j'aurais le temps, donc toute piste d'analyse ou commentaire à ce propos m'intéresse.

L'intelligence artificielle ne se limite pas à la simulation de l'intelligence humaine. C'est un peu le graal. Si certains projets essaient de simuler un comportement qui y ressemble, la plupart d'entre eux s'intéressent profondément à des sous problèmes liés à l'intelligence (prise de décision, résolution de problèmes, représentation des information - les bases de données, par exemple, est un champ applicatif issu de la recherche en IA, logiques floues, systèmes multi-agents et programmation distribuée, etc...).

La pensée de l'homme est celle que l'on comprends le mieux, mais il existe d'autres formes d'intelligence auxquelles nous n'avons pas forcément accès. Personnellement, j'aurais tendance à penser que ce qu'on transpose sur un chien (ou un autre animal), c'est un antropomorphisme de notre propre fonctionnement (ce qui donne l'impression de transcender ses réactions, mais en fait on en est loin). Dans cette optique là, même si ça reste un sujet intéressant, ça ne l'est pas forcément vis a vis de l'objectif à long therme de l'intelligence humaine. Pourtant, c'est bien ce qui est fait (regarde le développement commercial des robots chiens, par exemple).

Ce qui se discute sur cette section du forum, en revanche, c'est la vision globaliste du problème (qui s'oppose à la vision constructiviste, i.e. l'agglomération des sous problèmes résolus individuellement). Les différentes approches sont complémentaires

Le fait est que l'on peut penser sans formuler de mots (les animaux comme tu dit le font très bien) mais en l'occurence, entre humain, dans nos interractions entre nous et dans celles que l'on souhaiterait avec les machines "parlantes", on utilise des mots comme éléments unitaires. Savons nous encore communiquer sans mots ? Savons nous encore organiser nos idées, faire une déduction, sans mots ?

Même s'il y a un mécanisme intrinsèque (pas conscient*) derrière notre formulation de pensée (en mots) je pense que le mot est déjà un bon début de brique unitaire pour faire une machine "parlante", ou plus précisément l'idée qui est derrière le mot (le mot est interchangable - quand on passe d'une langue à l'autre, pas l'idée qu'il représente).

Quand au fait d'avoir la capacité d'être acteur sur le monde, des bras, c'est un plus, mais parler est déjà une action. Est-elle suffisante à elle-même comme action sur le monde extérieur pour un apprentissage d'une représentation complete de ce monde est une bonne question.

* = Je pense que c'est là un nœud du problème, quel est exactement ce mécanisme ? C'est celui là qu'il faut coder en dur. Tout le reste, (les briques élémentaires sémantiques, les règles grammaticales, les règles sociales, etc...), doit pouvoir être appris (l'autre nœud du problème), si on veut pouvoir parler d'intelligence...

Bonjour,

Je me demandais : quelles méthodes utilisez-vous pour apprendre à vos robots ? J'ai fait très peu de robotique, aussi tout ce qui suit est purement théorique... En voulant faire des robots qui apprennent, il me semble qu'on essaye de reproduire la façon dont nous humains avons appris : répétition des gestes, unicité de l'apprentissage (une tâche à la fois), etc. C'est à la fois relativement puissant et très long (on est majeur à 18 ans !). Si on veut réduire le temps d'apprentissage d'un robot, il me semble qu'il faut inventer une nouvelle pédagogie plus adaptée. Dans ma tête ça passe par l'utilisation d'un simulateur pour démultiplier les expériences du monde réel et accélérer l'apprentissage.

Par ailleurs, je ne sais pas si je dis une hérésie, mais je me demande toujours si ce ne serait pas plus pratique de mettre à l'extérieur du robot toute la partie calcul, et relier "l'âme et le corps" par wifi ou affilié. Les processeurs actuels ne sont pas si puissants que ça, et pour le travail sur l'intelligence artificielle, tout se passe en labo, donc la dépendance au wifi ne serait pas pénalisante.

Personnellement, je n'ai pas de robots, je m'intéresse à l'aspect programmation pure. Donc je ne connait pas les capacités de l'embarqué et je pense de toute façon à un controle par ondes, comme tu dit.

Pour l'autre question, oui, l'apprentissage est long et on pense en général à un apprentissage par l'expérience. Mais une machine peut être dupliquée, une fois l'apprentissage effectué. Il suffit de recopier les données de l'apprentissage (plus ou moins une petite période d'adaptation, car aucune machine n'est physiquement absolument identique). Quand à une pédagogie plus appliquée, de toute facon la pédagodie utilisée va déjà être faite en fonction du type de capacité d'apprentissage qu'on donne à la machine, c'est donc déjà plus ou moins ce qui est fait au cas par cas.

Et si les briques unitaires du sens d'un mot abstrait étaient les mots et le sens complet de ces mots une phrase ou un ensemble de phrases ?
On a déjà des briques unitaires pour le sens de certains mots concrets (par exemple la couleur, ce serait entre autres codage RGB, le verbe etre ce serait un codage d'appartenance à ).
On a la logique mathématique comme agrégant...
La "pensée" serait elle alors une modélisation de certains sens, suivant un modèle logique, représentant un arbre sémantique (ou une structure similaire), construit avec des sens choisi au hasard parmis ceux connus ? Aisni que la déduction d'une nouvelle connaissance ou un ajustement de ces connaissances ?

exemple:
"droite" "ensemble de points alignés"
"segment" "ensemble de points alignés"
"point" "intersection de deux droites"

Une recherche de similitudes dans les définitions pourrait donner :

machine : "droite egal segment ?"
humain : "droite etre infini"
humain : "segment etre fini"

-> création de "fini" et "infini", vierges de sens, ajout de ;"infini" dans droite et de ;"fini" dans segment

machine : "fini ?"
humain : "avoir fin"
machine "infini ?"
humain : "non avoir fin"

-> création des champs sens de fini et infini, détection de l'opposition entre les deux (pour peu que le sens de "non" soit connu)

machine : "droite non egal segment"
humain : "oui"

-> ajout de "non egal segment" a droite et de "non egal droite" a segment

machine : "droite egal ensemble de point alignés infinis ?"
humain : "droite egal esemble infini de points alignés"

-> transformation des 2 premières propriétés connues de la droite en une seule, selon la formule donnée par l"humain, rappel de similarité entre droite et segment :

machine : "segment egal ensemble fini de points alignés ?"
humain : "oui"

-> transformation des 2 premières propriétés connues du segment en une seule ...

Alors, ça ressemble à de la "pensée" ?

Effectivement, la question de la brique unitaire se pose.
Le mot est un choix arbitraire. Est il suffisamment élémentaire pour qu'un sens puisse y être associé ? (Sur ce point là, les asiatiques ont peut être une facilité par rapport à nous, avec leurs sinogrammes associés à des idées et leur phrases sans accords ni conjugaisons.)

On pourrai effectivement choisir la lettre comme élément unitaire, et les groupes de lettre représentant des mots appris par la machine par répétition (dans un dialogue textuel avec la machine). L'apprentissage de la grammaire serait peut être plus facile, à moyen terme, vu que les accords seraient intégrés à l'apprentissage dès le premier niveau d'aggrégation "apprise" (le mot).

L'exemple de l'écriture chinoise me donne a penser que le mot serait suffisemment unitaire, à la condition d'écrire et de lire sans accorder ni conjuguer, ce qui serait suffisant pour tester une capacité d'apprentissage du sens. Après, si on veut passer à une machine qui apprends le sens ET lit/écrit correctement, il faudra passer par l'unité lettre, mais c'est déjà un exercice plus compliqué en terme d'apprentissage pour la machine.

Il y a aussi le problème du ressentit, comme tu dit, et des autres organes. Mais dans un premier temps, je pense que je tenterais de me concentrer sur une machine n'ayant comme entrées que quelques senseurs (contacts, accéléromètres, flux texte) et comme sorties quelques éléments de base (flux texte, 2/3 moteurs pour le déplacement, un bras, une pince). Juste de quoi modéliser la sémantique et son apprentissage. Si une telle machine était capable d'apprendre le sens des mots, alors nul doute qu'une plus complexe en organes pourra le faire sous condition de ressources mémoire/temps suffisantes.

La question qui se pose alors est celle de la structure minimaliste de senseurs/moteurs à associer à ses capacités cognitives (mémoire/programme) pour que la machine puisse trouver un intérêt à l'apprentissage (une fonction objectif). Peut être une maximisation des variations énergétiques de sa pile... qui le pousserait à se charger puis se décharger rapidement, avec un bonus pour la longueur de ce cyle... Mais dans tout les cas, il faudra passer par une phase d'apprentissage de la capacité à aller se charger, paf, voilà un module...



Dans un autre ordre d'idée, il est a noter que les mathématiques, qui décrivent les propriétés abstraites de l'univers, ont fait de la "logique" la branche des mathématiques qui décrit les mathématiques. Pourrait on donc s'inspirer de la "logique" pour déterminer une base dans la modélisation de l'apprentissage des différents sous systèmes associés à la représentation du sens dans une IA ? (Attention, je ne parle pas d'utiliser la logique comme LE module sémantique — ce que font déjà certains chatterbots —, mais d'utiliser quelques éléments fondamentaux de la logique — comme le modus-ponens — pour construire des modules allant bien au dela de la logique. Utiliser la logique à un niveau méta, en quelque sorte, sans tomber dans son utilisation habituelle en IA, directement au niveau applicatif)

Bonjour,

Je n'y connait rien en robotique, mais je m'y connait en IA, et plus généralement en langages de programmations.
J'ai un faible pour le langage python (que je trouve extrèmement puissant, polyvalent, extrèmement simple d'utilisation et multiplateformes, tout en étant beaucoup plus léger le mastodonte java) pour ce qui est de la programmation.
Est il aisé de controler un robot avec un code en python (des interfaces python/machine(senseurs/activateurs) existent elles déjà) ?
Des projets de robotique codés en python existent ils déjà ?

Bon, et une dernière interrogation maintenant :

Ayant défini une liste de modules nécessiares à une intelligence a peu près complète, comment faire pour que ces modules soient appris (un apprentissage de la machine) et non pas innés (définis par un programeur) ? Quelles sont les éléments unitaires possibles/nécessaires de ces module et comment leur agencement peut définir le "contenu sémantique" de ces modules ?

Voilà, c'est comme ça que je tenterais de créer une IA si j'en avais le projet. Vous en pensez quoi ?

C'est bien ma question : qu'est ce que le "sens" d'un mot ?
-Pour un opératuer mathématique, c'est une notion rattachée à un espace mathématique ;
-pour une couleur, c'est une notion rattachée à un espace de représentation de l'environnement, (une proximité avec une représentation numérique d'une couleur repère) ;
-pour le ciel, c'est une notion rattachée à un lieu (de nouveau un élément particulier de représentation de l'environnement)...
mais la liste est longue.

Comment décrire le sens des mots "paradigme", "interface", "politique", quel module spécialisé y associer, et quelles grammaires dans ces module utiliser pour représenter ces notions particulière ?
C'est cette liste que je voudrais commencer à établir. (Je parle d'une IA générale, celle qu'on s'attendrait à trouver dans un robot humanoide multifonctionnel , le chatterbot n'étais qu'un exemple basique pour illustrer le début de mon propos.)

Salut,

Pour faire une IA capable de langage naturel, je pense que la clef du problème est le fait de faire intégrer à cette IA non pas du vocabulaire et des règles grammaticales, mais quelque chose qui correspond à une représentation du sens de ces mots. Et pas une représentation textuelle, mais une représentation "machine".

Dans un chatterbot, par exemple, j'immagine qu'il est possible de modéliser le vocabulaire et les liens logiques entre certains mots (traités comme des prédicats en logique, comme le ferait un moteur d'inférence). Cependant, tant que la machine n'appréhende pas d'une manière ou d'une autre la sens des mots qu'elle manipule, on tombera sur des syllogismes.

Il est certainement possible, par exemple dans une base de données contenant la correspondance mot/sens dans une table, de coder un sens a certains mots appartenants au registre mathématique, si le programme est doté d'un module représentant une part de la logique mathématique dans un langage formel. (par exmeple le sens du verbe "être égal" serait lié à la représentation mathématique du = dans le modèle mathématique formel, de même que le groupe sémantique "est un" serait représenté par l'inclusion à un ensemble). Dans un texte mathématique lu en langage naturel, un moteur de cohérence générale traduirait la compréhension du sens du texte dans le contexte foormel mathématique, et on pourrait parler alors de compréhension du sens.

Cependant, pour un texte descriptif, ou un texte manipulant des notions abstraite, ou phylosophiques, ce système ne serait pas suffisant.

La question quime tarraude est donc la suivante :
Quels modules, à part le moteur générique d'analyse du sens qui lie le tout, un moteur d'inférence logique, une grammaire formelle mathématique, une grammaire ensembliste, une module de représentation du monde physique (et des "organes" associés), seraient nécessiaires pour que l'intelligence soit complète ?

Est ce que l'attachement que je porte à la notion de sens dans le contexte du développement d'une IA vous parrait cohérent ?

À vos ardoises !

En fait, je pense que ca ne donnerai rien :aum ieux ce système permettrait d'apprendre le sens de certains verbes, et d'apprendre peut être partiellement une grammaire, mais il n'apprends pas plus le sens de la pluspart des mot. C'est je pense le point crucial : que la machine puisse appréhender le sens des mots, pour faire une IA.

Bon, en reposant à plat, ça donne ça :

La structure des tables me parait bien. La certitude bornée entre 0 et 5 compris. Quand une phrase est entrée elle commence avec une certitude de 2.

Des entrées possible pour débuter l'apprentissage seraient :

verbe être mot
être être mot
être être verbe
sujet être mot
...

Je fais le choix de parler sans conjugaison ni articles volontairement, puisque le systèeme apprends tout juste la grammaire. On commence par simple.

Le déroulement que j'immagine maintenant avec ces entrées est le suivant :

"verbe être mot" est stoqué dans la table vocabulaire, avec une certitude de 2, comme toute entrée par défaut. Puis on lance un module de recherche de cohérence, qui compare les données des tables (mettons 10 données ayant un lboc de lettre consécutif en commun, en commençant par chercher dans les tables + complexes) avec la nouvelle phrase. Il n'a rien a faire.

"être être mot" est stoqué de la même manière. La recherche de cohérence se trouve avec 2 mots similaires contenants des espaces. Elle détecte que les contenus après le premier espace sont identiques, elle tente une cohérentisation de la chose :
dans la table vocabulaire :
"verbe être mot" prends -1 en certitude (sauf si ça le fait passer à zero)
"être être mot" prends -1 en certitude (sauf si ça le fait passer à zero)
"verbe", "être", "être mot" sont créés comme mots de note 1
dans la table sens :
"être mot" est créé avec la certitude 2 et l'arité 1.
dans la table instance :
"être mot", "verbe", 2
"être mot", "être", 2
tout ça est une étape, un cycle de cohérence, il y a 10 cycles a passer comme ça.

le résultat du second cycle pourrait être :
vocabulaire :
"verbe", "être", "mot", "verbe être mot", "être être mot", "être mot", tout à 1
sens :
"être mot" à 1, "être" à 2 (par comparaison entre "être mot" et "être") avec une arité de 2 ?
Instance :
...

puis les autres cycles ne font rien, y'a plus rien a déduire.
et on continue avec "être être verbe"...


Voilà, si quelqu'un veut coder ça pour essayer de voir ce que ça donnerait