Probleme – Trois tableaux associatifs, chronométrés
Exercice · niveau 3 (difficile) · informatique (MP2I/MPI), chapitre 12 — Tableaux associatifs, hachage et sérialisation
É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.
Les autres exercices de ce chapitre Le cours du chapitre
Un blocage sur cet exercice ? Le tuteur d'Adloun guide par questions, sans donner la réponse.