From 636b0738fa922722535447d22f545c52b3d17aaa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=B6=99=E5=AD=90=E8=B3=A2?= Date: Tue, 31 Dec 2024 19:20:44 +0800 Subject: [PATCH] =?UTF-8?q?fix(hash=5Fcollision):=20typo=20of=20zh-Hant=20?= =?UTF-8?q?translation=20in=20"=E7=B7=9A=E6=80=A7=E6=8E=A2=E6=9F=A5"=20sec?= =?UTF-8?q?tion=20(#1599)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Fix typo of zh-Hant translation in "線性探查" section * Fix the same typo in hash summary Q&A section * Update hash_collision.md * Update summary.md --------- Co-authored-by: Yudong Jin --- zh-hant/docs/chapter_hashing/hash_collision.md | 2 +- zh-hant/docs/chapter_hashing/summary.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zh-hant/docs/chapter_hashing/hash_collision.md b/zh-hant/docs/chapter_hashing/hash_collision.md index 2b6ad7815..1939cd24c 100644 --- a/zh-hant/docs/chapter_hashing/hash_collision.md +++ b/zh-hant/docs/chapter_hashing/hash_collision.md @@ -64,7 +64,7 @@ 然而，**懶刪除可能會加速雜湊表的效能退化**。這是因為每次刪除操作都會產生一個刪除標記，隨著 `TOMBSTONE` 的增加，搜尋時間也會增加，因為線性探查可能需要跳過多個 `TOMBSTONE` 才能找到目標元素。 -為此，考慮線上性探查中記錄遇到的首個 `TOMBSTONE` 的索引，並將搜尋到的目標元素與該 `TOMBSTONE` 交換位置。這樣做的好處是當每次查詢或新增元素時，元素會被移動至距離理想位置（探測起始點）更近的桶，從而最佳化查詢效率。 +為此，考慮在線性探查中記錄遇到的首個 `TOMBSTONE` 的索引，並將搜尋到的目標元素與該 `TOMBSTONE` 交換位置。這樣做的好處是當每次查詢或新增元素時，元素會被移動至距離理想位置（探測起始點）更近的桶，從而最佳化查詢效率。 以下程式碼實現了一個包含懶刪除的開放定址（線性探查）雜湊表。為了更加充分地使用雜湊表的空間，我們將雜湊表看作一個“環形陣列”，當越過陣列尾部時，回到頭部繼續走訪。 diff --git a/zh-hant/docs/chapter_hashing/summary.md b/zh-hant/docs/chapter_hashing/summary.md index dfc193921..c80102b9d 100644 --- a/zh-hant/docs/chapter_hashing/summary.md +++ b/zh-hant/docs/chapter_hashing/summary.md @@ -38,7 +38,7 @@ 多次雜湊是開放定址的一種，開放定址法都有不能直接刪除元素的缺陷，需要透過標記刪除。標記為已刪除的空間可以再次使用。當將新元素插入雜湊表，並且透過雜湊函式找到標記為已刪除的位置時，該位置可以被新元素使用。這樣做既能保持雜湊表的探測序列不變，又能保證雜湊表的空間使用率。 -**Q**：為什麼線上性探查中，查詢元素的時候會出現雜湊衝突呢？ +**Q**：為什麼在線性探查中，查詢元素的時候會出現雜湊衝突呢？ 查詢的時候透過雜湊函式找到對應的桶和鍵值對，發現 `key` 不匹配，這就代表有雜湊衝突。因此，線性探查法會根據預先設定的步長依次向下查詢，直至找到正確的鍵值對或無法找到跳出為止。