Bug fixes and improvements (#1813)

* Sync zh and zh-hant version.

* Add the Warp sponsor banner.

* Update README with acknowledgments and Warp recommendation

Added acknowledgments and a recommendation for the Warp terminal application.

* Update README.md

* Update links in README.md to use HTTPS

* Sync zh and zh-hant versions.

* Add special thanks for Warp spnsorship.

* Use official warp image link.
This commit is contained in:
Yudong Jin
2025-09-23 20:44:38 +08:00
committed by GitHub
parent 790a6d17e1
commit 44effb07e6
37 changed files with 1009 additions and 636 deletions
@@ -15,7 +15,7 @@
```python title="array.py"
# 初始化陣列
arr: list[int] = [0] * 5 # [ 0, 0, 0, 0, 0 ]
nums: list[int] = [1, 3, 2, 5, 4]
nums: list[int] = [1, 3, 2, 5, 4]
```
=== "C++"
@@ -130,8 +130,8 @@
```zig title="array.zig"
// 初始化陣列
var arr = [_]i32{0} ** 5; // { 0, 0, 0, 0, 0 }
var nums = [_]i32{ 1, 3, 2, 5, 4 };
const arr = [_]i32{0} ** 5; // { 0, 0, 0, 0, 0 }
const nums = [_]i32{ 1, 3, 2, 5, 4 };
```
??? pythontutor "視覺化執行"
@@ -26,10 +26,10 @@
由於實際測試具有較大的侷限性,我們可以考慮僅透過一些計算來評估演算法的效率。這種估算方法被稱為<u>漸近複雜度分析(asymptotic complexity analysis</u>,簡稱<u>複雜度分析</u>。
複雜度分析能夠體現演算法執行所需的時間和空間資源與輸入資料大小之間的關係。**它描述了隨著輸入資料大小的增加,演算法執行所需時間和空間的增長趨勢**。這個定義有些拗口,我們可以將其分為三個重點來理解。
複雜度分析能夠體現演算法執行所需的時間和空間資源與輸入資料規模之間的關係。**它描述了隨著輸入資料規模的增加,演算法執行所需時間和空間的增長趨勢**。這個定義有些拗口,我們可以將其分為三個重點來理解。
- “時間和空間資源”分別對應<u>時間複雜度(time complexity</u>和<u>空間複雜度(space complexity</u>。
- “隨著輸入資料大小的增加”意味著複雜度反映了演算法執行效率與輸入資料體量之間的關係。
- “隨著輸入資料規模的增加”意味著複雜度反映了演算法執行效率與輸入資料規模之間的關係。
- “時間和空間的增長趨勢”表示複雜度分析關注的不是執行時間或佔用空間的具體值,而是時間或空間增長的“快慢”。
**複雜度分析克服了實際測試方法的弊端**,體現在以下幾個方面。
@@ -47,3 +47,9 @@
假設取 $n = 8$ ,你可能會發現每條曲線的值與函式對應不上。這是因為每條曲線都包含一個常數項,用於將取值範圍壓縮到一個視覺舒適的範圍內。
在實際中,因為我們通常不知道每個方法的“常數項”複雜度是多少,所以一般無法僅憑複雜度來選擇 $n = 8$ 之下的最優解法。但對於 $n = 8^5$ 就很好選了,這時增長趨勢已經佔主導了。
**Q** 是否存在根據實際使用場景,選擇犧牲時間(或空間)來設計演算法的情況?
在實際應用中,大部分情況會選擇犧牲空間換時間。例如資料庫索引,我們通常選擇建立 B+ 樹或雜湊索引,佔用大量記憶體空間,以換取 $O(\log n)$ 甚至 $O(1)$ 的高效查詢。
在空間資源寶貴的場景,也會選擇犧牲時間換空間。例如在嵌入式開發中,裝置記憶體很寶貴,工程師可能會放棄使用雜湊表,選擇使用陣列順序查詢,以節省記憶體佔用,代價是查詢變慢。
@@ -110,7 +110,7 @@ $$
![暴力搜尋遞迴樹](dp_solution_pipeline.assets/min_path_sum_dfs.png)
每個狀態都有向下和向右兩種選擇,從左上角走到右下角總共需要 $m + n - 2$ 步,所以最差時間複雜度為 $O(2^{m + n})$ ,其中 $n$ 和 $m$ 分別為網格的行數和列數。請注意,這種計算方式未考慮臨近網格邊界的情況,當到達網邊界時只剩下一種選擇,因此實際的路徑數量會少一些。
每個狀態都有向下和向右兩種選擇,從左上角走到右下角總共需要 $m + n - 2$ 步,所以最差時間複雜度為 $O(2^{m + n})$ ,其中 $n$ 和 $m$ 分別為網格的行數和列數。請注意,這種計算方式未考慮臨近網格邊界的情況,當到達網邊界時只剩下一種選擇,因此實際的路徑數量會少一些。
### 方法二:記憶化搜尋
+1 -1
View File
@@ -559,7 +559,7 @@
輸入一個 `key` ,雜湊函式的計算過程分為以下兩步。
1. 透過某種雜湊演算法 `hash()` 計算得到雜湊值。
2. 將雜湊值對桶數量(陣列長度)`capacity` 取模,從而獲取該 `key` 對應的陣列索引 `index` 。
2. 將雜湊值對桶數量(陣列長度)`capacity` 取模,從而獲取該 `key` 對應的桶(陣列索引`index` 。
```shell
index = hash(key) % capacity
+4
View File
@@ -45,3 +45,7 @@
**Q**:為什麼雜湊表擴容能夠緩解雜湊衝突?
雜湊函式的最後一步往往是對陣列長度 $n$ 取模(取餘),讓輸出值落在陣列索引範圍內;在擴容後,陣列長度 $n$ 發生變化,而 `key` 對應的索引也可能發生變化。原先落在同一個桶的多個 `key` ,在擴容後可能會被分配到多個桶中,從而實現雜湊衝突的緩解。
**Q**:如果為了高效的存取,那麼直接使用陣列不就好了嗎?
當資料的 `key` 是連續的小範圍整數時,直接用陣列即可,簡單高效。但當 `key` 是其他型別(例如字串)時,就需要藉助雜湊函式將 `key` 對映為陣列索引,再透過桶陣列儲存元素,這樣的結構就是雜湊表。
@@ -55,7 +55,7 @@
| 資料預處理 | / | 排序 $O(n \log n)$ | 建樹 $O(n \log n)$ | 建雜湊表 $O(n)$ |
| 資料是否有序 | 無序 | 有序 | 有序 | 無序 |
搜尋演算法的選擇還取決於資料體量、搜尋效能要求、資料查詢與更新頻率等。
搜尋演算法的選擇還取決規模、搜尋效能要求、資料查詢與更新頻率等。
**線性搜尋**
+1 -1
View File
@@ -3,6 +3,6 @@
- 二分搜尋依賴資料的有序性,透過迴圈逐步縮減一半搜尋區間來進行查詢。它要求輸入資料有序,且僅適用於陣列或基於陣列實現的資料結構。
- 暴力搜尋透過走訪資料結構來定位資料。線性搜尋適用於陣列和鏈結串列,廣度優先搜尋和深度優先搜尋適用於圖和樹。此類演算法通用性好,無須對資料進行預處理,但時間複雜度 $O(n)$ 較高。
- 雜湊查詢、樹查詢和二分搜尋屬於高效搜尋方法,可在特定資料結構中快速定位目標元素。此類演算法效率高,時間複雜度可達 $O(\log n)$ 甚至 $O(1)$ ,但通常需要藉助額外資料結構。
- 實際中,我們需要對資料體量、搜尋效能要求、資料查詢和更新頻率等因素進行具體分析,從而選擇合適的搜尋方法。
- 實際中,我們需要對資料規模、搜尋效能要求、資料查詢和更新頻率等因素進行具體分析,從而選擇合適的搜尋方法。
- 線性搜尋適用於小型或頻繁更新的資料;二分搜尋適用於大型、排序的資料;雜湊查詢適用於對查詢效率要求較高且無須範圍查詢的資料;樹查詢適用於需要維護順序和支持範圍查詢的大型動態資料。
- 用雜湊查詢替換線性查詢是一種常用的最佳化執行時間的策略,可將時間複雜度從 $O(n)$ 降至 $O(1)$ 。
@@ -2,7 +2,7 @@
<u>堆疊(stack</u>是一種遵循先入後出邏輯的線性資料結構。
我們可以將堆疊類比為桌面上的一疊盤子,如果想取出底部的盤子,則需要先將上面的盤子依次移走。我們將盤子替換為各種型別的元素(如整數、字元、物件等),就得到了堆疊這種資料結構。
我們可以將堆疊類比為桌面上的一疊盤子,規定每次只能移動一個盤子,那麼想取出底部的盤子,則需要先將上面的盤子依次移走。我們將盤子替換為各種型別的元素(如整數、字元、物件等),就得到了堆疊這種資料結構。
如下圖所示,我們把堆積疊元素的頂部稱為“堆疊頂”,底部稱為“堆疊底”。將把元素新增到堆疊頂的操作叫作“入堆疊”,刪除堆疊頂元素的操作叫作“出堆疊”。
+17 -1
View File
@@ -237,8 +237,24 @@
</div>
</section>
<!-- Section: special thanks -->
<section class="home-div" data-md-color-primary="grey" data-md-color-scheme="slate">
<div class="section-content">
<h3 style="text-align: center; margin: 0 0 2em 0;">
鳴謝
</h3>
<a href="https://www.warp.dev/?utm_source=github&utm_medium=influencer&utm_campaign=hello-algo">
<img src="https://github.com/warpdotdev/brand-assets/raw/main/Github/Sponsor/Warp-Github-LG-02.png"
class="device-on-hover" style="height: 18em; border-radius: 0.5em;" alt="Warp-Github-LG-02" />
<div class="text-button" style="margin: 1em auto;">
<span>Warp is built for coding with multiple AI agents.</span>
</div>
</a>
</div>
</section>
<!-- Section: contributors -->
<section data-md-color-scheme="slate" data-md-color-primary="grey" class="home-div">
<section data-md-color-scheme="default" data-md-color-primary="white" class="home-div">
<div class="section-content" style="max-width: 90vw;">
<!-- author -->
<div style="margin: 2em auto;">