Journal PoC : Transformer les tableaux associatifs (dict/map) en vecteur algébrique

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
3
13
avr.
2026

La PoC (Preuve de concept) dont il est ici question est en python, mais elle est généralisable à tout langage objet.

Le projet

Aujourd'hui à 99% de couverture de code on peut considérer la PoC complète. Le code source sur github est ici.

Le projet vise à transformer de manière portable les tableaux associatifs en vecteur algébrique.

Pour ça on part d'un développement initialement piloté par les propriétés algébriques pour obtenir du code chez moi ça marche©.

Pourquoi ? Parce que c'est drôle, mais incidemment, et on va explorer plus tard comment : c'est utile.

La présentation FOSDEM 2017 est ici, la version vidéo est ici.

Comment ?

En utilisant des traits ou mixins (votre éclairage sur le sujet est bienvenu) par surcharge des opérateurs (à droite et à gauche) on obtient des comportements qui sont compatibles avec n'importe quoi qui a l'interface d'une table associative.

En composant les traits, on obtient deux familles de tableaux associatifs algébriques

Voir Schéma

Les tableaux associatifs algébriques qui supportent la logique de combinaison linéaire.

Et les tableaux associatifs vectoriels qui supportent les opérations sur la norme, le produit scalaire et le cosinus.

Utilité

Avoir des vecteurs de dimensions n et fractal

Autant la fractalité des vecteurs me laisse de marbre et je ne vois pas l'utilité, autant avoir des vecteurs indéfinis est utile. Un cas simple est le fameux « word counter » (compte mots) utilisé dans les exemples d'indexation textuelle.

Plus un cosinus est proche de 1 plus vos deux vecteurs pointent dans la même direction ce qui permet de mesurer la similarité.

Ce qui est vrai avec des comptes mots est vrai avec d'autres vecteurs.

Utiliser python comme démonstrateur de pseudo code qui « marche » pour de l'objet

Foncièrement, les ficelles utilisées dans ce projet sont les mêmes que pour du C++/ruby/php?/C# : de la bonne vieille surcharge d'opérateur et des utilisations d'interfaces.

Il est donc possible de porter le code en utilisant les algorithmes pas très sioux utilisés et les tests vers d'autres langages.

  • # Il dit qu'il n'a plus de genou

    Posté par  (site web personnel) . Évalué à 6 (+3/-0).

    Je n'ai rien compris. Enfin, presque rien. Et pourtant, les tableaux associatifs et les vecteurs, j'ai une assez bonne idée de ce que c'est et ce qu'on peut faire avec.

    La PoC (Preuve de concept) dont il est ici question est en python, mais elle est >généralisable à tout langage objet.

    Aujourd'hui à 99% de couverture de code on peut considérer la PoC complète.

    Ça ne donne aucune idée de ce dont il s'agit concrètement, mais bravo.

    En utilisant des traits ou mixins (votre éclairage sur le sujet est bienvenu)

    Euh, tu as utilisé des traits et des mixins et tu aimerais avoir des explications à ce sujet ‽

    Je m'arrête là, c'est trop mal expliqué pour moi. Je vais aller voir la présentation et le code pour voir si j'en tire quelque chose de compréhensible, parce que c'est quand même intriguant cette histoire.

    • [^] # Re: Il dit qu'il n'a plus de genou

      Posté par  (site web personnel) . Évalué à 6 (+3/-0).

      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.

      Sinon, visiblement il s'agit de classes qui implémentent des dictionnaires avec des trucs dignes d'un espace vectoriel, à savoir :

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

      le tout en respectant suffisamment bien les axiomes d'un espace vectoriel.

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

      • [^] # Re: Il dit qu'il n'a plus de genou

        Posté par  (site web personnel) . Évalué à 1 (+0/-0).

        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.

      • [^] # Re: Il dit qu'il n'a plus de genou

        Posté par  (site web personnel) . Évalué à 5 (+2/-0).

        Bon, j'ai regardé un peu le code. C'est assez étrange à mes yeux, il faut dire que je ne comprends pour le moment rien du tout aux traits et aux mixins, donc accessoirement ce n'est pas moi qui pourrai t'éclairer sur les concepts que tu as utilisés. Personnellement, je m'amuserais bien à faire ce genre de truc sans m'encombrer de ces concepts : après tout, ça devrait être faisable en définissant simplement quelques classes héritant de dict.

        Quoi qu'il en soit, j'ai l'explication que je cherchais : l'addition et la multiplication par un scalaire, qui sont au cœur d'un espace vectoriel, fonctionnent en travaillant coordonnée par coordonnée, en considérant chaque clef comme un indice de coordonnée.

        Par conséquent, cela ne fonctionne que pour les dictionnaires à valeurs susceptibles d'être additionnées ou multipliées par un scalaire. Forcément, sinon ce ne serait pas des maths mais de la magie.

        À mon sens, cela consiste à considérer un espace vectoriel de dimension infinie à coordonnées indexées par n'importe quels objets immuables. C'est intéressant.

        • [^] # Re: Il dit qu'il n'a plus de genou

          Posté par  (site web personnel) . Évalué à 1 (+0/-0).

          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

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.