This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
scenario-lum [2025/12/08 07:28] 47.128.44.20 old revision restored (2025/11/19 19:54) |
scenario-lum [2025/12/11 17:11] (current) 47.128.56.207 old revision restored (2025/10/23 17:22) |
||
|---|---|---|---|
| Line 136: | Line 136: | ||
| à dire le seuil qui leur fait dire si oui ou non deux instances sont similaires. | à dire le seuil qui leur fait dire si oui ou non deux instances sont similaires. | ||
| - | === Couple Association Similarité (A-S) === | + | === Couple Association Similarité (A-S) === |
| + | |||
| + | <note important> | ||
| + | Le fonctionnement des agents Association décrit | ||
| + | dans cette section n'est pas celui décrit dans la | ||
| + | thèse de Mazac, mais plutôt une interprétation. | ||
| + | Pour moi ils devraient fonctionner comme suit, mais | ||
| + | la discussion reste ouverte. | ||
| + | </ | ||
| Déterminer l' | Déterminer l' | ||
| Line 175: | Line 183: | ||
| </ | </ | ||
| - | === L' | + | ==== L' |
| A partir des éléments de la section précédente, | A partir des éléments de la section précédente, | ||
| Line 202: | Line 210: | ||
| **Exploiteurs**. | **Exploiteurs**. | ||
| - | == Les explorateurs == | + | === Les explorateurs |
| Comme leurs nom l' | Comme leurs nom l' | ||
| Line 216: | Line 224: | ||
| l' | l' | ||
| - | == Les exploiteurs == | + | === Les exploiteurs |
| Ce type de couple se fixe sur les emplacements les plus | Ce type de couple se fixe sur les emplacements les plus | ||
| Line 227: | Line 235: | ||
| un emplacement. | un emplacement. | ||
| - | === Feedback d' | + | ==== Feedback d' |
| Dans la section précédente nous avons parlé du marquage | Dans la section précédente nous avons parlé du marquage | ||
| Line 237: | Line 245: | ||
| correspondant à la variable et aux paramètres des agents. | correspondant à la variable et aux paramètres des agents. | ||
| - | < | + | === L' |
| - | L' | + | |
| - | D-S et A-S. | + | |
| - | </ | + | |
| - | + | ||
| - | == L' | + | |
| Une découpe de variable, ou une association de flux, est évalué sur | Une découpe de variable, ou une association de flux, est évalué sur | ||
| Line 264: | Line 267: | ||
| évènement. | évènement. | ||
| - | == L' | + | === L' |
| Pour nuancer le poids de l' | Pour nuancer le poids de l' | ||
| Line 287: | Line 290: | ||
| <note tip> | <note tip> | ||
| - | Un autre facteur pouvant être pris en compte est la "direction" | + | Concernant les motifs |
| - | lors d'une association entre un flux interne et un flux externe. | + | |
| - | Pour éviter qu'un même motif soit appris par plusieurs | + | Une certaine redondance de l'apprentissage se retrouve lors de la |
| - | entre eux. | + | découverte de motifs dit " |
| + | en jeux plusieurs systèmes, donc des associations entre un flux | ||
| + | interne et un flux externe. Un même motif peut potentiellement | ||
| + | être appris | ||
| - | En partant | + | Exemple (en restant |
| - | l'émission d'une instance | + | le store m' |
| - | cette instance par un autre système, nous pouvons dire qu'il serait | + | associant les deux), je capte une augmentation |
| - | plus pertinent | + | que je communique aussi. L' |
| - | dont il peut avertir | + | l'augmentation de la luminosité (e2) est faite par les deux systèmes et |
| + | les deux systèmes créent des flux correspondant à cette association, | ||
| + | y a donc redondance. | ||
| + | |||
| + | Cette redondance est elle un mal ? | ||
| + | |||
| + | Doit-on utiliser cette redondance à notre avantage et l'utiliser | ||
| + | pour faire un consensus sur des motifs communs à certains objet ? | ||
| + | Si oui comment détecter qu'un même motif a été découvert par deux | ||
| + | systèmes différents | ||
| + | décider lequels des systèmes aura pour rôle de notifier les autres | ||
| + | des instances de ce motif ? | ||
| + | |||
| + | D'un autre point de vue, cette redondance est elle nécessaire ? | ||
| + | |||
| + | Ne pourait on pas faire en sorte " | ||
| + | pour qu'un minimum de système, au mieux un seul, découvre ce motif ? | ||
| + | |||
| + | Personellement je penche | ||
| + | pourrions par exemple donner plus d' | ||
| + | ou d' | ||
| + | interne. | ||
| + | |||
| + | Pour reprendre l' | ||
| + | luminosité", | ||
| + | et d'un flux externe pour le store. L' | ||
| + | être exploité par le système | ||
| + | |||
| + | Partir sur ce principe permettrait | ||
| + | complexe, c'est à dire mettant en jeu plusieurs avatars. | ||
| + | |||
| + | De plus vérifier | ||
| + | (avis personnel), quand bien même qu' | ||
| + | longue phase vérification, | ||
| + | véracité d'un motif, juste de regarder si il leur est utile ou non. De plus les systèmes | ||
| + | ont les mêmes capacités d' | ||
| + | leur de l' | ||
| + | de synchronisation entre eux). | ||
| - | remarque : prendre en compte ce facteur permettrait certes de réduire | ||
| - | la redondance mais risque de renforcer l' | ||
| - | cependant ce types de motifs sont surement plus facilement indentifiable | ||
| - | que des redondances de motifs. | ||
| </ | </ | ||
| - | == Calcul du feedback == | + | === Calcul du feedback |
| - | Le feedback d' | + | Le feedback d' |
| de son intérêt intrapersonnel **Ί< | de son intérêt intrapersonnel **Ί< | ||
| **Ί< | **Ί< | ||
| Line 331: | Line 369: | ||
| </ | </ | ||
| - | == Feedback Prédictif == | + | < |
| + | Cette formule d' | ||
| + | D-S ou A-S, puisque pour l' | ||
| + | |||
| + | Ίε(e) = (Nb_Var_Necessary(e) + 1) - Nb_Internal_Var_Used(e) | ||
| + | = 1 + 1 - 1 = 1. | ||
| + | |||
| + | => Ί(e) = Ία(e) = s(e) * π(e) | ||
| + | |||
| + | avec p(e) = 1. | ||
| + | |||
| + | Donc nous retrouvons la formule proposée par Mazac | ||
| + | </ | ||
| + | |||
| + | === Feedback Prédictif | ||
| Lorsqu' | Lorsqu' | ||
| Line 343: | Line 395: | ||
| fréquence d' | fréquence d' | ||
| et d'une confiance **rel**, qui est le rapport de prédictions juste sur | et d'une confiance **rel**, qui est le rapport de prédictions juste sur | ||
| - | le nombre de prédiction | + | le nombre de prédictions |
| < | < | ||
| Line 386: | Line 438: | ||
| </ | </ | ||
| + | ==== Flux d' | ||
| + | Lorsqu' | ||
| + | ou A-S, est déterminé comme " | ||
| + | correspondant au concept d' | ||
| + | les instances de ce concept (c'est à dire les instances similaires | ||
| + | au concept d' | ||
| + | === Identification === | ||
| + | Du point de vue d'un système, et donc de ses agents, un flux est perçu | ||
| + | comme un **flux interne** si celui-ci a été créé par le système, et | ||
| + | comme un **flux externe** si il a été créé par un autre système. | ||
| + | < | ||
| + | Par exemple : | ||
| + | Du point de vue du système d' | ||
| + | aux concepts : augmentation soudaine de la luminosité, | ||
| + | augmentation progressive de la luminosité, | ||
| + | interrupteur passe à ON, interrupteur passe à OFF, etc... seront perçus | ||
| + | comme des **flux interne** car créé par le système d' | ||
| - | ====== | + | A l' |
| + | se ferme; seront perçu comme des **flux externes**. | ||
| + | </ | ||
| - | + | Pour aider à l'identification | |
| - | + | est associé au flux URI du système l'ayant créé | |
| - | == Création de Flux == | + | et l'URI du concept |
| - | + | agents | |
| - | La découverte d' | + | |
| - | d' | + | |
| - | ses paramètres de découpe et l' | + | |
| - | ses paramètres de différenciation, les deux en fonction de la | + | |
| - | variable d'entrée à laquelle ils sont associés. | + | |
| - | + | ||
| - | La qualité des paramètres, | + | |
| - | est sauvegardé dans un **espace de marquage** à trois dimensions | + | |
| - | (la variable sélectionné, | + | |
| - | les paramètres | + | |
| - | + | ||
| - | Cet espace de marque sert à garder, dans un espace commun de recherche | + | |
| - | de paramètres à tous les couples d' | + | |
| - | certains paramètres | + | |
| - | + | ||
| - | {{wiki: | + | |
| - | + | ||
| - | Une fois qu'un couple, ou plutôt | + | |
| - | aura déterminé qu'un //concept | + | |
| - | un //flux d' | + | |
| - | correspondants | + | |
| - | les agents Association du système | + | |
| - | Association des autres systèmes d' | + | |
| - | + | ||
| - | {{wiki: | + | |
| - | + | ||
| - | + | ||
| - | Pour connaitre la similarité, | + | |
| - | instances | + | |
| - | histogrammes représentants les instances. | + | |
| - | + | ||
| - | {{wiki: | + | |
| - | + | ||
| - | === Partage d' | + | |
| - | + | ||
| - | A peu près même moment que le système | + | |
| - | créé ses //flux d' | + | |
| - | leur apparitions. | + | |
| - | + | ||
| - | Une notation possible est présentée ci-dessous. Noté **F**, un flux est | + | |
| - | identifié par l' | + | |
| - | De la même manière sont notés **e** les //concepts d' | + | |
| - | à un flux, il sont donc identifiés de la même manière que les flux, avec | + | |
| - | id et ip. | + | |
| {{wiki: | {{wiki: | ||
| - | |||
| - | Pour simplifier la notation pour le scénario, l'ip du système d' | ||
| - | sera 1 et l'ip du store électrique sera 2. L'ip 0 est considéré comme un | ||
| - | " | ||
| - | le fait de donner un ip 0 pour identifié le " | ||
| - | arbitraire, un flux pourrait garder l'ip de l' | ||
| - | les agents du système d' | ||
| - | devraient être capables de différencier les flux personnels et les flux | ||
| - | extérieurs. | ||
| - | |||
| - | Ainsi le système d' | ||
| - | des flux d' | ||
| - | // | ||
| - | |||
| - | Les couples d' | ||
| - | alors rechercher différentes Association de concepts d' | ||
| - | et pertinents. | ||
| - | |||
| - | {{wiki: | ||
| - | |||
| - | Les Associations vont être faites en prenant prioritairement en références | ||
| - | les flux internes du système d' | ||
| - | l' | ||
| - | dans tous les avatars de la société, et permet aussi une spécialisation | ||
| - | de ces mêmes avatars. En effet, les avatars d' | ||
| - | capteurs et d' | ||
| - | provenant de flux externes; à l' | ||
| - | de capteurs et d' | ||
| - | le découpage de leur variables d' | ||
| - | " | ||
| - | |||
| - | ==== Point de vue du store électrique (Orienté Scénario) ==== | ||
| - | |||
| - | Dans le point de vue précédent, | ||
| - | globale du modèle. De ce point de vue, au contraire, nous allons nous | ||
| - | concentré, pas à pas, sur les suites logiques d' | ||
| - | à un système d' | ||
| - | |||
| - | === Variables d' | ||
| - | |||
| - | Reprenons à partir de la découpe d'une variable d' | ||
| - | par exemple V< | ||
| - | |||
| - | {{wiki: | ||
| - | |||
| - | == Couple Découper - Similarité (D-S) == | ||
| - | |||
| - | L' | ||
| - | d' | ||
| - | interactions, | ||
| - | permet de connaître la " | ||
| - | d'une variable en particulier. Ils font varier leurs | ||
| - | paramètres en explorant l' | ||
| - | |||
| - | == Découpe == | ||
| - | |||
| - | L' | ||
| - | a pour paramètre un Δt qui est la taille de la fenêtre de découpe. | ||
| - | |||
| - | {{wiki: | ||
| - | |||
| - | L' | ||
| - | " | ||
| - | peut être simplement glissante, ou bien glissante et suivant les | ||
| - | variations de la variable d' | ||
| - | |||
| - | La portion découpée par l' | ||
| - | la forme d'un histogramme. | ||
| - | |||
| - | == Similarité et Différenciation == | ||
| - | |||
| - | Les histogrammes produit par l' | ||
| - | par l' | ||
| - | |||
| - | Celui ci compare les nouvelles instances d' | ||
| - | a stocké précédemment, | ||
| - | de chaque groupe d' | ||
| - | comme un pré-concept d' | ||
| - | |||
| - | La fonction de comparaison utilisée pour différencier les instances découpées | ||
| - | en une fonction d' | ||
| - | instances. | ||
| - | |||
| - | {{wiki: | ||
| - | |||
| - | Ainsi l' | ||
| - | d' | ||
| - | même la moyenne de ce groupe d' | ||
| - | une instance, alors un nouveau lui correspondant sera créé. | ||
| < | < | ||
| - | le paramètre de l'agent Similarité serait son seuil d' | + | TODO : mettre à jour l'image quand une notation aura été définie. |
| - | de similarité, | + | |
| </ | </ | ||
| - | == Feedback et sélection de concept | + | === API de transfert |
| - | + | ||
| - | Avant que la moyenne d'un groupe d' | + | |
| - | concept d' | + | |
| - | de chaque pré-concept, | + | |
| - | marquage des couple D-S. | + | |
| - | + | ||
| - | Le feedback | + | |
| - | spécificité de cet évènement, | + | |
| - | de la redondance de cet évènement. Pour faire simple, parmi tous les évènements | + | |
| - | " | + | |
| - | donc potentiellement le moins dû au hasard. | + | |
| - | + | ||
| - | < | + | |
| - | + | ||
| - | intérêt | + | |
| - | + | ||
| - | </ | + | |
| - | + | ||
| - | C'est lorsqu' | + | |
| - | de marquage, sur les paramètres de découpe de V< | + | |
| - | Flux d' | + | |
| - | + | ||
| - | == Conception de flux d' | + | |
| <note important> | <note important> | ||
| Le fonctionnement de l'API de flux n'est, pour le moment, pas clairement | Le fonctionnement de l'API de flux n'est, pour le moment, pas clairement | ||
| - | définie. | + | définie. Ce qui est écrit dans cette section sont des idées sur le fonctionnement |
| + | général de l'API et sur l' | ||
| + | existant pour les besoins du système d' | ||
| </ | </ | ||
| - | Comme dit précédemment, | + | == Fonctionnement hypothétique == |
| - | des //concepts d' | + | |
| - | Ces flux pourraient correspondre à des flux RSS (ou tout autre outils permettant | + | |
| - | le partage d'un "fil d' | + | |
| - | Similarité du couple associé, à chaque fois que l' | + | |
| - | nouvelle //instance d' | + | |
| - | du flux. | + | |
| - | Supposons qu' | + | Si nous prenons le point de vue d'un avatar, le principe des flux |
| - | créés. | + | reviens |
| + | avatars de la société. | ||
| - | Il y aura donc deux flux de créé par le couple D-S affecté à cette variable | + | < |
| - | d' | + | Le mot service utilisé ici ne correspond pas forcément |
| - | du point de vue du système d'éclairage. | + | à un service web à proprement parlé, ce n'est peut être pas |
| + | le bon mot à employer. | ||
| + | </ | ||
| - | {{wiki: | + | Ainsi lorsque le système d' |
| + | à un concept d' | ||
| + | créé par l' | ||
| + | de la création du service de notification. (par la même, si un service | ||
| + | de notification est détruit, les autres avatars seront avertis de sa | ||
| + | destruction, | ||
| - | < | + | Lorsqu' |
| - | Exemple | + | son système d' |
| + | Lorsqu' | ||
| + | que l' | ||
| + | De la même manière un avatar " | ||
| + | couple A-S tente d' | ||
| - | { | + | == Protocoles, API, frameworks déjà existants == |
| - | " | + | |
| - | " | + | Pour implémenter une API permettant de mettre en place de tel fonctionnalités, |
| + | adapter certains protocole/ | ||
| + | Ci-dessous sont listés quelques API potentiels : | ||
| - | "published": "2016-01-25T12: | + | |
| + | |||
| + | Le mode de fonctionnement des [[https:// | ||
| + | plutôt bien correspondre au principe des flux d' | ||
| + | tirent leurs noms). Cependant les flux RSS ont quelque faiblesse, se sont des fichiers | ||
| + | XML où sont écrit toutes les notifications et sont accessible par tous. De plus se sont | ||
| + | les outils | ||
| + | dans le fichier XML. Ce ne sont donc pas de réelles | ||
| + | terminal (pour notre cas, d'un avatar à un avatar) et il faudrait mettre en place un | ||
| + | programme permettant de détecter la création (ou la suppression) d'un flux dans la société. | ||
| - | | + | |
| - | "@type": "Object", | + | |
| + | Le réseau [[https:// | ||
| + | de réseaux de forums permettant le partage rapide, à des groupes | ||
| + | (ou news) concernant un forum. Il utilise le protocole [[https:// | ||
| + | qui a été conçu spécialement pour le transport de news dans un réseau, il existe en version | ||
| + | "sécurisé": NNTPS. La [[https:// | ||
| + | standard des échanges de messages dans un réseau Usenet. | ||
| - | " | + | ==== Récapitulatif ===== |
| - | } | + | |
| - | " | + | Avant de passer au fonctionnement pas à pas de l' |
| - | { | + | du store électrique, |
| - | " | + | |
| - | ... | + | === Variables d' |
| - | }, | + | |
| - | { | + | |
| - | " | + | |
| - | ... | + | Les **couples D-S** vont explorer leur **espace de marquage** en y déposant l' |
| - | } | + | trouvé avec les paramètres associés. Ce marquage sert de mémoire pour retrouver |
| - | ] | + | facilement des paramètres pertinents et va aussi influencer les déplacements des |
| - | } | + | couple D-S dans l' |
| - | </ | + | |
| - | === Flux d' | + | L' |
| + | la variable d' | ||
| + | associé à cet agent **Découper**, | ||
| + | par " | ||
| + | " | ||
| + | déposé dans l' | ||
| - | Reprenons à partir du moment où tous les flux (internes et externes) | + | Une fois des " |
| - | de tous les objets de la société soient | + | des **concepts d' |
| + | l' | ||
| + | à un concept d' | ||
| - | C'est à dire : | + | {{wiki:flux_creation.png}} |
| - | * 4 flux internes correspondant à : | + | === Flux d' |
| - | * V2:1 à 1 pendant un certain temps. | + | |
| - | * V2:1 à -1 pendant un certain temps. | + | |
| - | * V2:2 augmentant progressivement de 0 à 1. | + | |
| - | * V2:2 diminuant progressivement de 1 à 0. | + | |
| - | * 6 flux externes correspondant à : | + | |
| - | * V1:1 passant de 0 à 1 instantanément. | + | |
| - | * V1:1 passant de 1 à 0 instantanément. | + | |
| - | * V1:2 passant à 1 instantanément. | + | |
| - | * V1:2 passant à 0 instantanément. | + | |
| - | * V1:2 augmentant progressivement. | + | |
| - | * V1:2 diminuant progressivement (sur plusieurs heures). | + | |
| - | == Couple Association Similarité (A-S) == | + | Le système à maintenant accès des **flux d' |
| + | lors de l' | ||
| - | Déterminer l' | + | Ces flux d'instances peuvent aussi bien être des **flux internes**, c'est à dire des |
| - | la fonction | + | flux créés |
| - | // | + | flux créés et mis à jour par d'autre système. |
| - | paramètres testés dans l'espace de marquage. | + | |
| - | == Association == | + | A partir de ces flux des **couples A-S** vont tenter d' |
| + | en regardant si ils ont l'air plus ou moins corrélés, c'est à dire si l'un arrive toujours | ||
| + | après l' | ||
| - | L'agent Association d'un couple A-S prend pour référence | + | Pour cela ils vont parcourir leur espace de marquage, ainsi l' |
| - | le flux (interne ou externe) au quel il est affecté dans | + | couple A-S prend un flux, et donc le concept d'évènement associer, comme référence et |
| - | l'espace | + | va explorer les possibilités |
| - | étant les autres flux auquel il tente d'associer son flux | + | produite par l' |
| - | de référence. | + | associé. |
| - | == Feedback d' | + | Comme pour les couples D-S, l' |
| + | de marquage. | ||
| - | Comme pour le couple D-S, l'agent Similarité récupère | + | L' |
| - | et classe | + | différents types de délai entre les deux évènements associé, est calculé à partir |
| - | L' | + | de la spécificité et la redondance de ce " |
| - | par le délai | + | du nombre de flux internes qui a entres en jeux lors de l' |
| - | pouvant bien entendu être négatif. | + | une spécificié et redondance, plus d'intérêt |
| + | flux internes, puis entre un flux interne | ||
| - | Un feedback | + | Les associations sont aussi évalué à partir de leur capacité prédictive. Et une fois |
| - | découvertes par le couple A-S. Ce feedback | + | qu'une association a été déterminé comme " |
| - | de deux intérêts : | + | fiable, alors un flux d'instance |
| + | évènement (qui est l' | ||
| + | autrui de l' | ||
| - | * L'**intérêt intrapersonnel** : | + | A partir de ce flux d'instance, autrui pourra peut être créer des associations pertinentes, |
| - | + | qui pourrons me permettre de créer | |
| - | L' | + | |
| - | pertinent pour soi, sans prendre en compte autrui. Il prend en compte | + | |
| - | la spécificité | + | |
| - | * L' | + | {{wiki:flux_association.png}} |
| - | L' | + | ===== Déroulement |
| - | pertinent pour autrui, c'est à dire qu'il plus pertinent que se soit | + | |
| - | le store qui prévienne les autres avatars | + | |
| - | Ainsi cet intérêt est calculé à partir | + | Afin de mieux comprendre le fonctionnement |
| - | dans l' | + | dans la partie précédente, illustrons le déroulement pas à pas du processus |
| - | cherche en priorité les motifs liés à ses capteurs, sans pour autant laisser | + | d' |
| - | une probabilité nulle de trouver des motifs à partir de flux externe. | + | |
| - | <note tip> | + | ==== Capteurs, |
| - | L' | + | |
| - | qu'un objet possède des capteurs et des actionneurs | + | |
| - | (ex. capteur de luminosité + ampoule, chauffage + thermomètre...). | + | |
| - | + | ||
| - | Le principe étant que les avatars créeront en priorité des associations | + | |
| - | intrapersonnelles, | + | |
| - | des concepts de plus en plus complexe, associer des motifs externes avec | + | |
| - | des motifs internes sera plus pertinent que d'associer deux motifs internes | + | |
| - | entre eux. | + | |
| + | Au départ de son apprentissage, | ||
| + | le système d' | ||
| + | ses différents capteurs et effecteurs (ses patterns sensorimoteurs). Il ne | ||
| + | connais pas encore l' | ||
| + | parti d'une société. | ||
| + | |||
| + | < | ||
| + | Ne pas confondre l' | ||
| + | d' | ||
| + | pas pour l' | ||
| </ | </ | ||
| - | L'intérêt d'une association est donc calculé | + | L'objet "store électrique" |
| + | * Un interrupteur permettant | ||
| + | * Un " | ||
| + | |||
| + | === Variations des valeurs captées dans une journée type === | ||
| - | < | + | Comme nous l' |
| - | intérêt = (intérêt égoïste) ^ alpha * (intérêt altruiste) ^ beta | + | d' |
| + | que le jour est levé. Il ferme ensuite ses stores vers 19h, lorsque le soleil | ||
| + | se couche, pour ensuite rallumer la lumière de son bureau. Rappelons que le | ||
| + | store n'es connecté à aucun objets lui permettant de connaitre la luminosité extérieur. | ||
| - | <=> intérêt | + | == Variations de l' |
| + | {{wiki: | ||
| - | Les coefficients alpha et beta sont ici pour donner plus de poids à l'une ou l' | + | == Variations |
| - | par défaut nous pouvons les considérer comme égal à 1. | + | |
| - | </ | + | {{wiki: |
| - | <note tip> | + | ==== Découverte d' |
| - | Autre possibilité : | + | |
| - | intérêt = ((spécificité + précision) ^ alpha) / ( ( 3 - nb_flux_interne ) ^ beta ) | + | Nous allons maintenant voir comment les **couples Découper-Similarité** génèrent, trient |
| + | et évaluent des instances d' | ||
| + | marquage**. | ||
| - | Le but étant que le rapport intra/inter soit, pour un même intérêt | + | === Exploration |
| - | égoïste, plus important si plus de flux interne sont mis en jeux dans | + | |
| - | l'association. | + | |
| - | </ | + | |
| - | == Prédiction et Partage == | + | Au début de son apprentissage l' |
| + | marquage. Ainsi, les couples D-S le parcourant, qui sont pour l' | ||
| + | type // | ||
| + | c'est à dire qu'ils sélectionnent leurs paramètres de manière aléatoire. Si un couple | ||
| + | D-S veut utiliser une place déjà occupée, des paramètres déjà utilisés, par un autre | ||
| + | couple D-S, alors il cherchera une autre position. | ||
| - | A partir | + | Rappellons que **l' |
| - | les couples A-S vont pouvoir tenter d' | + | à trois axes : |
| - | prédictive des paramètres ayant le plus fort intérêt. | + | * La **variable d' |
| + | * Les **paramètres des agents Découper**, | ||
| + | * Les **paramètres des agents Similarité**, c'est à dire les seuils de similarité | ||
| + | |||
| + | < | ||
| + | TODO : image/ | ||
| + | </ | ||
| - | De nouveaux flux sont alors créé pour les évènements association les plus pertinents, | + | === Découpe des variables === |
| - | donc en priorité ceux dont l' | + | |
| - | évènement externe et un évènement interne, et enfin ceux avec deux évènements externes. | + | |
| - | < | + | < |
| - | Donner un poids différents pour les associations flux externe -> flux interne et | + | En chantier |
| - | flux interne -> flux externe, permettrais d' | + | |
| - | avec un seul flux interne. | + | |
| - | + | ||
| - | Cependant, la création de motif " | + | |
| - | ces motifs " | + | |
| - | dans un apprentissage décentralisé. | + | |
| </ | </ | ||
| - | ==== Spécialisation des avatars ==== | + | Supposons la position aléatoire |
| - | + | étant variable V2:1 (l'interrupteur), fenètre de découpe | |
| - | * Les objets possédant plus ou moins de capteurs et d'actionneurs, | + | de similarité à 25%, et regardons |
| - | + | que l'apprentissage se déroule sur plusieurs semaines avec des journées identiques | |
| - | * Une fois qu'un avatar aura " | + | (bien que cela ne soit pas réaliste). Rappelons aussi que d'autres couples D-S |
| - | + | explorent | |
| - | ===== Problèmes ===== | + | |
| - | + | ||
| - | * Supposons maintenant | + | |
| - | * En plus du feedback d' | + | == Variable : V2:1, Fenètre de découpe : 1 minutes, Seuil de similarité : 25 % == |
| - | * Comment les avatars pourrait arriver, de manière émergente, à un consensus concernant un motif, pour que celui-ci soit " | + | {{v2_1_decoupe.png}} |
| - | * Comment à un niveau plus haut de l' | ||