Jul a écrit 903 commentaires

PS : Ce projet est une réécriture complète d'un autre projet (vectordict) qui incluait les opérations booléennes (désormais impossible car | est utilisé pour autre chose).

La doc est plus complète et contient une API plus étendue qui inclut « les matrices creuses » qui permettent de transformer les dict en dict.

La ré-écriture, m'a permis de pouvoir livrer le cœur des fonctionnalités et d'atteindre la couverture de 99% du code.

Pardon pour la faute de frappe. Comme tu fais principalement des iterations ça me parait tout de même proche. Je connais pas bien mais la multiplication ça donnerait ça :

Genre :

mdict(a="b") * 10 
# {'x': 'bbbbbbbbbb'}

Et bien, comme je propage le + et le x selon les types natifs, ça marche comme tu le penserais avec des types pour lesquels x veut dire répéter (les strings et les tableaux).

On a bien sans surprise

resultat = {k: v * n for k, v in d.items()}

C'est un peu l'algo de base pour les 4 opérations en récursif.

Et du coup le muler hérite de l’adder (de l’héritage de mixin) ? L’héritage me parait surprenant. Si tu applique le mixin muler alors tu peut faire aussi l’addition mais pas la soustraction ? par contre si tu veut la soustraction tu aura la multiplication ?

Yep, J'ai galéré à faire un truc cohérent et le développement a convergé à lier les mixins les un aux autres.

Par exemple a - b est en fait a + ( -1 x b )

C'est pour ça que pour avoir la soustraction, il faut d'abord avoir la multiplication et l'addition.

Et c'est pour ça que je « livre » les mixins dans des ensembles cohérents (les carquois) car de mon point de vue les livrer indépendamment les uns des autres est un terrain miné.

+, x, -, / forme un ensemble appelé LinearAlgebra. Là,pour le nommage j'ai été carré.

Désolé si je pose beaucoup de question, mais ça m’intéresse.

Ne soit pas désolé, ça me fait plaisir d'exposer ce que j'ai fait.

Pour info, j'ai tenté de le proposer à python-ideas, mais mes nombreux manques en communication et peut-être aussi le fait que personne ne voit l'intérêt de transformer les dict en vecteur n dimensions, a fait que l'idée n'a pas été retenue.

Je me tâte à me fallucher l'énorme travail de rédiger une PEP pour re proposer l'idée.

OK ça se compare comment face aux compréhensions, etiertools et autres numpy/panda ?

Pour etiertools j'ai rien trouvé https://pypi.org/search/?q=etiertools&o=
Pour itertools ça n'a rien à voir.

Pour numpy/panda, ça se comporte grosso modo selon le même mode : celui du principe de moindre surprise.

Ah et ton schéma, il représente quoi ?

Chaque cases dans un rectangle de couleur est supposé être un trait.

Ex :
- un adder est un additionneur
- un suber un soustractionneur (kof kof)
- un muler un multiplicateur
- un diver un divisionneur (kof)

et l'ensemble de mul/div/add/sub est supposé faire un tout cohérent d'algèbre linéaire.

C'est pas très fin, mais c'est dans les grandes lignes ce que j'ai appris à faire en microélectronique que j'ai appliqué à des concepts de plus haut niveau.

Et j'ai appelé un emsemble de traits cohérents un carquois. On peut discuter longtemps sur mon talent de nommage …. Je ne suis pas convaincu moi même par mes conventions.

Mais ça paraissait intelligent quand je l'ai fait.

    from archery import mdict as d
    d({ "foo" : "bar" }) / d({ "linux" : 7})
    # {}

Là, je ne vois pas :)

Par contre si j'ai

    from archery import mdict as Point
    Point(x=1, y=1) / 7
    # {'x': 0.14285714285714285, 'y': 0.14285714285714285}

J'ai bien une homothétie d'un facteur 1/7 sur un vecteur :)

La preuve de concept part d'un classique des langages de programmations : les tableaux associatifs aussi appelés dictionnaires.

Ensuite, on surcharge les opérateurs +, -, /, x, de manière à passer les règles de l'algèbre linéaire définissant un vecteur, c'est-à-dire outre les régles de distributivité, associativité, il est défini :

• un dictionnaire nul ;
• l'opposé d'un dictionnaire ;
• l'addition de deux dictionnaires ;
• la multiplication d'un dictionnaire par un scalaire ;
• la multiplication de 2 dictionnaires l'un par l'autre ;
• le produit scalaire de deux dictionnaires ;
• d'autres opérations annexes qui peuvent être déduites des précédentes (comme le cosinus) ;

C'est plus clair ?

Oui, j'ai repompé ma copie sur messire Ortotlo :)

Tu dis que ça peut être implémenté dans n'importe quel langage objet, donc tu ne devrais pas avoir besoin de parler de traits pour en parler.

En effet.

C'est plus des opérations génériques sur des espaces vectoriels de dimensions arbitraires, mais finie, sans regarder le code.

En regardant le code, j'en arrive à la même conclusion. :)

après tout, ça devrait être faisable en définissant simplement quelques classes héritant de dict.

L'avantage du duck typing (juste s'appuyer sur la présence de __setitem__ et __getitem__) c'est que ça permet de faire un truc générique.

Ce qui permet de faire hériter des classes qui ne sont pas des dict des méthodes nécessaires à l'implémentation de l'algèbre linéaire (ou plus), mais ont une interface de dict en lui faisant hériter des traits (ou mixins) par composition.

Ex (peut être que du code c'est plus clair) :

    from collections import Counter
    from archery import VectorDict
    class CWCos(VectorDict, Counter):
         pass

    CWCos(["mot", "wut", "wut", "bla"]).cos(CWCos(["mot","wut", "bla"]))
    # OUT: 0.942809041582

Super le code, ça s'appelle l'archerie et les fichiers Python s'appellent la caserne, l'arc, le carquois et la flèche. Je vois que c'est optimisé pour le divertissement de l'auteur, pas pour la relecture.

J'étais parti de l'idée que j'utilisais des traits, et après, j'ai filé la métaphore pour tenter d'être cohérent.

Après tout, un ensemble de traits (flèches en anglais) c'est un carquois …

Et une implémentation concrète d'un ensemble de trait ça paraissait « logique » d'appeler ça un arc (car c'est avec ça qu'on lance des « traits »).

Après, avec le temps, je me suis aperçu que c'était un poil foireux, mais j'ai pas eu l'imagination nécessaire à trouver des meilleurs noms. J'ai juste changé les arcs japonais initiaux (hankyus et daikyus) par mdict (dict qui multiplie) et vdict (dict vectoriel)…

Nommer c'est dur. Ça m'a servi de leçon, depuis, j'essaie d'éviter la créativité.

Voilà, est-ce que ce n'est pas plus clair en présentant les choses comme ça ?

si si.

Il faut croire que la communication n'est pas mon fort. ^{_^}

Merci pour ce résumé qui à mon avis est plus éclairant que ma présentation.

Au temps pour moi, la maintenant défunte url labuvette.org pointait vers le meilleur des newsgroup francophone fcold (fr.comp.os.debat.linux) & co.

Et c'est là d'où une partie des moules fossilisées de linuxfr viennent.

C'est plus de la préhistoire de linuxfr que vraiment linuxfr.

C'est dommage que ce patrimoine numérique ait disparu parce qu'il y avait des perles.

Ma conscience écologique n'y survivrait pas. :)

Plus simplement, pourquoi pour la postérité ne pas lancer un projet d'IA autonome dont le corpus d'apprentissage serait linuxfr ? Comme ça je serais postérisé avec tous les autres ici en fournissant à l'Humanité un morceau de sagesse aussi éternelle que l'électricité ?

Qui ne rêve pas d'un corpus qui s'étendrait à la tribune, à la buvette et aux forums ?

Si tu tombes sur un os, je serais ravi de te donner un coup de main, soit ici, soit sur les tickets github :D

Si la postérité (la survie à ma mort de mes trucs écrits) m'intéressait ; je les aurais imprimés sur papier et je ne les laisserais pas uniquement en format numérique. :)

Ça le papier, c'est du low tech qui dure !

Je préfère un quart d'heure de gloire warholien du temps de mon vivant.

C'est plus rigolo. Et puis l'indexation google va changer et je retournerai là où je suis.

Le mien, pris au microscope :)

Je n'ai pas compris qu'est ce que tu commande ? Autrement dit, qui sont tes agents ?

Des agents ; ici des sondes de mesures en python.

Pour moi MQTT, c'est de la domotique, donc tu peux piloter tes appareils connectés comme ta lampe ?

Rien n'interdit de détourner MQTT de son usage, si les objets connectés implémentaient les commandes, ils seraient, eux aussi, pilotables de la même manière.

C'est juste une logique de bus de commandes en moins de 100 lignes de code et ne va pour l'instant pas plus loin.

Grace à la communauté, j'ai fait une petite PoC (preuve de concept) du bousin un peu suringéniée car un simple parseur LR en regexp aurait pu faire l'affaire.

Néanmoins, j'en suis arrivé à l'idée, qu'un forth dédié IPC/IoT avec une « inversion de contrôle » pour certaine commande (à définir du coté de l'interprété avec des callbacks dynamiques) était sinon utile au moins : RIGOLO.

J'envisage un ansible pour IoT basé sur du forth avec mqtt comme couche de transport aussi bien qu'un usage en orchestration de « process distribués ».

Ça continue à bouillir dans ma tête ^{^} mais je sens un truc fun, et utile émerger du brouillard.

Et pourquoi pas “Earthnet”, quitte à donner dans le différentialisme ! ^{^}

Parce qu'il y a un hébergeur qui s'appelle earthnet ?

Dans ma tête son petit nom temporaire est « forth based C&C »

À tous ceux qui aident à faire de ce post un truc construit et présentable dont @gUi, merci.

Avec plaisir :

Qui n'a pas rêvé de faire sa console de pirates qui contrôle ses agents au doigt et à l'œil traditionnellement sur IRC ?

C'est le principe d'un Control & Command parfois appelé C&C pour les botnets. Mais ici, on en fait un éducationnel.

Il s'agit de piloter des agents à distance en leur envoyant des commandes sur un BUS qui résulte dans des actions prédéfinies comme :
- arrêtes toi,
- reprends,
- dis si tu es présent et en vie …

Ci-suit un petit exemple en python de l'implémentation d'une telle logique en moins de 100 lignes de codes

Et des fois que ce soit plus facile à copier ainsi la même en quote :

Qui n'a pas rêvé de faire sa console de pirates qui contrôle ses agents au doigt et à l'œil traditionnellement sur IRC ?

C'est le principe d'un [Control & Command](https://en.wikipedia.org/wiki/Botnet#Command_and_control) parfois appelé C&C pour les botnets. Mais ici, on en fait un éducationnel.

Il s'agit de piloter des agents à distance en leur envoyant des commandes sur un BUS qui résulte dans des actions prédéfinies comme :
- arrêtes toi, 
- reprends, 
- dis si tu es présent et en vie ...

Ci-suit un petit exemple en python de l'implémentation d'une telle logique en moins de 100 lignes de codes

Merci

J'ai effectivement oublié :/

Désolé d'avoir oublié :( : la définition de wikipédia pour un C&C est un protocole de contrôle et commande centralisé pour les botnets traditionnellement sur IRC.

Le serveur MQTT est configurable en serveur websocket qui est supportée par certains clients (malheureusement non disponibles en cli). :D

Donc, j'ai les websockets si je veux \o/

Ça ressemble bien à un C&C, on est d'accord ?

Je voulais émuler GPIB au dessus de MQTT.

Puis je me suis aperçu que c'était trop compliqué au vu de mes capacités.

Je me suis limité par la suite à envoyer du forth sur un bus de commande et à simplement obtenir les trucs amusants comme arrêter, relancer une mesure, remettre à zéro le bot, … pinger …. Bref, je réimplémente un C&C en python + forth maison.

Mais, je me dis que le truc étant agnostique sur l'origine du message, ça pourrait être tout aussi bien être un IPC avec passage de forth sur le fil au lieu de passer juste des données.

J'ai trop d'idées, mais l'une d'entre elle est de faire un ansible pour IoT où comme tu peux paramétrer tes commandes cotées client, tu implémentes (ou pas) les commandes à exécuter, la sécurité reposant sur les ACLs MQTT sur les canaux. De la bonne, vraie, injection de commande par conception dans un forth qui se veut confiné en ressource et fonctionnalités pour éviter des problèmes triviaux (comme le halting problème).

Une autre, c'est de muscler le langage pour permettre de faire tout ce que fait le démonstrateur en python afin de créer une sorte d'objective forth où par défaut toute fonction est un agent indépendant qui communique par MQTT en s'envoyant du forth comme message sur un bus.

\o/ j'ai commencé à ajouter les profils (car j'imagine qu'ils sont la clé à prédire qui a du succès) et j'ai un premier résultat sous la forme d'une fonction de distribution

P(publi) = heavyside(1809, inf) x exp ( -abo/Tabo )

Ce qui pour moi (tenter des sciences solo, c'est chaud) serait la mise en évidence d'un nombre d'abo minimum pour atteindre « les posts à succès » ~1809

Merci à tous pour les échanges.

Merci.

Mon chantier politique : #iségorie

Mon plan de bataille qui émerge suite aux discussions: quantifier et qualifier par les métriques

L'impact sur « le code » ;

• modification du code pour rechercher des informations supplémentaires sur les posteurs (profil)
• rajouter pour les posts et les profils la possibilité de rajouter des étiquettes/annotations nécessaires quelque soit la méthode (bayésienne, ML, fréquentielle) pour faire de l'apprentissage
• documenter/publier des graphs
• ajouter dans le README tout en haut le changement de finalité du bot : non plus reposter, mais étudier l'inégalité d'accès aux tribunes publiques, et déterminer les variables d'influences ;
• changer le nom du projet un peu trollesque pour refléter le changement de finalité (ça j'ai pas d'idée)
• c'est con, mais il me semble (expérience) qu'il faut aussi étudier les conséquences de l'exposition par le bot (blocage du bot, exposés harcelés …) en fonction des variables d'influences qui seront éventuellement déterminées

je pense qu'il veut dire pour discuter en temps qu'humain avec d'autres humains sur le sujet.

Mais, j'ai réalisé que j'ai du travail à faire avant de recommencer à en discuter qui consiste en une mission simple et claire : recueillir des métriques et quantifier/qualifier mon intuition.