3.4.7 · D5Trees
Question bank — AVL tree — balance factor, rotations (LL, RR, LR, RL), insert, delete
True or false — justify
Every AVL tree is a Binary Search Tree
True. An AVL tree is defined as a Binary Search Tree with the extra rule, so it inherits every BST property including in-order sorting.
Every Binary Search Tree is an AVL tree
False. A BST built by inserting in order is a straight line of height ; its root has , violating the AVL rule.
A tree where the root has is guaranteed to be a valid AVL tree
False. The AVL rule must hold at every node, not just the root; a deep node further down could still have .
A single rotation always reduces the height of the rotated subtree by exactly one
False. On insert it restores the pre-insert height (net change zero relative to before the insert); on delete a rotation can leave the subtree height unchanged, which is exactly why deletes cascade.
After a rotation the in-order traversal of the subtree is unchanged
True. Rotations only re-point parent/child links; they never reorder keys, so the sorted sequence — the BST invariant — is preserved.
An LR rotation is genuinely different work from doing two independent single rotations
False. LR is two single rotations:
rotateLeft on 's left child, then rotateRight on . It is a name for the pair, not a new operation.An insert into an AVL tree can require at most one rotation (single or double) to fully rebalance the whole tree
True. An insert lengthens exactly one root-to-leaf path by one; a single fix at the lowest unbalanced node restores that path's height to its original value, so no ancestor stays unbalanced.
A delete can require at most one rotation
False. A delete shortens a subtree, which can unbalance an ancestor after the fix; rebalancing may cascade up to times toward the root.
The height of the empty subtree is by convention
False. It is . This makes a leaf's height and a leaf's come out to ; using shifts every and breaks imbalance detection.
An AVL tree with nodes always has height exactly
False. Its height is bounded by about , and can be less. It is , not a fixed formula.
The minimum-node AVL tree of a given height is related to Fibonacci Numbers
True. Its node count obeys , the Fibonacci recurrence shifted, giving .
A Red-Black Tree and an AVL tree with the same keys always have the same shape
False. Both are balanced BSTs but use different rules; AVL keeps stricter height balance (better lookups), red-black allows looser balance (fewer rotations on updates).
Rotations are used in a Heap to restore its ordering after insertion
False. A binary heap uses sift-up/sift-down swaps along a single path, not BST rotations; heaps aren't search trees and have no balance-factor rule.
Spot the error
"Empty subtree height , so a leaf has height , and its ." — find the flaw
The starting convention is wrong: empty height is , so a leaf has height . The leaf's happens to still be here, but every internal node's height is now off by one, silently mis-detecting imbalance.
"I inserted a node, the root looks lopsided, so I'll count nodes on each side and rotate toward the heavier side." — find the flaw
Rotation choice is decided by balance factor and insertion path, not by counting nodes. A subtree can hold more nodes yet be shorter; only heights (via ) determine imbalance.
"During insert I found , so it's an LL case — do a right rotation." — find the flaw
only says left-heavy; it doesn't distinguish LL from LR. You must also check whether the new key went into 's left child's left (LL) or right (LR) subtree.
"On rotateRight I updated 's height first, then 's." — find the flaw
Order is reversed. After the rotation becomes the lower node, so update the child first, then the new parent , otherwise 's height is computed from a stale .
"For LR I straightened it with the outer rotation first, then the inner one." — find the flaw
The inner rotation (at ) straightens the zig-zag into a straight LL/RR line; the outer rotation (at ) then fixes it. Doing the outer one first cannot fix a bent path.
"Delete only needs a check at the node I removed; ancestors are unaffected." — find the flaw
Removing a node can shorten a subtree, so an ancestor several levels up may become unbalanced after a lower fix. You must recheck and possibly rotate on the whole path back to the root.
"On delete I found with , so I picked LR." — find the flaw
With (including ) the case is LL, not LR. The
>= 0 boundary belongs to LL; only a strictly negative left-child signals LR. The case appears only in deletes."A rotation might break the BST ordering, so afterward I re-sort the three nodes." — find the flaw
No re-sorting is ever needed. A rotation is designed to preserve in-order ordering, so the BST property is intact automatically; re-sorting would be redundant and could corrupt subtree links.
Why questions
Why is the minimum (not maximum) node count used to prove the height bound?
The sparsest tall tree is the worst case; if even the emptiest height- AVL tree needs many nodes, then nodes cannot stretch very tall. This directly upper-bounds height in terms of .
Why does the golden ratio appear in the height bound?
Because follows the Fibonacci recurrence, and Fibonacci numbers grow like . Inverting that growth gives . See Fibonacci Numbers and Big-O Notation.
Why does a double rotation need an inner rotation before the outer one?
A zig-zag (bent) imbalance can't be undone by a single turn; the inner rotation converts the bent LR/RL shape into a straight LL/RR shape that the outer rotation can then resolve.
Why do insert and delete choose the rotation case differently?
Insert knows the key path it just took (left-of-left, etc.), so it uses the key. Delete has no such key path, so it reads the taller child's own to tell straight (LL/RR) from bent (LR/RL).
Why does an insert never cascade but a delete can?
Insert restores the affected subtree to its pre-insert height, so ancestors see no change. Delete can leave a subtree one shorter, propagating a height change (and possible imbalance) upward.
Why do we walk back up after the recursive insert/delete rather than checking during the descent?
Heights and balance factors change only after the leaf-level modification happens. On the unwinding return path each node's updated height is finally known, so that's when we recompute and rotate. See Tree Rotations.
Why prefer an AVL tree over a plain BST if both do on average?
A plain BST is only on average; adversarial or sorted input degrades it to . AVL guarantees in the worst case by self-balancing.
Why is AVL often chosen over red-black for lookup-heavy workloads?
AVL keeps a tighter height bound, so searches touch fewer nodes. Red-Black Tree structures allow more slack (taller trees) in exchange for cheaper rebalancing on frequent updates.
Edge cases
Inserting a duplicate key into an AVL tree
The standard code returns the node unchanged (
else: return node), so no structural change and no rebalancing occurs — heights and balance factors stay exactly as they were.The balance factor of an empty tree (or an empty subtree)
Undefined for the tree as a whole since there's no node, but as a subtree its height contributes to a parent's computation. You never rotate "nothing."
Deleting the only node in a single-node AVL tree
The tree becomes empty (root null). No rotation applies because there is no remaining node whose could be violated.
A node with on delete's LL/LR test
falls under the
>= 0 LL branch, so a single right rotation is used. This exact-zero situation cannot arise from an insert — it's unique to deletes shortening a subtree symmetrically.Building an AVL tree by inserting keys in strictly increasing order
Unlike a plain BST (which degenerates to a line of height ), the AVL keeps rotating (repeated RR/left rotations) so height stays throughout.
A perfectly balanced tree where every node already has — does inserting one leaf force a rotation?
Not necessarily. The new leaf may push some ancestor's to , which is still legal. A rotation triggers only when some node reaches .
The tallest legal AVL subtree that still hangs off a node
One child is exactly one taller than the other. This maximal-skew-yet-legal shape is precisely what the minimum-node analysis describes.