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.

zh-hant/docs/chapter_computational_complexity/performance_evaluation.md

@@ -26,10 +26,10 @@
 
 由於實際測試具有較大的侷限性，我們可以考慮僅透過一些計算來評估演算法的效率。這種估算方法被稱為<u>漸近複雜度分析（asymptotic complexity analysis）</u>，簡稱<u>複雜度分析</u>。
 
-複雜度分析能夠體現演算法執行所需的時間和空間資源與輸入資料大小之間的關係。**它描述了隨著輸入資料大小的增加，演算法執行所需時間和空間的增長趨勢**。這個定義有些拗口，我們可以將其分為三個重點來理解。
+複雜度分析能夠體現演算法執行所需的時間和空間資源與輸入資料規模之間的關係。**它描述了隨著輸入資料規模的增加，演算法執行所需時間和空間的增長趨勢**。這個定義有些拗口，我們可以將其分為三個重點來理解。
 
 - “時間和空間資源”分別對應<u>時間複雜度（time complexity）</u>和<u>空間複雜度（space complexity）</u>。
-- “隨著輸入資料大小的增加”意味著複雜度反映了演算法執行效率與輸入資料體量之間的關係。
+- “隨著輸入資料規模的增加”意味著複雜度反映了演算法執行效率與輸入資料規模之間的關係。
 - “時間和空間的增長趨勢”表示複雜度分析關注的不是執行時間或佔用空間的具體值，而是時間或空間增長的“快慢”。
 
 **複雜度分析克服了實際測試方法的弊端**，體現在以下幾個方面。

zh-hant/docs/chapter_computational_complexity/summary.md

@@ -47,3 +47,9 @@
 假設取 $n = 8$ ，你可能會發現每條曲線的值與函式對應不上。這是因為每條曲線都包含一個常數項，用於將取值範圍壓縮到一個視覺舒適的範圍內。
 
 在實際中，因為我們通常不知道每個方法的“常數項”複雜度是多少，所以一般無法僅憑複雜度來選擇 $n = 8$ 之下的最優解法。但對於 $n = 8^5$ 就很好選了，這時增長趨勢已經佔主導了。
+
+**Q** 是否存在根據實際使用場景，選擇犧牲時間（或空間）來設計演算法的情況？
+
+在實際應用中，大部分情況會選擇犧牲空間換時間。例如資料庫索引，我們通常選擇建立 B+ 樹或雜湊索引，佔用大量記憶體空間，以換取 $O(\log n)$ 甚至 $O(1)$ 的高效查詢。
+
+在空間資源寶貴的場景，也會選擇犧牲時間換空間。例如在嵌入式開發中，裝置記憶體很寶貴，工程師可能會放棄使用雜湊表，選擇使用陣列順序查詢，以節省記憶體佔用，代價是查詢變慢。