« Arbre à focos: application » : différence entre les versions
Aller à la navigation
Aller à la recherche
Contenu ajouté Contenu supprimé
Aucun résumé des modifications |
(Contenu remplacé par « Voir assothink : [http://m3m.homelinux.org/wikiMC/index.php/Arbre_%C3%A0_focos:_application#L.27arbre_.C3.A0_foco_au_sein_de_l.27application_Assothink m3m.homelinux.org/w... ») |
||
| (9 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
Voir assothink : [http://m3m.homelinux.org/wikiMC/index.php/Arbre_%C3%A0_focos:_application#L.27arbre_.C3.A0_foco_au_sein_de_l.27application_Assothink m3m.homelinux.org/wikiMC/index.php/Arbre_%C3%A0_focos:_application#L.27arbre_.C3.A0_foco_au_sein_de_l.27application_Assothink] |
|||
= L'arbre à foco au sein de l'application Alex = |
|||
Cet article donne la partie applicative des focos dans [[Alex|Alex]]. Il répond à l'article consacré au [[Arbre à focos|volet théorique]] de l'arbre à focos. |
|||
===== Note sur l'historique d'Alex et des focos<br> ===== |
|||
L'arbre à focos est un composant d'[[Alex|Alex]] introduit dans Alex II. |
|||
Alex I était conçu autour d'un nombre fixe de consciences disponibles pour des interactions parallèles (médiocre modèle). |
|||
A partir d'Alex II, la conscience EST un arbre dynamique à focos. |
|||
Note: ''Alex I contenait'' |
|||
*''un array de consciences<br>'' |
|||
*''un array d'horizon d'excitation par conscience'' |
|||
''Ces deux arrays deviennent obsolètes et disparaissent dans Alex II.''<br> |
|||
== Conscience = arbre à focos == |
|||
D'un point de vue informatique l'arbre contient des focos, et chaque foco est matérialisé par un Thread (le foco est en java une sous-classe de la la calasse java.lang.Thread). <br> |
|||
Pour une part l'arbre se comporte comme une ''pile''. Les focos sont créés (push) et éliminés (pop) sur l'arbre un peu comme ils le seraient sur une pile. L'arbre croît et décroit dynamiquement. Le nombre de fils d'un foco est variable. Tout foco peut avoir des fils (il n'y a PAS de particularité pour des focos ''terminaux''). <br> |
|||
Dans un arbre à focos seront autorisés au minimum: |
|||
*un foco de base - la racine de l'arbre à focos, qui est un foco permanent. |
|||
*des focos téléonomiques (numériques ou autres) , à courte duré de vie, orientés vers un résultat précis |
|||
*des focos interactifs, à longue durée de vie, mais sans cible précise |
|||
===== Contributions & extensibilité ===== |
|||
Alex II offrira la possibilité de sous-classer la classe foco pour permettre des contributions externes de manière souple. Cette caractéristique essentielle du modèle doit permettre l'extension d'un groupe de développement de l'application Alex. <br> |
|||
On peut imaginer notamment: |
|||
*des focos spécialisé en décodage de pattern recognition sur (a) des lettres (b) des mots (c) des phrases (d) des formes reconnaissable (e) des sons reconnaissables... |
|||
*des focos spécialisés en tâches telle qu'émission linguistique / phonétique, repérage spatial, repérage temporel |
|||
*etc... <br> |
|||
== Focus de conscience = foco == |
|||
Les éléments de l'arbre sont des '''''focos''''' ('''fo'''cus de '''co'''nscience). |
|||
A tout moment les différents focos sont plus ou moin ''actifs, plus ou moins prioritaires'' (bien en ligne avec l'idée des Thread). |
|||
== Statut d'un foco == |
|||
Un foco peut être dans divers ''statuts'': |
|||
*''working'' : occupé à construire un résultat intermédiaire, ou actif de manière générale |
|||
*''ready'' : passif, offrant en disponibilité un ''résultat'' |
|||
*''waiting'' : passif, immobile, mais prêt à être réactivé. L'attente peut venir d'un foco fils devant produire un résultat, ou simplement d'une perte de priorité due à une urgence ailleurs dans l'arbre.<br> |
|||
*''obsolete'' : prête à être détruite, car ayant pour objet des problèmes déjà complètement traités et exploités.<br> |
|||
Les focos ont des liens les uns vers les autres, en particulier lorsqu'ils forment les composant d'un problème numérique. Ces liens forment un arborescence (pas d'anastomose!).<br> |
|||
Un foco peut être très simple (numérique 10x10) ou très complexe (interaction en logique associative avec un canal d'input). Ici la complexité peut être définie comme le nombre de nœuds présentant une état d'excitation significatif.<br> |
|||
Les focos interagissent selon un schéma de signaux, d'interruptions, de réveil (bien en ligne encore avec l'idée des Thread). <br> |
|||
== Attributs d'un foco == |
|||
Outres ses caractéristiques hérités des de Threads, et outre son statut (décrit ci-dessus), un foco sera caractérisé par:<br> |
|||
*un niveau de priorité |
|||
*un horizon de temps (utilisé dans les processus d'excitation/ érosion)<br> |
|||
*des liens avec des focos descendants (pour les focos numériques, les liens vers les focos contenant les résultats intermédiaires attendus)<br> |
|||
*un lien vers un foco créateur (à réactiver lorsque ce focos n'est plus ''working'')<br> |
|||
*une date de création<br> |
|||
*un "résultat" disponible (pour les focos téléonomiques), qui est en fait un état d'excitation stabilisé. |
|||
== Représentation de la gélatine active<br> == |
|||
Chaque foco contient sa gélatine active. Il s'agit d'un ensemble de niveau d'excitation des concepts. |
|||
Un niveau d'excitation peut être représenté par un ''float'' (réel sur 4 bytes). |
|||
Dans chaque foco, peu de concepts sont excités à un instant donné. |
|||
Beaucoup de schéma de structuration de ces données sont possibles. Les objectifs à satisfaire sont: |
|||
*rapidité de création d'un foco (allocations initiales) |
|||
*rapidité du processus de transmission des signaux d'excitation(il s'agit d'éviter les boucles trop larges).<br> |
|||
*gestion économe de la mémoire (pas trop contraignante: avec des arrays simples pour 10<sup>6</sup> nœuds-concepts, 10<sup>2</sup> focos... ~0.5 Gb). |
|||
Dans la gélatine passive, l'ensemble des nœuds-concepts est accessible à la fois en tant qu'array simple et à travers les réseaux de liens. |
|||
===== Solution implémentée ===== |
|||
La solution s'appuie sur la création initiale d'un pool de focos disponibles. L'activation d'un foco implique son rattachement à l'arbre. La désactivation d'un foco implique sont détachement de l'arbre et la réinitialisation de toutes ses excitations et paramètres. |
|||
Le foco contient un array d'excitation, coïndexal avec l'array des nœuds-concepts. Cet array est surtout utilisé pour la propagation des signaux (identification des cibles). |
|||
===== Optionnel: redondance à travers un ''topChain'' ===== |
|||
Dans chaque foco, les excitations sont aussi stockées dans un ''topChain'' pour mémoriser les nœuds-concepts actifs à tout moment, triés par état d'excitation. Seuls ces nœuds interviennent dans: |
|||
*la propagation de signaux (identification des sources)<br> |
|||
*la diminution spontanée des excitations |
|||
*la disponibilité du résultat |
|||
Cette structure implique une forme délibérée de redondance. |
|||
===== Architecture idéale massivement parallèle ===== |
|||
Bien entendu l'implémentation décrite serait inutile dans une architecture , ou chaque nœud-concept aurait son Thread autonome et concurrent, ou si, mieux encore, dans uen architecture où chaque nœud-concept aurait son processeur propre. |
|||
Ce qui est réalisé ici est une poussive tentative basée sur |
|||
*des machines disposant de peu de processeurs (1 à 8) |
|||
*un langage séquentiel object-oriented: Java |
|||