La table de hachage est une structure de données qui permet d’implémenter une table associative (que l’on appelle aussi un index ou un dictionnaire). Son principe est de répartir les données de façon homogène à l’aide d’une fonction de hachage appliquée aux clés de la table.

La plupart des langages de programmation offrent une table de hachage comme structure de données standard, avec peut-être l’exception notable du langage C (noter que le C++ comble cette lacune).

Mais est-il possible de faire mieux que la table de hachage proposée par défaut?

Mesure du mieux

Il y a différentes mesures qui déterminent la qualité d’une table de hachage.

L’une d’elle est le taux de remplissage – est-ce que la table accommode un certain nombre d’éléments sans laisser trop de « trous »?

Une autre est l’efficacité de consultation, et l’efficacité d’insertion. Je ne parlerai pas de l’efficacité d’enlever un élément.

Un facteur clé pour améliorer le taux de remplissage est une bonne fonction de hachage. Par exemple, si la fonction de hachage ne retourne jamais que des nombres entre 0 et 100, il est inévitable que plusieurs clés aient la même valeur de hachage après une centaine d’insertions. Même si la table de hachage se redimensionne pour accommoder plus d’éléments, ce sera en vain car tous les éléments vont se retrouver aux emplacements correspondants aux nombres de 0 à 100, en fait c’est contre-productif puisque le taux de remplissage se détériore!

La solution proposée dans cet article ne permet pas de compenser une mauvaise fonction de hachage. En fait elle est plus exigeante que les solutions traditionnelles car elle fait appel à plusieurs fonctions de hachage pour chaque clé.

Le principe de la seconde chance

Utiliser deux (ou davantage) fonctions de hachage est la base de la première astuce qui va nous permettre d’écrire une table de hachage super efficace, le principe de la seconde chance.

Etant donné une fonction de hachage h1 et une clé k, comment décider où placer l’élément dans la table de hachage? Une table de hachage fait généralement appel à un tableau de taille fixe (N) pour stocker les données, donc il s’agit de faire correspondre le numéro retourné par h1(k) avec un numéro d’index dans ce tableau.

Cela se fait souvent avec l’opération modulo, c’est-à-dire le reste de la division h1(k) / N. Le modulo donne un nombre entre 0 et N-1 qui est utilisée comme valeur d’index.

Si je rappelle tout cela, c’est pour mettre en exergue le fait qu’une tâche de la table de hachage est de gérer les collisions. En effet, il y a plusieurs valeurs telles que, par exemple, x modulo 100 est égal à 13. Si la valeur de hachage est 13, 113, 213, 313 etc il faut lui trouver une place même s’il y a déjà un élément à l’emplacement prévu.

Une solution est de rechercher un autre emplacement possible pour l’élément. Le principe de la seconde change utilise une différente fonction de hachage, disons h2, pour déterminer cet autre emplacement. Il est important que h1 et h2 soient indépendants, autrement il y a des chances que les deux fonctions retournent les mêmes deux résultats pour différentes clés.

Donc l’algorithme est:

p1 = h1(k) modulo N
si libre(p1)
  alors table[p1] = paire(k, élément)
sinon
  p2 = h2(k) modulo N
  si libre(p2)
    alors table[p2] = paire(k, élément)

Il est possible d’utiliser davantage de fonctions de hachage de la même façon que h2.

Pour retrouver un élément, on regarde aux différents emplacements possible pour voir s’ils contiennent la clé recherchée.

Si tous les emplacements sont déjà pris, il peut être nécessaire de redimensionner le tableau — ce qui donne un nouvel N et permet, on l’espère, de placer l’élément.

Il n’est pas très satisfaisant de devoir compter sur un N qui a exactement la bonne valeur pour pouvoir placer un élément, d’autant plus qu’il est coûteux de redimensionner la table de hachage car tous les éléments prennent un nouvel emplacement. L’efficacité de consultation est très bonne mais utilisé seul, le principe de seconde chance donne un taux de remplissage avoisinant les 50%.

Le principe du coucou

Pour améliorer cela, on utilise une autre astuce: le principe du coucou. Le bébé coucou, il est bien connu, est né dans le nid d’autres oiseaux et se fait de la place en jetant les oeufs du nid par-dessus bord. Pour une table de hachage, l’idée est de faire de la place en déplaçant l’élément existant autre part.

Certains utilisent les fonctions de hachage pour trouver un nouvel emplacement à l’élément existant dans la table de hachage. S’il n’y a pas d’emplacement libre, il peut y avoir des déplacements en cascade. Mais une étude a montré qu’un seul déplacement par insertion est nécessaire pour une bonne efficacité.

Ma solution, de son côté, utilise une réserve pour les éléments existants déplacés. Dans mes tests, en utilisant une table de hachage de 50 à 100 éléments comme réserve, le taux de remplissage excède facilement 90% pour l’insertion de 250 à 10000 éléments jusqu’à saturation.

C’est tout bonnement excellent pour une solution aussi simple et économe en espace mémoire.

L’algorithme combinant le principe de seconde chance avec deux fonctions de hachage, le principe du coucou et une réserve est:

p1 = h1(k) modulo N
si libre(p1)
  alors table[p1] = paire(k, élément)
sinon
  p2 = h2(k) modulo N
  si libre(p2)
    alors table[p2] = paire(k, élément)
  sinon
    p = choix(p1 ou p2)
    ajoute(réserve, table[p])
    table[p] = paire(k, élément)

Si la réserve est pleine on a le choix de redimensionner le tableau ou la réserve. Je pense que l’idéal est d’augmenter les deux jusqu’à ce que la taille de la réserve soit trop grande pour être stockée dans une ligne de cache ou une page de mémoire, puis n’augmenter que la taille du tableau. Mes tests montrent qu’il n’y a pas d’avantage à avoir une très grande réserve.

Pour la réserve on peut utiliser une table de hachage comme je l’ai fait ou on peut utiliser une liste ordonnée par valeur de hachage, dont l’ordre peut être maintenu de façon efficace pour un nombre d’éléments restreint (O(log N) pour la consultation et pour l’insertion). L’avantage est que la liste ordonnée peut accepter des éléments dont toutes les valeurs de hachage sont identiques.

Problème: je n’ai qu’une seule fonction de hachage!

Souvent en standard on n’a qu’une seule fonction de hachage à disposition, par exemple en Java il y a x.hashCode(). Dans le cas d’un objet composé de plusieurs attributs, on peut simplement prendre les attributs uniques à l’objet et utiliser leurs fonctions de hachage.

Il y a un autre moyen. Puisque l’index dans le tableau est calculé à l’aide de h1(k) modulo N, le résultat non fractionnaire de la division n’entre pas en compte. Par exemple si:

N = 100
h1(k)=1113

alors l’index est 13. On n’utilise pas les deux premiers chiffres 11.

Donc on peut utiliser la partie entière de la division h1(k) / N comme seconde valeur de hachage.

Et maintenant, à vos claviers!

struct Int32bits is Countable, is Indexed, is Iterable
{
   toInt => Integ32
}

def Integ32 = new Integer(size: 32)
{
   toBits => Int32bits
}

Integ32 n = 345
.n = n.toBits << 1   # assigne à n en convertissant avec toInt

Cependant, on peut vouloir interpréter la valeur comme une série d’octets au lieu de bits. Ou bien vouloir encore d’autres interprétations… La définition du type ne peut pas prévoir toutes les permutations.

De plus, la fonction de conversion peut être difficile à écrire en dodo.

Le langage C offre deux alternatives bien connues pour résoudre cela: la coercion de type et l’union. Ce sont deux mécanismes qui sont responsables pour grande partie du caractère dangereux de la programmation C, avec l’utilisation des pointeurs.

Il faut noter que Java a aussi la coercion de type (avec des limites) mais pas les pointeurs. Comme Java est généralement considéré sûr, on pourrait juste le copier.

Mais je n’aime pas me contenter de l’existant

Voici quelques idées de travail.

Comme je l’ai remarqué entre parenthèses plus haut, la coercion de type en Java est limitée. Il y a des coercions prédéfinies, comme (int) 'A' qui convertit un caractère en son code Unicode (entier). Pour cela les fonctions de conversion font bien l’affaire.

Il y a aussi les coercions d’un type plus générique vers un type spécialisé, notamment pour le type Object que l’on veut réinterpréter comme un type particulier. C’est une coercion dynamique dans le sens que Java vérifie que le type demandé est bien valide en cours d’exécution (grâce à la façon dont Java fait le polymorphisme). Si la coercion est invalide on a un ClassCastException.

Ce type de coercion ne résout pas le problème que je me posais, qui était, par exemple, de réinterpréter un entier comme une série d’octets ou tout autre arrangement qui convient. Pour qu’une telle coercion soit valide il faut simplement que le nouveau type occupe la même place en mémoire que l’original, ou même moins de place.

Le type union de C semble une bonne solution. De plus, il permet de définir non pas juste deux, mais n’importe quel nombre de types qui peuvent occuper le même emplacement mémoire. Le coût est qu’il faut une variable pour désigner l’union, puis si le type désiré contient plusieurs champs une autre variable dedans pour la structure. On se retrouve avec des constructions très imbriquées.

Je propose de se limiter à juste deux types simultanés. De plus, pour éviter les changements incontrôlés sur une valeur qui est normalement régie par des règles particulières, la valeur originale est copiée avant d’être utilisée dans l’union. Cette copie peut être retrouvée à l’aide d’une fonction de conversion. J’appelle le type union alias et la fonction de conversion unalias:

def n' = alias(n)
{
   byte[4] octets
}

.n'.octets[1] = n'.octets[3]
.n = n'    # conversion avec n'.unalias

Le problème est que l’on ne veut pas nécessairement exposer la représentation mémoire d’un objet, et surtout pas permettre de modifier un pointeur ou un attribut de taille en mémoire! On a déjà vu assez d’horreurs en C.

Comment peut-on s’assurer que la valeur retournée par alias ou par unalias est valide? Avez-vous des suggestions?

Malgré les apparences, je ne suis pas resté complètement oisif.

Documentation
Pour une part j’ai commencé à mettre à jour la documentation du langage. Dites-moi ce que vous en pensez!

Dodo – Introduction (anglais)

Implémentation
J’ai aussi fait des tentatives d’implémentation de dodo en d’autres langages. Je reparlerai de la version C une autre fois. Pour le moment, je vous invite à regarder cette adaptation du modèle objet de dodo à Javascript (incomplet):

Source de la page

Si vous regardez tout en bas du source, vous verrez un petit programme d’exemple qui fait appel à ce modèle objet adapté de dodo.

Je donne ici les correspondances de terme:

             Dodo                |            Javascript
_________________________________|________________________________
                                 |
 struct                          | struct
                                 |
 self                            | this
                                 |
 new var0(x: 1) {def z = 36}     | copy(var0, 'x', 1, {z: 36})
                                 |
 ^fonc                           | $fonc
                                 |
 class A {def coul="bleu"}       | var A = new Class({coul: "bleu"});
                                 |
 class B {B(n) {print(n)}}       | var B = new Class({}, {1: function(n)
                                 |         {print(n);}});
                                 |
                                 |   NOTE: "1" est le nombre d'arguments
                                 |   du constructeur
                                 |
 def C = new A {def p = 0}       | var C = new A.constructor({p: 0});
                                 |
 B(1000)                         | new B(1000)
                                 |

J’ai bien tenté de rendre les variables construites par ce modèle non éditables comme en dodo mais celà fait appel au nouveau standard ECMAScript et mes connaissances de Javascript sont limitées.

Ne nous attardons pas plus longtemps sur les détails triviaux. Voyons ce que le terme signifie en informatique.

Le currying transforme une fonction qui s’applique à une liste de paramètres:

f(x, y, z)

en une fonction qui s’applique à un seul paramètre, qui retourne une autre fonction à un paramètre, etc jusqu’à consommer tous les paramètres.

f(x) -> f'(y) -> f''(z)

En dodo cette transformation se fait en remplaçant les paramètres de la fonction avec des caractères de soulignement _.

def g = f(_, _, _)

On peut appeler cette fonction avec trois paramètres de la façon suivante:

g(1)(3)(n) 	# = f(1, 3, n)

Quel est l’avantage de faire cela? Et bien cela permet d’appeler g avec un seul ou deux paramètres, et réutiliser la fonction résultante comme une fonction ordinaire. Dans un langage qui n’utilise que les fonctions curriées cela donne des propriétés intéressantes.

Dodo n’est pas un tel langage mais l’option est là.
Une autre utilisation du caractère de soulignement est d’appeler une fonction avec des paramètres renseignés à l’avance, par exemple:

def normalise = min(_, 100)
.x = normalise(x)	# contraint x à être inférieur ou égal à 100

Cela peut aussi servir à composer des fonctions:

def positive_sinus = abs(_) & sin(_)
positive_sinus(-0.5)	# = sin(abs(-0.5))

Ici « & » sert à combiner les deux fonctions en une nouvelle fonction, qui les applique dans l’ordre à l’argument. Cela ne marche pas avec les fonctions ordinaires, il faut utiliser _.

Certes il est limité à un petit nombre d’éléments du langage mais on peut déjà faire des choses intéressantes. Assurez-vous de lire Readme.txt et les exemples. Page du projet:

http://sourceforge.net/projects/dodo

Autres liens:

http://blog.developpez.com/dodo/p7976/langage/dodo/langage-minimal-pour-dodo

http://blog.developpez.com/dodo/p9236/technique/vers-une-premiere-implementation-de-dodo

Dès lors, on peut considérer une valeur de vérité comme un ensemble de taille maximale un.

L’ensemble vide [] signifie faux et l’ensemble avec un élément [v] signifie vrai. Il est aisé de relier les opérations sur les ensembles aux opérations booléennes:

Union (conjonction OU)

quel que soit E: E union E = E
[] union [v] = [v]
[v] union [] = [v]

Table de vérité:

 a   b | a OU b
_______|_____
 0   0 |  0
 0   1 |  1
 1   0 |  1
 1   1 |  1

Intersection (disjonction ET)

quel que soit E: E intersection E = E
[] intersection [v] = []
[v] intersection [] = []

Table de vérité:

 a   b | a ET b
_______|_____
 0   0 |  0
 0   1 |  0
 1   0 |  0
 1   1 |  1

Complément (négation NON)

complément [] = [v]
complément [v] = []

Table de vérité:

 a | NON a
___|_____
 0 |  1
 1 |  0

Différence symétrique (disjonction exclusive XOR)

quel que soit E: E différence symétrique E = []
[] différence symétrique [v] = [v]
[v] différence symétrique [] = [v]

Table de vérité:

 a   b | a XOR b
_______|_____
 0   0 |  0
 0   1 |  1
 1   0 |  1
 1   1 |  0

On voit que les relations sont les mêmes pour les valeurs ensemblistes [], [v] et les valeurs de vérité 0, 1.

Dans dodo, qualifier Logic apporte les opérations || (OU/union), && (ET/intersection), ! (NON/complément) et ^^ (XOR/différence symétrique). Il s’applique à la fois aux booléens, aux intervalles et aux ensembles.

Une représentation efficace d’un ensemble dont l’ensemble d’éléments possibles est limité est un entier. Chaque bit de l’entier correspond à un élément possible. Si le bit vaut 1 l’élément est présent mais s’il vaut 0 l’élément est absent.

Dans le cas du booléen considéré comme un ensemble décrit ci-dessus, l’ensemble des éléments possibles se limite à un seul: v. Il suffit donc d’un bit pour représenter le booléen.

En utilisant le bit le moins significatif, on obtient la représentation suivante:

[] = 0x0000 = 0
[v] = 0x0001 = 1

Si bien que faux vaut 0, et vrai vaut 1! Si vous êtes familier avec C ou un autre langage qui a repris la même convention cela ne devrait pas vous surprendre. De fait c’est une notation largement acceptée en logique.

Cela semble une bonne idée en théorie, mais comment cela marche en pratique?

À mon idée, les services peuvent tourner dans la même tâche, une autre tâche (le plus courant), un autre processus ou même sur une autre machine. La communication par message entre un client et un serveur doit être efficace, contrôlée et sure.

Il faut donc s’attendre à un système de messages assez complexe.

Je vais essayer de décrire ce qui peut se passer quand un client envoie une requête au serveur.
D’abord, le client doit disposer d’une capability qui l’autorise à faire la requête. Le code situé dans un constructeur ou une méthode, qui peut donc avoir des effets de bord, peut généralement obtenir une capability sans ambages. Le reste du code peut la recevoir en paramètre.

La capability contient un code (comme un mot de passe) plus ou moins sophistiqué reconnu par le serveur. Celui-ci est utilisé pour encoder la requête.

Pour savoir où envoyer la requête, il faut que le serveur enregistre les services qu’il offre auprès des clients. Alors le client peut choisir un serveur à qui envoyer la requête (ou peut-être plusieurs serveurs).

Puis le message qui forme la requête entre dans une file d’attente associée avec le serveur. Les messages sortent de la file d’attente suivant le principe du premier venu, premier servi (par défaut) ou suivant un système de priorité mis en place par le programmeur.

Je pense que chaque tâche maintient sa liste de files d’attente pour les services qu’elle utilise, et le serveur fait le tour des tâches pour trouver les files d’attentes qui lui sont destinées. Si le serveur se trouve dans un autre processus ou sur une autre machine, il y a un serveur spécial auprès du client qui s’occupe de récupérer les messages destinés au serveur pour les lui envoyer.

Une fois le message récupéré, le serveur le décode à l’aide du code correspondant à la capability utilisée. Alors la méthode désignée est exécutée avec les paramètres reçus dans le message. Les paramètres doivent être validés avant d’être passés à la méthode.

Si la méthode doit reporter une exception ou un résultat au client, il faut mettre à jour l’objet retourné par la requête (message) et en informer le client. Le message retourné a plusieurs états possibles, comme « en attente », « résultat partiel », « résultat final », « exception »…

Le client, de son côté, peut faire ce qu’il veut en attendant le résultat. Jusqu’à ce qu’il demande à utiliser ce résultat, auquel cas il s’arrête jusqu’à obtenir le résultat final ou une exception. Il devrait être possible d’accéder au résultat partiel à l’aide d’un handler muni d’un timeout.

Le compilateur peut se charger d’optimiser tout cela, peut-être en se passant d’encodage et décodage dans certains cas, ou même de passage de message. La file d’attente de messages doit être efficace et éviter de bloquer les tâches. Si le handler l’autorise, on pourrait renoncer à envoyer un message plutôt que de bloquer quand la file d’attente est trop pleine.

Y a-t-il des questions qui n’ont pas été encore abordées? Des point qui ne sont pas clairs ou erronés? J’aimerais avoir votre opinion.

Il se trouve que dodo a déjà deux mécanismes qui pourraient être réutilisés: les intercepteurs d’appel (wrap) et les templates. Voici un exemple de ce que l’on pourrait faire avec s’ils étaient utilisés pour les macros.

Le but de cet exemple est de transformer une forme impérative (boucle while) en une forme à continuations.

Par exemple, je veux transformer:

loop while (x > 2.0)
{
   .x = (x + e) * k
}

en:

fun: x -> ret(double)
   if (x > 2.0)
      (x + e) * k -> x
      $loop1(x)
   else
      ret(x)
.
-> loop1
loop1(x)

Ce code est l’équivalent de la boucle while en CPS.

Ma proposition utilise wrap pour définir la syntaxe de la boucle while et les actions associées, et template pour transformer la syntaxe.

Commençons notre exemple. D’abord on va définir une expression régulière qui correspond à la syntaxe de la boucle while:

/loop while
\(\n $cond\n \)(
{\n $body\n } | :\n $body\n \.[ \n])/

Dans l’expression régulière, j’utilise un espace pour dénoter que l’on peut mettre des espaces ou tabulations, et un saut de ligne ou \n pour indiquer que l’on peut mettre des espaces, tabulations ou sauts de lignes. Soit [ \t]* et [ \t\n\r]* respectivement.

Les syntaxes acceptées sont
loop while (cond) {body}
et
loop while (cond): body.

Quand le compilateur rencontre cette syntaxe, les variables cond et body prennent une valeur et une action est exécutée. Je définis un template loop_while qui est l’action utilisée pour transformer la syntaxe. Son invocation sera:

   loop_while(
      use (body.inVars + cond.inVars) * body.outVars,
      set body.outVars,
      while cond,
      do body)

Les paramètres de loop_while sont:

• use les variables d’entrée de la boucle. Ce sont les variables utilisées par le corps et les variables utilisées par la condition qui sont aussi modifiées par le corps de la boucle.
• set les variables de sortie de la boucle. Ce sont les variables modifiées par le corps de la boucle.
• while la condition.
• do le corps de la boucle

Voici le code complet.

/loop while
\(\n $cond\n \)(
{\n $body\n } | :\n $body\n \.[ \n])/
{
   loop_while(
      use (body.inVars + cond.inVars) * body.outVars,
      set body.outVars,
      while cond,
      do body)
}


def template loop_while(use $inVars, set $outVars, while $cond, do $body) =
   fun: inVars -> ret(outVars.types)
      if (cond)
          body -> outVars
          $loop1(inVars)
      else
          ret(outVars)
   .
   -> loop1
   loop1(inVars)

Voici comment fonctionne le code dans la forme à continuations.

  fun: inVars -> ret(outVars.types) 

Définit une fonction lambda qui prend en paramètre inVars et retourne outVars.

    if (cond) 
      body -> outVars
      $loop1(inVars) 

Si la condition est vraie, exécute le corps de la boucle puis fait un appel récursif à la fonction lambda avec inVars comme arguments.

    else 
      ret(outVars) 
  .

Sinon, retourne outVars.

  -> loop1 
  loop1(inVars)

Enfin, met la fonction lambda dans une variable loop1 puis appelle la fonction avec inVars comme arguments.

Alors que se passe-t-il si l’on met le return à l’intérieur d’un bloc try?

Par exemple:

yield(int) disUnNombre()
{
   popoh()
   try:
      return 5
      return 3
      return 1
   .
   hopop()
}

D’après la documentation, hopop() devrait être appelé juste avant que la fonction retourne avec return 5. De même pour return 3 et return 1…

Or le but du bloc try est d’isoler le code qui peut générer un erreur, de façon que le code qui suit soit toujours exécuté (bloc finally dans d’autres langages). Le yield interfère ici avec ce but.

Il faut donc ajouter une règle comme quoi l’instruction return ne cause pas l’exécution du code après le bloc try dans le cas du yield. L’exécution a toujours lieu en cas d’exception ou quand les instructions du bloc try sont complétées.

Le compilateur s’arrange pour que toutes les valeurs de la fonction soient retournées, donc hopop() est appelé dans tous les cas de terminaison.

Les vacances sont terminées et je compte reprendre la publication du Nid De Dodo. Au programme: la gestion des versions, l’encapsulation des données et probablement une discussion sur le parallélisme.

Ce sont des sujets passionnants alors il faut repasser ici à l’occasion