From ee67d3e6a7293cac13c98633041e0c8228627566 Mon Sep 17 00:00:00 2001
From: huangjikun <72253502+xiaomiusa87@users.noreply.github.com>
Date: Fri, 3 May 2024 19:40:59 +0800
Subject: [PATCH 1/5] Maintain the same semantics as other languages in
 n_queens.go (#1329)

---
 codes/go/chapter_backtracking/n_queens.go | 1 +
 1 file changed, 1 insertion(+)

diff --git a/codes/go/chapter_backtracking/n_queens.go b/codes/go/chapter_backtracking/n_queens.go
index f2a74021a..5d7e7fb23 100644
--- a/codes/go/chapter_backtracking/n_queens.go
+++ b/codes/go/chapter_backtracking/n_queens.go
@@ -15,6 +15,7 @@ func backtrack(row, n int, state *[][]string, res *[][][]string, cols, diags1, d
 
 		}
 		*res = append(*res, newState)
+		return
 	}
 	// 遍历所有列
 	for col := 0; col < n; col++ {

From a6be0ffdc30fc749ddcec2904a85a695be0b03ee Mon Sep 17 00:00:00 2001
From: Hongting Su <84000657+BlindTerran@users.noreply.github.com>
Date: Fri, 3 May 2024 21:41:50 +1000
Subject: [PATCH 2/5] Update graph_traversal.md (#1334)

The implementation uses hash set to store all visited vertices instead of hash table. Change the description text from "hash table" to "hash set"
---
 en/docs/chapter_graph/graph_traversal.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/en/docs/chapter_graph/graph_traversal.md b/en/docs/chapter_graph/graph_traversal.md
index ab4d031ea..6272805fa 100644
--- a/en/docs/chapter_graph/graph_traversal.md
+++ b/en/docs/chapter_graph/graph_traversal.md
@@ -18,7 +18,7 @@ BFS is usually implemented with the help of a queue, as shown in the code below.
 2. In each iteration of the loop, pop the vertex at the front of the queue and record it as visited, then add all adjacent vertices of that vertex to the back of the queue.
 3. Repeat step `2.` until all vertices have been visited.
 
-To prevent revisiting vertices, we use a hash table `visited` to record which nodes have been visited.
+To prevent revisiting vertices, we use a hash set `visited` to record which nodes have been visited.
 
 ```src
 [file]{graph_bfs}-[class]{}-[func]{graph_bfs}
@@ -67,7 +67,7 @@ The code is relatively abstract, it is suggested to compare with the following f
 
 **Time complexity**: All vertices will be enqueued and dequeued once, using $O(|V|)$ time; in the process of traversing adjacent vertices, since it is an undirected graph, all edges will be visited $2$ times, using $O(2|E|)$ time; overall using $O(|V| + |E|)$ time.
 
-**Space complexity**: The maximum number of vertices in list `res`, hash table `visited`, and queue `que` is $|V|$, using $O(|V|)$ space.
+**Space complexity**: The maximum number of vertices in list `res`, hash set `visited`, and queue `que` is $|V|$, using $O(|V|)$ space.
 
 ## Depth-first search
 
@@ -77,7 +77,7 @@ The code is relatively abstract, it is suggested to compare with the following f
 
 ### Algorithm implementation
 
-This "go as far as possible and then return" algorithm paradigm is usually implemented based on recursion. Similar to breadth-first search, in depth-first search, we also need the help of a hash table `visited` to record the visited vertices to avoid revisiting.
+This "go as far as possible and then return" algorithm paradigm is usually implemented based on recursion. Similar to breadth-first search, in depth-first search, we also need the help of a hash set `visited` to record the visited vertices to avoid revisiting.
 
 ```src
 [file]{graph_dfs}-[class]{}-[func]{graph_dfs}
@@ -133,4 +133,4 @@ To deepen the understanding, it is suggested to combine the following figure wit
 
 **Time complexity**: All vertices will be visited once, using $O(|V|)$ time; all edges will be visited twice, using $O(2|E|)$ time; overall using $O(|V| + |E|)$ time.
 
-**Space complexity**: The maximum number of vertices in list `res`, hash table `visited` is $|V|$, and the maximum recursion depth is $|V|$, therefore using $O(|V|)$ space.
+**Space complexity**: The maximum number of vertices in list `res`, hash set `visited` is $|V|$, and the maximum recursion depth is $|V|$, therefore using $O(|V|)$ space.

From cb32c525e733fda89485a585a5691ccc6a60e32b Mon Sep 17 00:00:00 2001
From: khoaxuantu <68913255+khoaxuantu@users.noreply.github.com>
Date: Fri, 3 May 2024 18:46:42 +0700
Subject: [PATCH 3/5] feat: Add Ruby code - chapter "Sorting" (#1333)

* feat: add ruby code - chapter sorting

* Update radix_sort.rb

---------

Co-authored-by: Yudong Jin <krahets@163.com>
---
 codes/ruby/chapter_sorting/bubble_sort.rb    | 51 ++++++++++++++
 codes/ruby/chapter_sorting/counting_sort.rb  | 62 +++++++++++++++++
 codes/ruby/chapter_sorting/radix_sort.rb     | 70 ++++++++++++++++++++
 codes/ruby/chapter_sorting/selection_sort.rb | 29 ++++++++
 4 files changed, 212 insertions(+)
 create mode 100644 codes/ruby/chapter_sorting/bubble_sort.rb
 create mode 100644 codes/ruby/chapter_sorting/counting_sort.rb
 create mode 100644 codes/ruby/chapter_sorting/radix_sort.rb
 create mode 100644 codes/ruby/chapter_sorting/selection_sort.rb

diff --git a/codes/ruby/chapter_sorting/bubble_sort.rb b/codes/ruby/chapter_sorting/bubble_sort.rb
new file mode 100644
index 000000000..c97764267
--- /dev/null
+++ b/codes/ruby/chapter_sorting/bubble_sort.rb
@@ -0,0 +1,51 @@
+=begin
+File: bubble_sort.rb
+Created Time: 2024-05-02
+Author: Xuan Khoa Tu Nguyen (ngxktuzkai2000@gmail.com)
+=end
+
+### 冒泡排序 ###
+def bubble_sort(nums)
+  n = nums.length
+  # 外循环：未排序区间为 [0, i]
+  for i in (n - 1).downto(1)
+    # 内循环：将未排序区间 [0, i] 中的最大元素交换至该区间的最右端
+    for j in 0...i
+      if nums[j] > nums[j + 1]
+        # 交换 nums[j] 与 nums[j + 1]
+        nums[j], nums[j + 1] = nums[j + 1], nums[j]
+      end
+    end
+  end
+end
+
+### 冒泡排序（标志优化）###
+def bubble_sort_with_flag(nums)
+  n = nums.length
+  # 外循环：未排序区间为 [0, i]
+  for i in (n - 1).downto(1)
+    flag = false # 初始化标志位
+
+    # 内循环：将未排序区间 [0, i] 中的最大元素交换至该区间的最右端
+    for j in 0...i
+      if nums[j] > nums[j + 1]
+        # 交换 nums[j] 与 nums[j + 1]
+        nums[j], nums[j + 1] = nums[j + 1], nums[j]
+        flag = true # 记录交换元素
+      end
+    end
+
+    break unless flag # 此轮“冒泡”未交换任何元素，直接跳出
+  end
+end
+
+### Driver Code ###
+if __FILE__ == $0
+  nums = [4, 1, 3, 1, 5, 2]
+  bubble_sort(nums)
+  puts "冒泡排序完成后 nums = #{nums}"
+
+  nums1 = [4, 1, 3, 1, 5, 2]
+  bubble_sort_with_flag(nums1)
+  puts "冒泡排序完成后 nums = #{nums1}"
+end
diff --git a/codes/ruby/chapter_sorting/counting_sort.rb b/codes/ruby/chapter_sorting/counting_sort.rb
new file mode 100644
index 000000000..ca86944e4
--- /dev/null
+++ b/codes/ruby/chapter_sorting/counting_sort.rb
@@ -0,0 +1,62 @@
+=begin
+File: counting_sort.rb
+Created Time: 2024-05-02
+Author: Xuan Khoa Tu Nguyen (ngxktuzkai2000@gmail.com)
+=end
+
+### 计数排序 ###
+def counting_sort_naive(nums)
+  # 简单实现，无法用于排序对象
+  # 1. 统计数组最大元素 m
+  m = 0
+  nums.each { |num| m = [m, num].max }
+  # 2. 统计各数字的出现次数
+  # counter[num] 代表 num 的出现次数
+  counter = Array.new(m + 1, 0)
+  nums.each { |num| counter[num] += 1 }
+  # 3. 遍历 counter ，将各元素填入原数组 nums
+  i = 0
+  for num in 0...(m + 1)
+    (0...counter[num]).each do
+      nums[i] = num
+      i += 1
+    end
+  end
+end
+
+### 计数排序 ###
+def counting_sort(nums)
+  # 完整实现，可排序对象，并且是稳定排序
+  # 1. 统计数组最大元素 m
+  m = nums.max
+  # 2. 统计各数字的出现次数
+  # counter[num] 代表 num 的出现次数
+  counter = Array.new(m + 1, 0)
+  nums.each { |num| counter[num] += 1 }
+  # 3. 求 counter 的前缀和，将“出现次数”转换为“尾索引”
+  # 即 counter[num]-1 是 num 在 res 中最后一次出现的索引
+  (0...m).each { |i| counter[i + 1] += counter[i] }
+  # 4. 倒序遍历 nums, 将各元素填入结果数组 res
+  # 初始化数组 res 用于记录结果
+  n = nums.length
+  res = Array.new(n, 0)
+  (n - 1).downto(0).each do |i|
+    num = nums[i]
+    res[counter[num] - 1] = num # 将 num 放置到对应索引处
+    counter[num] -= 1 # 令前缀和自减 1 ，得到下次放置 num 的索引
+  end
+  # 使用结果数组 res 覆盖原数组 nums
+  (0...n).each { |i| nums[i] = res[i] }
+end
+
+### Driver Code ###
+if __FILE__ == $0
+  nums = [1, 0, 1, 2, 0, 4, 0, 2, 2, 4]
+
+  counting_sort_naive(nums)
+  puts "计数排序（无法排序对象）完成后 nums = #{nums}"
+
+  nums1 = [1, 0, 1, 2, 0, 4, 0, 2, 2, 4]
+  counting_sort(nums1)
+  puts "计数排序完成后 nums1 = #{nums1}"
+end
diff --git a/codes/ruby/chapter_sorting/radix_sort.rb b/codes/ruby/chapter_sorting/radix_sort.rb
new file mode 100644
index 000000000..d5611ee74
--- /dev/null
+++ b/codes/ruby/chapter_sorting/radix_sort.rb
@@ -0,0 +1,70 @@
+=begin
+File: radix_sort.rb
+Created Time: 2024-05-03
+Author: Xuan Khoa Tu Nguyen (ngxktuzkai2000@gmail.com)
+=end
+
+### 获取元素 num 的第 k 位，其中 exp = 10^(k-1) ###
+def digit(num, exp)
+  # 转入 exp 而非 k 可以避免在此重复执行昂贵的次方计算
+  (num / exp) % 10
+end
+
+### 计数排序（根据 nums 第 k 位排序）###
+def counting_sort_digit(nums, exp)
+  # 十进制的位范围为 0~9 ，因此需要长度为 10 的桶数组
+  counter = Array.new(10, 0)
+  n = nums.length
+  # 统计 0~9 各数字的出现次数
+  for i in 0...n
+    d = digit(nums[i], exp) # 获取 nums[i] 第 k 位，记为 d
+    counter[d] += 1 # 统计数字 d 的出现次数
+  end
+  # 求前缀和，将“出现个数”转换为“数组索引”
+  (1...10).each { |i| counter[i] += counter[i - 1] }
+  # 倒序遍历，根据桶内统计结果，将各元素填入 res
+  res = Array.new(n, 0)
+  for i in (n - 1).downto(0)
+    d = digit(nums[i], exp)
+    j = counter[d] - 1 # 获取 d 在数组中的索引 j
+    res[j] = nums[i] # 将当前元素填入索引 j
+    counter[d] -= 1 # 将 d 的数量减 1
+  end
+  # 使用结果覆盖原数组 nums
+  (0...n).each { |i| nums[i] = res[i] }
+end
+
+### 基数排序 ###
+def radix_sort(nums)
+  # 获取数组的最大元素，用于判断最大位数
+  m = nums.max
+  # 按照从低位到高位的顺序遍历
+  exp = 1
+  while exp <= m
+    # 对数组元素的第 k 位执行计数排序
+    # k = 1 -> exp = 1
+    # k = 2 -> exp = 10
+    # 即 exp = 10^(k-1)
+    counting_sort_digit(nums, exp)
+    exp *= 10
+  end
+end
+
+### Driver Code ###
+if __FILE__ == $0
+  # 基数排序
+  nums = [
+    10546151,
+    35663510,
+    42865989,
+    34862445,
+    81883077,
+    88906420,
+    72429244,
+    30524779,
+    82060337,
+    63832996,
+  ]
+  radix_sort(nums)
+  puts "基数排序完成后 nums = #{nums}"
+end
diff --git a/codes/ruby/chapter_sorting/selection_sort.rb b/codes/ruby/chapter_sorting/selection_sort.rb
new file mode 100644
index 000000000..79fe73eea
--- /dev/null
+++ b/codes/ruby/chapter_sorting/selection_sort.rb
@@ -0,0 +1,29 @@
+=begin
+File: selection_sort.rb
+Created Time: 2024-05-03
+Author: Xuan Khoa Tu Nguyen (ngxktuzkai2000@gmail.com)
+=end
+
+### 选择排序 ###
+def selection_sort(nums)
+  n = nums.length
+  # 外循环：未排序区间为 [i, n-1]
+  for i in 0...(n - 1)
+    # 内循环：找到未排序区间内的最小元素
+    k = i
+    for j in (i + 1)...n
+      if nums[j] < nums[k]
+        k = j # 记录最小元素的索引
+      end
+    end
+    # 将该最小元素与未排序区间的首个元素交换
+    nums[i], nums[k] = nums[k], nums[i]
+  end
+end
+
+### Driver Code ###
+if __FILE__ == $0
+  nums = [4, 1, 3, 1, 5, 2]
+  selection_sort(nums)
+  puts "选择排序完成后 nums = #{nums}"
+end

From aebaa3ef0299a81cfec3ec114f54d513e65307de Mon Sep 17 00:00:00 2001
From: cyyy <134364018+Yucao-cy@users.noreply.github.com>
Date: Fri, 3 May 2024 07:50:20 -0400
Subject: [PATCH 4/5] translation: Update hash_collision.md (#1153)

* 1

* Move `docs-en` to `en/docs`

* Revert the moving operation

* 1

* Update hash_collision.md

---------

Co-authored-by: krahets <krahets@163.com>
---
 en/docs/chapter_hashing/hash_collision.md | 63 ++++++++++++-----------
 1 file changed, 33 insertions(+), 30 deletions(-)

diff --git a/en/docs/chapter_hashing/hash_collision.md b/en/docs/chapter_hashing/hash_collision.md
index a2851dff7..20f39ca3d 100644
--- a/en/docs/chapter_hashing/hash_collision.md
+++ b/en/docs/chapter_hashing/hash_collision.md
@@ -1,45 +1,46 @@
 # Hash collision
 
-As mentioned in the previous section, **usually the input space of a hash function is much larger than its output space**, making hash collisions theoretically inevitable. For example, if the input space consists of all integers and the output space is the size of the array capacity, multiple integers will inevitably map to the same bucket index.
+The previous section mentioned that, **in most cases, the input space of a hash function is much larger than the output space**, so theoretically, hash collisions are inevitable. For example, if the input space is all integers and the output space is the size of the array capacity, then multiple integers will inevitably be mapped to the same bucket index.
 
-Hash collisions can lead to incorrect query results, severely affecting the usability of hash tables. To solve this problem, we expand the hash table whenever a hash collision occurs, until the collision is resolved. This method is simple and effective but inefficient due to the extensive data transfer and hash value computation involved in resizing the hash table. To improve efficiency, we can adopt the following strategies:
+Hash collisions can lead to incorrect query results, severely impacting the usability of the hash table. To address this issue, whenever a hash collision occurs, we perform hash table resizing until the collision disappears. This approach is pretty simple, straightforward, and working well. However, it appears to be pretty inefficient as the table expansion involves a lot of data migration as well as recalculation of hash code, which are expansive. To improve efficiency, we can adopt the following strategies:
 
-1. Improve the data structure of the hash table, **allowing it to function normally in the event of a hash collision**.
-2. Only perform resizing when necessary, i.e., when hash collisions are severe.
+1. Improve the hash table data structure in a way that **locating target element is still functioning well in the event of a hash collision**.
+2. Expansion is the last resort before it becomes necessary, when severe collisions are observed.
 
 There are mainly two methods for improving the structure of hash tables: "Separate Chaining" and "Open Addressing".
 
 ## Separate chaining
 
-In the original hash table, each bucket can store only one key-value pair. "Separate chaining" transforms individual elements into a linked list, with key-value pairs as list nodes, storing all colliding key-value pairs in the same list. The figure below shows an example of a hash table with separate chaining.
+In the original hash table, each bucket can store only one key-value pair. "Separate chaining" converts a single element into a linked list, treating key-value pairs as list nodes, storing all colliding key-value pairs in the same linked list. The figure below shows an example of a hash table with separate chaining.
 
 ![Separate chaining hash table](hash_collision.assets/hash_table_chaining.png)
 
 The operations of a hash table implemented with separate chaining have changed as follows:
 
-- **Querying elements**: Input `key`, pass through the hash function to obtain the bucket index, access the head node of the list, then traverse the list and compare `key` to find the target key-value pair.
-- **Adding elements**: First access the list head node via the hash function, then add the node (key-value pair) to the list.
-- **Deleting elements**: Access the list head based on the hash function's result, then traverse the list to find and remove the target node.
+- **Querying Elements**: Input `key`, obtain the bucket index through the hash function, then access the head node of the linked list. Traverse the linked list and compare key to find the target key-value pair.
+- **Adding Elements**: Access the head node of the linked list via the hash function, then append the node (key-value pair) to the list.
+- **Deleting Elements**: Access the head of the linked list based on the result of the hash function, then traverse the linked list to find the target node and delete it.
 
 Separate chaining has the following limitations:
 
-- **Increased space usage**: The linked list contains node pointers, which consume more memory space than arrays.
-- **Reduced query efficiency**: Due to the need for linear traversal of the list to find the corresponding element.
+- **Increased Space Usage**: The linked list contains node pointers, which consume more memory space than arrays.
+- **Reduced Query Efficiency**: This is because linear traversal of the linked list is required to find the corresponding element.
+
 
 The code below provides a simple implementation of a separate chaining hash table, with two things to note:
 
 - Lists (dynamic arrays) are used instead of linked lists for simplicity. In this setup, the hash table (array) contains multiple buckets, each of which is a list.
-- This implementation includes a method for resizing the hash table. When the load factor exceeds $\frac{2}{3}$, we resize the hash table to twice its original size.
+- This implementation includes a hash table resizing method. When the load factor exceeds $\frac{2}{3}$, we expand the hash table to twice its original size.
 
 ```src
 [file]{hash_map_chaining}-[class]{hash_map_chaining}-[func]{}
 ```
 
-It's worth noting that when the list is very long, the query efficiency $O(n)$ is poor. **At this point, the list can be converted to an "AVL tree" or "Red-Black tree"** to optimize the time complexity of the query operation to $O(\log n)$.
+It's worth noting that when the linked list is very long, the query efficiency $O(n)$ is poor. **In this case, the list can be converted to an "AVL tree" or "Red-Black tree"** to optimize the time complexity of the query operation to $O(\log n)$.
 
 ## Open addressing
 
-"Open addressing" does not introduce additional data structures but uses "multiple probes" to handle hash collisions. The probing methods mainly include linear probing, quadratic probing, and double hashing.
+"Open addressing" does not introduce additional data structures but instead handles hash collisions through "multiple probing". The probing methods mainly include linear probing, quadratic probing, and double hashing.
 
 Let's use linear probing as an example to introduce the mechanism of open addressing hash tables.
 
@@ -47,26 +48,27 @@ Let's use linear probing as an example to introduce the mechanism of open addres
 
 Linear probing uses a fixed-step linear search for probing, differing from ordinary hash tables.
 
-- **Inserting elements**: Calculate the bucket index using the hash function. If the bucket already contains an element, linearly traverse forward from the conflict position (usually with a step size of $1$) until an empty bucket is found, then insert the element.
-- **Searching for elements**: If a hash collision is found, use the same step size to linearly traverse forward until the corresponding element is found and return `value`; if an empty bucket is encountered, it means the target element is not in the hash table, so return `None`.
+- **Inserting Elements**: Calculate the bucket index using the hash function. If the bucket already contains an element, linearly traverse forward from the conflict position (usually with a step size of $1$) until an empty bucket is found, then insert the element.
+- **Searching for Elements**: If a hash collision is encountered, use the same step size to linearly traverse forward until the corresponding element is found and return `value`; if an empty bucket is encountered, it means the target element is not in the hash table, so return `None`.
 
-The figure below shows the distribution of key-value pairs in an open addressing (linear probing) hash table. According to this hash function, keys with the same last two digits will be mapped to the same bucket. Through linear probing, they are stored consecutively in that bucket and the buckets below it.
+
+The figure below shows the distribution of key-value pairs in an open addressing (linear probing) hash table. According to this hash function, keys with the same last two digits will be mapped to the same bucket. Through linear probing, they are stored sequentially in that bucket and the buckets below it.
 
 ![Distribution of key-value pairs in open addressing (linear probing) hash table](hash_collision.assets/hash_table_linear_probing.png)
 
-However, **linear probing tends to create "clustering"**. Specifically, the longer a continuous position in the array is occupied, the more likely these positions are to encounter hash collisions, further promoting the growth of these clusters and eventually leading to deterioration in the efficiency of operations.
+However, **linear probing is prone to create "clustering"**. Specifically, the longer the continuously occupied positions in the array, the greater the probability of hash collisions occurring in these continuous positions, further promoting the growth of clustering at that position, forming a vicious cycle, and ultimately leading to degraded efficiency of insertion, deletion, query, and update operations.
 
 It's important to note that **we cannot directly delete elements in an open addressing hash table**. Deleting an element creates an empty bucket `None` in the array. When searching for elements, if linear probing encounters this empty bucket, it will return, making the elements below this bucket inaccessible. The program may incorrectly assume these elements do not exist, as shown in the figure below.
 
 ![Query issues caused by deletion in open addressing](hash_collision.assets/hash_table_open_addressing_deletion.png)
 
-To solve this problem, we can use a "lazy deletion" mechanism: instead of directly removing elements from the hash table, **use a constant `TOMBSTONE` to mark the bucket**. In this mechanism, both `None` and `TOMBSTONE` represent empty buckets and can hold key-value pairs. However, when linear probing encounters `TOMBSTONE`, it should continue traversing since there may still be key-value pairs below it.
+To solve this problem, we can adopt the "lazy deletion" mechanism: instead of directly removing elements from the hash table, **use a constant `TOMBSTONE` to mark the bucket**. In this mechanism, both `None` and `TOMBSTONE` represent empty buckets and can hold key-value pairs. However, when linear probing encounters `TOMBSTONE`, it should continue traversing since there may still be key-value pairs below it.
 
-However, **lazy deletion may accelerate the degradation of hash table performance**. Every deletion operation produces a delete mark, and as `TOMBSTONE` increases, so does the search time, as linear probing may have to skip multiple `TOMBSTONE` to find the target element.
+However, **lazy deletion may accelerate the performance degradation of the hash table**. Every deletion operation produces a delete mark, and as `TOMBSTONE` increases, the search time will also increase because linear probing may need to skip multiple `TOMBSTONE` to find the target element.
 
-Therefore, consider recording the index of the first `TOMBSTONE` encountered during linear probing and swapping the target element found with this `TOMBSTONE`. The advantage of this is that each time a query or addition is performed, the element is moved to a bucket closer to the ideal position (starting point of probing), thereby optimizing the query efficiency.
+To address this, consider recording the index of the first encountered `TOMBSTONE` during linear probing and swapping the positions of the searched target element with that `TOMBSTONE`. The benefit of doing this is that each time an element is queried or added, the element will be moved to a bucket closer to its ideal position (the starting point of probing), thereby optimizing query efficiency.
 
-The code below implements an open addressing (linear probing) hash table with lazy deletion. To make fuller use of the hash table space, we treat the hash table as a "circular array," continuing to traverse from the beginning when the end of the array is passed.
+The code below implements an open addressing (linear probing) hash table with lazy deletion. To make better use of the hash table space, we treat the hash table as a "circular array,". When going beyond the end of the array, we return to the beginning and continue traversing.
 
 ```src
 [file]{hash_map_open_addressing}-[class]{hash_map_open_addressing}-[func]{}
@@ -74,35 +76,36 @@ The code below implements an open addressing (linear probing) hash table with la
 
 ### Quadratic probing
 
-Quadratic probing is similar to linear probing and is one of the common strategies of open addressing. When a collision occurs, quadratic probing does not simply skip a fixed number of steps but skips "the square of the number of probes," i.e., $1, 4, 9, \dots$ steps.
+Quadratic probing is similar to linear probing and is one of the common strategies of open addressing. When a collision occurs, quadratic probing does not simply skip a fixed number of steps but skips a number of steps equal to the "square of the number of probes", i.e., $1, 4, 9, \dots$ steps.
 
 Quadratic probing has the following advantages:
 
 - Quadratic probing attempts to alleviate the clustering effect of linear probing by skipping the distance of the square of the number of probes.
-- Quadratic probing skips larger distances to find empty positions, helping to distribute data more evenly.
+- Quadratic probing skips larger distances to find empty positions, which helps to distribute data more evenly.
 
 However, quadratic probing is not perfect:
 
 - Clustering still exists, i.e., some positions are more likely to be occupied than others.
-- Due to the growth of squares, quadratic probing may not probe the entire hash table, meaning it might not access empty buckets even if they exist in the hash table.
+- Due to the growth of squares, quadratic probing may not probe the entire hash table, meaning that even if there are empty buckets in the hash table, quadratic probing may not be able to access them.
 
 ### Double hashing
 
 As the name suggests, the double hashing method uses multiple hash functions $f_1(x)$, $f_2(x)$, $f_3(x)$, $\dots$ for probing.
 
-- **Inserting elements**: If hash function $f_1(x)$ encounters a conflict, try $f_2(x)$, and so on, until an empty position is found and the element is inserted.
-- **Searching for elements**: Search in the same order of hash functions until the target element is found and returned; if an empty position is encountered or all hash functions have been tried, it indicates the element is not in the hash table, then return `None`.
+- **Inserting Elements**: If hash function $f_1(x)$ encounters a conflict, it tries $f_2(x)$, and so on, until an empty position is found and the element is inserted.
+- **Searching for Elements**: Search in the same order of hash functions until the target element is found and returned; if an empty position is encountered or all hash functions have been tried, it indicates the element is not in the hash table, then return `None`.
 
-Compared to linear probing, double hashing is less prone to clustering but involves additional computation for multiple hash functions.
+
+Compared to linear probing, the double hashing method is less prone to clustering, but multiple hash functions introduce additional computational overhead.
 
 !!! tip
 
-    Please note that open addressing (linear probing, quadratic probing, and double hashing) hash tables all have the issue of "not being able to directly delete elements."
+    Please note that open addressing (linear probing, quadratic probing, and double hashing) hash tables all have the problem of "can not directly delete elements."
 
 ## Choice of programming languages
 
-Various programming languages have adopted different hash table implementation strategies, here are a few examples:
+Different programming languages adopt different hash table implementation strategies. Here are a few examples:
 
 - Python uses open addressing. The `dict` dictionary uses pseudo-random numbers for probing.
 - Java uses separate chaining. Since JDK 1.8, when the array length in `HashMap` reaches 64 and the length of a linked list reaches 8, the linked list is converted to a red-black tree to improve search performance.
-- Go uses separate chaining. Go stipulates that each bucket can store up to 8 key-value pairs, and if the capacity is exceeded, an overflow bucket is connected; when there are too many overflow buckets, a special equal-size expansion operation is performed to ensure performance.
+- Go uses separate chaining. Go stipulates that each bucket can store up to 8 key-value pairs, and if the capacity is exceeded, an overflow bucket is linked; when there are too many overflow buckets, a special equal-capacity resizing operation is performed to ensure performance.

From cac10b07a170298bcd8c0bd6b80a20e928546cbd Mon Sep 17 00:00:00 2001
From: K3v123 <123932560+K3v123@users.noreply.github.com>
Date: Fri, 3 May 2024 23:50:36 +1200
Subject: [PATCH 5/5] Translation: Update binary_tree.md (#1287)

* Translation: Update binary_tree.md

simplified some parts while others added a few words to make it clearer

* translation: Update binary_tree.md

edited most of the stuff that QiLOL has suggestion, again thanks QiLOL for the review

* translation: Update binary_tree.md

changed to simpler words instead.
Did not update the 2nd part, as I'm waiting for Khrahets to make the final decision
---
 en/docs/chapter_tree/binary_tree.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/en/docs/chapter_tree/binary_tree.md b/en/docs/chapter_tree/binary_tree.md
index b9dce3ef0..644b79b58 100644
--- a/en/docs/chapter_tree/binary_tree.md
+++ b/en/docs/chapter_tree/binary_tree.md
@@ -1,6 +1,6 @@
 # Binary tree
 
-A "binary tree" is a non-linear data structure that represents the ancestral and descendent relationships, embodying the "divide and conquer" logic. Similar to a linked list, the basic unit of a binary tree is a node, each containing a value, a reference to the left child node, and a reference to the right child node.
+A "binary tree" is a non-linear data structure that represents the hierarchical relationship between ancestors and descendants, embodying the divide-and-conquer logic of "splitting into two". Similar to a linked list, the basic unit of a binary tree is a node, each containing a value, a reference to the left child node, and a reference to the right child node.
 
 === "Python"
 
@@ -212,7 +212,7 @@ The commonly used terminology of binary trees is shown in the following figure.
 - "Leaf node": A node with no children, both of its pointers point to `None`.
 - "Edge": The line segment connecting two nodes, i.e., node reference (pointer).
 - The "level" of a node: Incrementing from top to bottom, with the root node's level being 1.
-- The "degree" of a node: The number of a node's children. In a binary tree, the degree can be 0, 1, or 2.
+- The "degree" of a node: The number of children a node has. In a binary tree, the degree can be 0, 1, or 2.
 - The "height" of a binary tree: The number of edges passed from the root node to the farthest leaf node.
 - The "depth" of a node: The number of edges passed from the root node to the node.
 - The "height" of a node: The number of edges from the farthest leaf node to the node.
@@ -221,13 +221,13 @@ The commonly used terminology of binary trees is shown in the following figure.
 
 !!! tip
 
-    Please note that we usually define "height" and "depth" as "the number of edges passed," but some problems or textbooks may define them as "the number of nodes passed." In this case, both height and depth need to be incremented by 1.
+    Please note that we typically define "height" and "depth" as "the number of edges traversed", but some problems or textbooks may define them as "the number of nodes traversed". In such cases, both height and depth need to be incremented by 1.
 
 ## Basic operations of binary trees
 
 ### Initializing a binary tree
 
-Similar to a linked list, initialize nodes first, then construct references (pointers).
+Similar to a linked list, begin by initialize nodes, then construct references (pointers).
 
 === "Python"
 
@@ -609,13 +609,13 @@ Similar to a linked list, inserting and removing nodes in a binary tree can be a
 
 !!! tip
 
-    It's important to note that inserting nodes may change the original logical structure of the binary tree, while removing nodes usually means removing the node and all its subtrees. Therefore, in a binary tree, insertion and removal are usually performed through a set of operations to achieve meaningful actions.
+    It's important to note that inserting nodes may change the original logical structure of the binary tree, while removing nodes typically involves removing the node and all its subtrees. Therefore, in a binary tree, insertion and removal are usually performed through a coordinated set of operations to achieve meaningful outcomes.
 
 ## Common types of binary trees
 
 ### Perfect binary tree
 
-As shown in the figure below, in a "perfect binary tree," all levels of nodes are fully filled. In a perfect binary tree, the degree of leaf nodes is $0$, and the degree of all other nodes is $2$; if the tree's height is $h$, then the total number of nodes is $2^{h+1} - 1$, showing a standard exponential relationship, reflecting the common phenomenon of cell division in nature.
+As shown in the figure below, in a "perfect binary tree," all levels of nodes are fully filled. In a perfect binary tree, the degree of leaf nodes is $0$, while the degree of all other nodes is $2$; if the tree's height is $h$, then the total number of nodes is $2^{h+1} - 1$, showing a standard exponential relationship, reflecting the common phenomenon of cell division in nature.
 
 !!! tip
 
@@ -643,7 +643,7 @@ As shown in the figure below, in a "balanced binary tree," the absolute differen
 
 ## Degeneration of binary trees
 
-The figure below shows the ideal and degenerate structures of binary trees. When every level of a binary tree is filled, it reaches the "perfect binary tree"; when all nodes are biased towards one side, the binary tree degenerates into a "linked list".
+The figure below shows the ideal and degenerate structures of binary trees. A binary tree becomes a "perfect binary tree" when every level is filled; while it degenerates into a "linked list" when all nodes are biased toward one side.
 
 - The perfect binary tree is the ideal situation, fully leveraging the "divide and conquer" advantage of binary trees.
 - A linked list is another extreme, where operations become linear, degrading the time complexity to $O(n)$.