Pourquoi l'algorithme de rotation de l'arbre d'affichage prend-il en compte le nœud parent et grand-parent?

Je ne comprends pas très bien pourquoi la rotation dans la structure de données de l'arbre d'affichage prend en compte non seulement le parent du nœud de notation, mais aussi le grand-parent (opération zig-zag et zig-zig). Pourquoi les éléments suivants ne fonctionneraient-ils pas:

Lorsque nous insérons, par exemple, un nouveau nœud dans l'arbre, nous vérifions si nous insérons dans le sous-arbre gauche ou droit. Si nous insérons à gauche, nous faisons pivoter le résultat à DROITE, et vice versa pour le sous-arbre droit. Récursivement, ce serait comme ça

Tree insert(Tree root, Key k){
    if(k < root.key){
        root.setLeft(insert(root.getLeft(), key);
        return rotateRight(root);
    }
    //vice versa for right subtree
}

Cela devrait éviter toute la procédure de "splay", vous ne pensez pas?

L'algorithme d'équilibrage plus simple peut nécessiter temps amorti par rotation dans le pire des cas. Supposons que l'arbre n'est qu'un chemin totalement déséquilibré pour les bons enfants; aucun nœud n'a d'enfant à gauche. La seule feuille de cet arbre est l'arbre avec la clé maximale. Si vous faites pivoter cette étape étape par étape jusqu'à la racine, vous avez utilisé n - 1 rotations, et l'arbre résultant est toujours totalement déséquilibré.$\Omega(n)$$n-1$

$n^2/2$$\Omega(n)$$\Omega(n)$

Ce mauvais exemple apparaît dans le papier d'origine de Sleator et Tarjan.

$x$$x$$x$

L'avantage de cet algorithme plus complexe est qu'il amène non seulement le nœud accédé à la racine, mais déplace également chaque ancêtre du nœud accédé à peu près à mi-chemin de la racine , mais ne déplace jamais aucun nœud à plus d'un nombre constant de niveaux de la racine.

$O(\log n)$$\Omega(n)$

Plus brièvement: le jeu déplace les nœuds vers le haut rapidement et vers le bas lentement.