xinyin025/hello-algo
1
0
Fork 0
mirror of https://github.com/krahets/hello-algo.git synced 2026-07-26 04:56:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

Revisit the English version (#1835)

Browse Source 
* Review the English version using Claude-4.5.

* Update mkdocs.yml

* Align the section titles.

* Bug fixes
This commit is contained in:
Yudong Jin
2025-12-30 17:54:01 +08:00
committed by GitHub
parent 091afd38b4
commit 45e1295241
106 changed files with 4195 additions and 3398 deletions
Download Patch File Download Diff File Expand all files Collapse all files
en/docs/chapter_tree/avl_tree.md
+38 -27
View File
@@ -1,6 +1,6 @@
# AVL tree *
In the "Binary Search Tree" section, we mentioned that after multiple insertions and removals, a binary search tree might degrade to a linked list. In such cases, the time complexity of all operations degrades from $O(\log n)$ to $O(n)$.
In the "Binary Search Tree" section, we mentioned that after multiple insertion and removal operations, a binary search tree may degenerate into a linked list. In this case, the time complexity of all operations degrades from $O(\log n)$ to $O(n)$.
As shown in the figure below, after two node removal operations, this binary search tree will degrade into a linked list.
@@ -10,11 +10,11 @@ For example, in the perfect binary tree shown in the figure below, after inserti
![Degradation of an AVL tree after inserting nodes](avl_tree.assets/avltree_degradation_from_inserting_node.png)
In 1962, G. M. Adelson-Velsky and E. M. Landis proposed the <u>AVL Tree</u> in their paper "An algorithm for the organization of information". The paper detailed a series of operations to ensure that after continuously adding and removing nodes, the AVL tree would not degrade, thus maintaining the time complexity of various operations at $O(\log n)$ level. In other words, in scenarios where frequent additions, removals, searches, and modifications are needed, the AVL tree can always maintain efficient data operation performance, which has great application value.
In 1962, G. M. Adelson-Velsky and E. M. Landis proposed the <u>AVL tree</u> in their paper "An algorithm for the organization of information". The paper described in detail a series of operations ensuring that after continuously adding and removing nodes, the AVL tree does not degenerate, thus keeping the time complexity of various operations at the $O(\log n)$ level. In other words, in scenarios requiring frequent insertions, deletions, searches, and modifications, the AVL tree can always maintain efficient data operation performance, making it very valuable in applications.
## Common terminology in AVL trees
An AVL tree is both a binary search tree and a balanced binary tree, satisfying all properties of these two types of binary trees, hence it is a <u>balanced binary search tree</u>.
An AVL tree is both a binary search tree and a balanced binary tree, simultaneously satisfying all the properties of these two types of binary trees, hence it is a <u>balanced binary search tree</u>.
### Node height
@@ -180,7 +180,7 @@ Since the operations related to AVL trees require obtaining node heights, we nee
```c title=""
/* AVL tree node */
TreeNode struct TreeNode {
typedef struct TreeNode {
int val;
int height;
struct TreeNode *left;
@@ -214,7 +214,18 @@ Since the operations related to AVL trees require obtaining node heights, we nee
=== "Ruby"
```ruby title=""
### AVL tree node class ###
class TreeNode
attr_accessor :val # Node value
attr_accessor :height # Node height
attr_accessor :left # Left child reference
attr_accessor :right # Right child reference
def initialize(val)
@val = val
@height = 0
end
end
```
=== "Zig"
@@ -231,7 +242,7 @@ The "node height" refers to the distance from that node to its farthest leaf nod
### Node balance factor
The <u>balance factor</u> of a node is defined as the height of the node's left subtree minus the height of its right subtree, with the balance factor of a null node defined as $0$. We will also encapsulate the functionality of obtaining the node balance factor into a function for easy use later on:
The <u>balance factor</u> of a node is defined as the height of the node's left subtree minus the height of its right subtree, and the balance factor of a null node is defined as $0$. We also encapsulate the function to obtain the node's balance factor for convenient subsequent use:
```src
[file]{avl_tree}-[class]{avl_tree}-[func]{balance_factor}
@@ -243,13 +254,13 @@ The <u>balance factor</u> of a node is defined as the height of the node's left
## Rotations in AVL trees
The characteristic feature of an AVL tree is the "rotation" operation, which can restore balance to an unbalanced node without affecting the in-order traversal sequence of the binary tree. In other words, **the rotation operation can maintain the property of a "binary search tree" while also turning the tree back into a "balanced binary tree"**.
The characteristic of AVL trees lies in the "rotation" operation, which can restore balance to unbalanced nodes without affecting the inorder traversal sequence of the binary tree. In other words, **rotation operations can both maintain the property of a "binary search tree" and make the tree return to a "balanced binary tree"**.
We call nodes with an absolute balance factor $> 1$ "unbalanced nodes". Depending on the type of imbalance, there are four kinds of rotations: right rotation, left rotation, right-left rotation, and left-right rotation. Below, we detail these rotation operations.
We call nodes with a balance factor absolute value $> 1$ "unbalanced nodes". Depending on the imbalance situation, rotation operations are divided into four types: right rotation, left rotation, left rotation then right rotation, and right rotation then left rotation. Below we describe these rotation operations in detail.
### Right rotation
As shown in the figure below, the first unbalanced node from the bottom up in the binary tree is "node 3". Focusing on the subtree with this unbalanced node as the root, denoted as `node`, and its left child as `child`, perform a "right rotation". After the right rotation, the subtree is balanced again while still maintaining the properties of a binary search tree.
As shown in the figure below, the value below the node is the balance factor. From bottom to top, the first unbalanced node in the binary tree is "node 3". We focus on the subtree with this unbalanced node as the root, denoting the node as `node` and its left child as `child`, and perform a "right rotation" operation. After the right rotation is completed, the subtree regains balance and still maintains the properties of a binary search tree.
=== "<1>"
![Steps of right rotation](avl_tree.assets/avltree_right_rotate_step1.png)
@@ -283,42 +294,42 @@ Similarly, as shown in the figure below, when the `child` node has a left child
![Left rotation with grand_child](avl_tree.assets/avltree_left_rotate_with_grandchild.png)
It can be observed that **the right and left rotation operations are logically symmetrical, and they solve two symmetrical types of imbalance**. Based on symmetry, by replacing all `left` with `right`, and all `right` with `left` in the implementation code of right rotation, we can get the implementation code for left rotation:
It can be observed that **right rotation and left rotation operations are mirror symmetric in logic, and the two imbalance cases they solve are also symmetric**. Based on symmetry, we only need to replace all `left` in the right rotation implementation code with `right`, and all `right` with `left`, to obtain the left rotation implementation code:
```src
[file]{avl_tree}-[class]{avl_tree}-[func]{left_rotate}
```
### Left-right rotation
### Left rotation then right rotation
For the unbalanced node 3 shown in the figure below, using either left or right rotation alone cannot restore balance to the subtree. In this case, a "left rotation" needs to be performed on `child` first, followed by a "right rotation" on `node`.
For the unbalanced node 3 in the figure below, using either left rotation or right rotation alone cannot restore the subtree to balance. In this case, a "left rotation" needs to be performed on `child` first, followed by a "right rotation" on `node`.
![Left-right rotation](avl_tree.assets/avltree_left_right_rotate.png)
### Right-left rotation
### Right rotation then left rotation
As shown in the figure below, for the mirror case of the above unbalanced binary tree, a "right rotation" needs to be performed on `child` first, followed by a "left rotation" on `node`.
As shown in the figure below, for the mirror case of the above unbalanced binary tree, a "right rotation" needs to be performed on `child` first, then a "left rotation" on `node`.
![Right-left rotation](avl_tree.assets/avltree_right_left_rotate.png)
### Choice of rotation
The four kinds of imbalances shown in the figure below correspond to the cases described above, respectively requiring right rotation, left-right rotation, right-left rotation, and left rotation.
The four imbalances shown in the figure below correspond one-to-one with the above cases, requiring right rotation, left rotation then right rotation, right rotation then left rotation, and left rotation operations respectively.
![The four rotation cases of AVL tree](avl_tree.assets/avltree_rotation_cases.png)
As shown in the table below, we determine which of the above cases an unbalanced node belongs to by judging the sign of the balance factor of the unbalanced node and its higher-side child's balance factor.
As shown in the table below, we determine which case the unbalanced node belongs to by judging the signs of the balance factor of the unbalanced node and the balance factor of its taller-side child node.
<p align="center"> Table <id> &nbsp; Conditions for Choosing Among the Four Rotation Cases </p>
| Balance factor of unbalanced node | Balance factor of child node | Rotation method to use |
| --------------------------------- | ---------------------------- | --------------------------------- |
| $> 1$ (Left-leaning tree) | $\geq 0$ | Right rotation |
| $> 1$ (Left-leaning tree) | $<0$ | Left rotation then right rotation |
| $< -1$ (Right-leaning tree) | $\leq 0$ | Left rotation |
| $< -1$ (Right-leaning tree) | $>0$ | Right rotation then left rotation |
| Balance factor of the unbalanced node | Balance factor of the child node | Rotation method to apply |
| -------------------------------------- | --------------------------------- | --------------------------------- |
| $> 1$ (left-leaning tree) | $\geq 0$ | Right rotation |
| $> 1$ (left-leaning tree) | $<0$ | Left rotation then right rotation |
| $< -1$ (right-leaning tree) | $\leq 0$ | Left rotation |
| $< -1$ (right-leaning tree) | $>0$ | Right rotation then left rotation |
For convenience, we encapsulate the rotation operations into a function. **With this function, we can perform rotations on various kinds of imbalances, restoring balance to unbalanced nodes**. The code is as follows:
For ease of use, we encapsulate the rotation operations into a function. **With this function, we can perform rotations for various imbalance situations, restoring balance to unbalanced nodes**. The code is as follows:
```src
[file]{avl_tree}-[class]{avl_tree}-[func]{rotate}
@@ -328,7 +339,7 @@ For convenience, we encapsulate the rotation operations into a function. **With
### Node insertion
The node insertion operation in AVL trees is similar to that in binary search trees. The only difference is that after inserting a node in an AVL tree, a series of unbalanced nodes may appear along the path from that node to the root node. Therefore, **we need to start from this node and perform rotation operations upwards to restore balance to all unbalanced nodes**. The code is as follows:
The node insertion operation in AVL trees is similar in principle to that in binary search trees. The only difference is that after inserting a node in an AVL tree, a series of unbalanced nodes may appear on the path from that node to the root. Therefore, **we need to start from this node and perform rotation operations from bottom to top, restoring balance to all unbalanced nodes**. The code is as follows:
```src
[file]{avl_tree}-[class]{avl_tree}-[func]{insert_helper}
@@ -336,7 +347,7 @@ The node insertion operation in AVL trees is similar to that in binary search tr
### Node removal
Similarly, based on the method of removing nodes in binary search trees, rotation operations need to be performed from the bottom up to restore balance to all unbalanced nodes. The code is as follows:
Similarly, on the basis of the binary search tree's node removal method, rotation operations need to be performed from bottom to top to restore balance to all unbalanced nodes. The code is as follows:
```src
[file]{avl_tree}-[class]{avl_tree}-[func]{remove_helper}
@@ -344,10 +355,10 @@ Similarly, based on the method of removing nodes in binary search trees, rotatio
### Node search
The node search operation in AVL trees is consistent with that in binary search trees and will not be detailed here.
The node search operation in AVL trees is consistent with that in binary search trees, and will not be elaborated here.
## Typical applications of AVL trees
- Organizing and storing large amounts of data, suitable for scenarios with high-frequency searches and low-frequency intertions and removals.
- Organizing and storing large-scale data, suitable for scenarios with high-frequency searches and low-frequency insertions and deletions.
- Used to build index systems in databases.
- Red-black trees are also a common type of balanced binary search tree. Compared to AVL trees, red-black trees have more relaxed balancing conditions, require fewer rotations for node insertion and removal, and have a higher average efficiency for node addition and removal operations.
- Red-black trees are also a common type of balanced binary search tree. Compared to AVL trees, red-black trees have more relaxed balance conditions, require fewer rotation operations for node insertion and deletion, and have higher average efficiency for node addition and deletion operations.