informatique (MP2I/MPI) · Chapitre 12 · Application directe du cours
Problème — Trois tableaux associatifs, chronométrés
Tableaux associatifs, hachage et sérialisation · niveau 3 (difficile)
Énoncé
Le chapitre ouvre sur un tableau comparant liste, arbre de recherche et table de hachage. On le vérifie.
- Écrire les trois réalisations en OCaml et mesurer le coût d'une recherche sur clés.
- Mesurer le coût de la construction, et l'effet de l'ordre d'insertion sur l'arbre.
- Mesurer le coût d'un listage trié.
- Conclure : le tableau du chapitre est-il confirmé ?
Corrigé
Les trois réalisations sont : la liste de couples de List.assoc, le dictionnaire par ABR du chapitre chap:tas, et Hashtbl. Les clés sont mots distincts d'un dictionnaire. Tout est compilé en code natif ; on mesure le temps par recherche.
1. La recherche. Mesuré :
| temps par recherche | rapport | complexité annoncée | |
|---|---|---|---|
| liste d'association | s | ||
| arbre de recherche | s | ||
| table de hachage | s | en moyenne |
Les trois lignes se lisent ensemble. L'écart liste/hachage est de quatre ordres de grandeur : c'est la différence entre et à , et il vaudrait à . L'écart arbre/hachage, lui, n'est que de : c'est un rapport constant en apparence — en réalité il croît en , mais ne vaut que ici, et la constante du hachage, elle, comprend le calcul du haché. Un facteur ne se décide pas sur la complexité : il se décide sur ce qu'on demande d'autre à la structure.
La hauteur mesurée de l'arbre est , pour un de : l'arbre construit dans un ordre aléatoire est haut d'un multiple constant de — ici fois. C'est le résultat classique sur l'ABR aléatoire : sa hauteur moyenne est , sans le moindre rééquilibrage. L'équilibre explicite de l'arbre bicolore ne sert donc pas au cas moyen, il sert à supprimer le pire.
2. La construction, et l'ordre d'insertion. Mesuré sur clés :
| ordre d'insertion dans l'ABR | hauteur | temps |
|---|---|---|
| mélangé | s | |
| trié | s |
Un facteur pour les mêmes clés. L'arbre construit en ordre trié est le peigne annoncé par le chapitre chap:tas : exactement, et la construction est passée en . La table de hachage, elle, est insensible à l'ordre d'insertion — c'est un de ses avantages que le tableau du chapitre ne mentionne pas, et il n'est pas mince : elle n'a pas de pire cas d'entrée, seulement un pire cas de clés.
3. Le listage trié. Mesuré sur les clés :
| par l'arbre, parcours infixe | s |
|---|---|
par la table, iter puis List.sort | s |
Les deux listes obtenues sont identiques — vérifié clé par clé. Le rapport est , et il croît en : l'arbre rend une liste déjà triée en , la table doit trier en .
4. Le verdict. Le tableau du chapitre est confirmé sur ses quatre lignes, et la troisième — « aucun parcours trié possible » — est bien la ligne décisive : c'est la seule où l'écart est qualitatif. Sur la recherche, les trois structures diffèrent d'un facteur ; sur l'ordre, la table ne sait rien faire du tout et doit sous-traiter à un tri.
Deux nuances que la mesure ajoute, et que le tableau ne dit pas.
- Le facteur entre arbre et table est petit. Il ne justifie pas à lui seul de renoncer aux garanties de l'arbre, ni à son parcours trié. Une structure qui va cinq fois plus vite sur une opération et ne sait pas en faire une autre n'est pas « meilleure ».
- La ligne « pire cas » du chapitre est asymétrique. L'ABR a un pire cas d'entrée — des clés triées, ce qui arrive tous les jours —, et le mesuré le montre : facteur . La table a un pire cas de clés choisies — ce qui ne survient que si un adversaire les choisit. Ces deux pires cas n'ont pas la même probabilité, et c'est ce qui décide en pratique.