Re: [爆卦] 大學生推翻圖靈獎得主40年理論
這篇新聞的重點在於 Andrew Krapivin 偶然發現了一種方法,改進了 哈希表(Hash
Table),並且推翻了長達 40年 的計算機科學猜想。以下是主要重點與關鍵摘錄:
重點分析
問題背景:指標與哈希表
Krapivin 研究 縮小指標(micro-indicators) 的方法,嘗試提升數據結構的效率。
為了更有效組織指標指向的數據,他轉向 哈希表(hash table),這是一種計算機科學中研究透徹的數據結構。
突破性的發現:全新的哈希表
在改進過程中,他 無意間發明了一種全新的哈希表,其運行速度遠超預期。
羅格斯大學教授 Martín Farach-Colton 對此持懷疑態度,因為哈希表的基礎已被深入
研究多年。
卡內基美隆大學的 William Kuszmaul 確認了這項發現,並驚訝地表示 Krapivin 推翻了一個長達 40 年的計算機科學猜想。
顛覆性發現:突破時間複雜度下限
傳統認知:
在某些哈希表(如均勻探測策略的哈希表)中,最糟情況 的 查詢與插入時間下限 為
O(x),其中 x 是哈希表的裝填程度(load factor)。
計算機科學家 姚期智(Andrew Yao) 曾預測,對於 貪心型哈希表,查詢操作的平均時間無法優於 O(logx)。
Krapivin 的發現:
他們的 新哈希表 能夠將最糟情況的查詢與插入時間縮減至 O(log x2 ),比過去的下限更快。
更顛覆性的突破: 在某些 非貪心型哈希表 中,平均查詢時間可達 O(1),完全擺脫哈希表的裝填程度影響。
關鍵摘錄
「你不只是設計了酷炫的雜湊表,你其實完全推翻了一個長達 40 年的猜想!」
→ 這表明該發現的重大影響,顛覆了計算機科學界的認知。
「最糟情況下的查詢與插入時間可達 O(log x2 ),遠比姚的預測快得多。」
→ 這項發現提升了哈希表在高載狀態下的效率,挑戰了既有的時間下限理論。
「在某些非貪心型哈希表中,平均查詢時間甚至可達 O(1),不受裝填程度影響。」
→ 這突破了哈希表的傳統設計,使其無論多接近滿載,查詢仍可保持恆定時間。
總結
這項發現不僅優化了哈希表的 查詢與插入速度,更挑戰了 計算機科學長期以來的理論限制。如果進一步被驗證並應用,可能會對 數據庫、快取系統 甚至 大型分布式系統 帶來革命性影響。
GPT說的 雖然我看不懂OuO
--
這對一般人沒啥影響 懶得解釋
只要知道加密解密速度會提昇就好
大師級的理論被推翻不知道本人有什麼想
法?
一個是速度變快 一個是數量多寡不影響速度
難怪回的超快
不止加解密吧, 大數據查詢速度也會更快
主要是IT系統查詢會變快 而且以前設計
hash table會因為考慮資料量變大也許會變
慢 而用更大的hash function 也許以後可
以不用想這麼多 有方法讓效能恆定
好猛,非貪婪算法可以壓到0(1)
用了一堆名詞其實就是 pointer而已
這對一般人的影響也超大…
你這個GPT吃進去根本沒消化
我還有追問阿 但點到為止
非專業懶得裝懂
---- 追問 Krapivin 的新哈希表之所以能達成這種突破,主要原因可能來自以下幾個方面: 1. 傳統哈希表的挑戰 (a) 貪心型哈希表的限制 貪心型(greedy-based)哈希表在插入時會根據一定規則(如線性探測、二次探測)選擇 「最近的可用位置」,這會導致高載時發生碰撞(collision),進而影響查詢速度。 姚期智的猜想 認為,無論怎麼設計,這類哈希表的平均查詢時間至少會是 O(logx),因 為隨著裝填程度 x 增加,碰撞會越來越嚴重,查詢時間無法避免增長。 (b) 哈希表的最糟情況時間下限 O(x) 傳統理論認為,當哈希表幾乎裝滿時,最糟的查詢時間會與 x(裝填程度) 線性相關, 因為某些數據可能需要經過 x 次探測才能找到。 這是因為現有的設計無法避免最壞情況的長鏈(long probe chains),即一串數據擠在 某些槽位上,導致搜索時間變長。 2. 可能的技術突破 Krapivin 的新設計可能涉及 不同的哈希策略,使其打破過去的下限約束: (a) 改進探測方式(非貪心型哈希) 傳統方法:線性探測(linear probing)、二次探測(quadratic probing)等方法會導 致特定槽位上的碰撞越來越嚴重,查詢時間變長。 Krapivin 可能的創新: 採用非貪心型策略,使數據分布更加均勻。 避免「最短路徑插入」,而是尋找能夠在全局範圍內最優分配的方式。 可能涉及隨機化技術,減少碰撞的影響,使得查詢時間不受 x 增長影響。 (b) 動態重組或自適應結構 傳統哈希表:哈希函數固定,插入與查詢的規則也固定,導致某些槽位長時間負擔過重。 可能的改進方法: 使用 自適應哈希技術(adaptive hashing),根據負載情況動態調整數據的存儲位置。 重哈希(Rehashing)優化,但不影響查詢時間。 層級式哈希(hierarchical hashing),利用額外的索引層來加速查詢。 (c) 透過數學證明找到更優的時間界限 研究團隊可能發現了一種全新的 機率分析方法 或 數學結構,讓某些類型的哈希表突破 O(logx) 的限制。 這可能涉及 高效能的隨機哈希技術(randomized hashing),讓不同鍵值的存儲行為更 加分散,減少最差情況的影響。 3. 影響與意義 (a) O(1) 查詢時間的影響 如果哈希表的查詢時間真的達到 O(1) 且不受裝填程度影響,將對許多領域帶來重大影響 ,包括: 資料庫與索引(Database & Indexing):加速 SQL / NoSQL 資料庫查詢,降低資料庫索 引的查詢時間。 分布式系統與快取(Distributed Systems & Caching):如 Google 的 Bigtable、 Facebook 的 Memcached,效能可能大幅提升。 密碼學與安全(Cryptography & Security):更快的哈希表可能影響密碼學應用,如 Bloom Filter、Merkle Tree。 (b) 挑戰計算機科學的傳統理論 這項發現推翻了 姚期智的 40 年理論預測,顯示哈希表的時間複雜度界限可能比過去所 認為的更低,這可能引發一連串新的數據結構研究與應用突破。 結論 Krapivin 等人的研究之所以能「做到這種事情」,很可能是因為他們: 發現了新的哈希策略,避免傳統貪心型方法的局限。 使用更有效的隨機化技術或數學分析,找到了突破時間下限的方法。 創造出一種自適應或層級式的哈希表設計,使得查詢時間保持恆定。 這項突破不僅讓哈希表運行速度大幅提升,也對計算機科學的基礎理論產生深遠影響,可 能改變未來大規模數據處理的方式。 ----- 以上GPT說的 不負責真實性OuO---
※ 編輯: s9234032 (223.136.237.63 臺灣), 02/11/2025 09:59:00簡單講就是新方法可以讓某些程式跑更快
叫chatgpt講人話
在存資料時可能花了點額外的功夫
但查找資料的時候卻變得非常快
資料量很大時,這種優化效果更明顯。
有在用Google搜尋吧?那你被影響到了
GPT只是在總結沒講解
97
首Po羅格斯大學生安德魯·克拉皮文(Andrew Krapivin)偶然發現了標題《微小指標 》的論文 克拉皮文很快想到能縮小指標尺寸的方法 為了達成這目標![[爆卦] 大學生推翻圖靈獎得主40年理論 [爆卦] 大學生推翻圖靈獎得主40年理論](https://s.imgur.com/images/logo-1200-630.png)
阿肥試著用白話文解釋,不深入探討。因為阿肥也只是略懂略懂。有大神看不下去的,請輕虐。 Hash 有兩種 set 跟map。map的做法呢一般又分兩種:array 跟 link list。這篇應該是著重在array這邊。一般情況下當array越來越滿,會發生碰撞,需要找出新的空位。40年理論是猜想使用greedy算法,普遍找空位的time complexity是log(n)。 而這篇提出的方法是把array切割為多個小塊,然後給這些小塊起編號以及紀錄;滿/空 的status。所以當碰撞發生時,查找就會快很多,普遍情況下會是O(1)。個人理解是相當於架一個樹在hash table上,進而達到優化查找時間,大guy是醬。 ----- Sent from JPTT on my iPhone
32
[問卦] 幹哩良勒 周杰倫的雙截棍怎麼唱的啦??幹 要試唱雙節棍 結果舌頭一直打結 到底怎麼唱的啦?? 難怪從來沒聽過高首唱這首歌 可能真的太難唱了10
[問卦] 為什麼菜很燙 吞下去就沒感覺了如題啦 剛剛吃飯 菜很燙 在嘴巴裡面哈希哈希幾次後就吞了 結果食道和胃好像沒神經一樣![[問卦] 為什麼菜很燙 吞下去就沒感覺了 [問卦] 為什麼菜很燙 吞下去就沒感覺了](https://i.imgur.com/Qvn8eE9b.jpg)
8
[鳴潮] C105 MAN!哈希咧!![[鳴潮] C105 MAN!哈希咧! [鳴潮] C105 MAN!哈希咧!](https://i.imgur.com/Wf2wMrPb.jpg)
4
[挖礦] 請問一個hive os的數字定義大家好,老弟挖礦新手,對於hive os畫面中的一個數字一直不了解定義,如下圖中,溫 度和哈希速度中間那個百分比。 如果我的6900不改oc參數,這個百分比會在30幾左右,一旦加入oc參數,這顆百分比會掉 到0,所以希望有大大能幫忙解惑,謝謝![[挖礦] 請問一個hive os的數字定義 [挖礦] 請問一個hive os的數字定義](https://i.imgur.com/U7JPFNwb.jpg)
3
[問卦] 慟!摩西當年分的竟然不是紅海!?出埃及記14:1 耶和華曉諭摩西:安營在比哈希錄前,密奪和海的中間。 出埃及記14:21 摩西向海伸杖,耶和華便用大東風,使海水一夜退去。 從地圖來看![[問卦] 慟!摩西當年分的竟然不是紅海!? [問卦] 慟!摩西當年分的竟然不是紅海!?](https://i.imgur.com/pFZSXetb.jpg)
[閒聊] TRC20轉帳問題剛從BITMAX轉USDT走TRC20去FTX BITMAX顯示提幣成功 FTX那邊則是Unconfirmed 我看了一下TRX說我的交易哈希不存在 附上交易哈希
Re: [問卦] 什麼是零知識證明阿肥外商碼農阿肥啦! 就一堆炒幣、炒Web3.0的人重新把這個概念提出來而已,不然現在2.0你一般在做的登入 系統其實就是一種ZKP了。當代的登入系統一般都是把用戶註冊密碼hash過後再加鹽(sal t)入庫,等到需要驗證就直接比對當下的哈希值,這個其實就是一種簡單明瞭的ZKP了。 然後區塊鏈只是把這個概念玩法再複雜化而已,本質就是這樣也不是什麼新東西,就一堆