青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 5, comments - 40, trackbacks - 0, articles - 0

關于哈希表——一個常見的謬誤

Posted on 2008-03-04 22:13 Wang Jinbo 閱讀(9369) 評論(18)  編輯 收藏 引用 所屬分類: 算法與數學
Hash Table(哈希表)就是根據對象的特征進行定位的一種數據結構。一個簡單的實現方法是將對象通過某種運算得到一個整數,再讓這個整數除以哈希表的大小,取其余數,以此作為對象的存儲位置。
很多的書上認為,哈希表的大小最好是選擇一個大的質數,并且最好不要和2的整數冪接近。《算法導論》上還認為,最不好的選擇是哈希表的大小恰好是2的整數冪,對此的解釋是(只記得大意):因為計算機是用二進制存儲的,當一個二進制數除以一個2的整數冪的時候,結果就是這個二進制數的后幾位,前面的位都丟失了,也就意味著丟失了一部分信息,進而導致哈希表中的元素分布不均勻。
這個解釋看似合理,但我不認同。不光是我,Java開發小組的人也不認同。Java里的HashSet類偏偏就把哈希表的大小設置成2的整數冪。可以設想一下,對于自然數集合中的任意一個數x,對于一個正整數M,難道x mod M為某些值的概率會大些嗎?顯然不是,因為x是在自然數集合里任選的,當選取的次數非常多時,x mod M的結果應該是平均分布在[0,M-1]中。我認為《算法導論》的錯誤在于先引入了二進制,其實二進制和哈希表的“碰撞”根本沒有什么關系;然后說對除以2^n的余數會丟失位,丟失信息,這顯然也不對,因為只要x>=M,x mod M的結果總是要“丟失一些信息的”。照《算法導論》的說法,如果計算機采用十進制,那哈希表的容量是10^n的話豈不是很糟?這種解釋顯然站不住腳。
我認為對于x mod M這樣的哈希函數來說,好壞應該取決于x的生成方式和M的值。比如一個字符串“ABC”,如果我讓x("ABC")=65*128^2+66*128+67,即把字符串當成一個128進制的整數,那么若M=128,那就很糟糕了。因為這樣無論是什么字符串,最終結果只取決于最后一個字符,這才會造成分布不均勻。

以上只是我個人的見解,有不妥之處歡迎指出。

Feedback

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-03-04 23:15 by turingbook
吹毛求疵一下:hash應該譯為散列。
哈希這個譯法顯然是當年初譯者誤以為人名了。

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-03-05 00:27 by helixapp
樓主理解很正確,假如10進制的話, 10^n 次方就不好,任意非素數都可以表示為 m1^n1 * m2^n2 * m3^n3 .... 所以說素數比其他的數字更加適合啊。

不過對于計算機,2^n 次方的確是很糟的hash size, 想想你對ip地址,對內存地址求hash吧...

不過MOD的hash方法的確有缺陷,linux kernel里面用的乘以一個大素數然后取高位的方法比這個好多了

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-03-05 00:29 by helixapp
BTW 我敢肯定java里面HashSet類沒有使用單純求余的方法來算hash

# re: 關于哈希表——一個常見的謬誤[未登錄]  回復  更多評論   

2008-03-05 08:46 by cppexplore
java里的hash是乘以31的:hash=hash<<5-hash+ch。
據說就英文而言,乘以33的是最優的:hash=hash<<5+hash+ch,這個也是apache stl等一大堆著名項目或庫的hash方式。
特定應用而言,還是要根據特定的數據,設計最優的hash函數。

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-03-05 08:56 by cppexplore
上面的語句外面都是foreach(ch in str){}。
hash表的數量 應該不是影響hash的因素吧 想不出來原因。貌似一般都把hash表的桶數量設置的很大,是實際使用到的3倍多。

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-03-05 11:25 by abettor
同意樓主的見解。

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-03-05 17:11 by #Ant
說的有一些道理,感覺hash表的大小還是要根據實際情況來選取。

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-04-18 15:12 by 萬鐵
有理, 對于mod的方法,確實與素數無關。
大于mod值的所謂信息只能“丟失”,只保留小于mod值的那些“位”。

要降低這個影響,在散列函數的計算過程中,這些低位所代表的信息也要能體現輸入。比如對于字符串的散列函數, 最好能夠把高位的字符串折回到低位去,這樣即使取余,也會保證均勻性,只不過,有一個元素對于桶的密度會增大。

能力有限, 太形式化的描述,不會。

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-08-18 19:46 by roofjava@163.com
關于這個,我也認為和2的冪數無關。但是這可能跟哈希函數的設計有關,怎么說呢,很多哈希函數的設計本身是根據二進制進行的,所以《算法導論》才會得出丟失信息的結論。

不過最好還是用大數據測試比較下。

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2008-10-19 18:23 by Phoenix
哎,樓主的思維還不夠嚴謹……

“如果計算機采用十進制,那哈希表的容量是10^n的話豈不是很糟?”
給1234,容量是10,求余得4,僅由最后一位得出,前面的數直接被無視了,而對9求余就不是這樣了。

“不光是我,Java開發小組的人也不認同。”
你知道他們用的散列函數僅僅是求余?他們二者的思想沒有矛盾,是你糾結的這個矛盾。

樓主的質疑態度還是很好的。

歡迎批評我:phoenix.0220@gmail.com

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2009-03-25 16:33 by ofan
正好看到《算法導論》中的hash table部分
我想《算法導論》中說表的大小不應為2的整數次方,應該是有針對性的,不是普遍的規律。

# re: 關于哈希表——一個常見的謬誤[未登錄]  回復  更多評論   

2010-08-05 14:12 by steven
一個理想的HASH函數,輸出的值的每一位都“散列”的,無所謂丟失哪一部分來適應“桶”的大小

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2012-03-12 02:32 by Wallace
豁然開朗啊

# re: 關于哈希表——一個常見的謬誤[未登錄]  回復  更多評論   

2013-01-25 16:08 by richard
使用質數是有意義的, 雖然準確的證明我不會(我也沒看到哪里有證明),
但是可以簡單說明一下.

用最簡單的hash函數 h(k) = k mod m來說明.
對于任意的k1, k2,
假設事件A為k1 mod m == k2 mod m, 即k1, k2產生沖突的概率為p(A).
事件B_i為k1 mod m取得某個余數i, p(B_i) = 1/m,
事件C_j為k2 mod m取得某個余數j, p(C_j) = 1/m,

1. 如果m為質數:
由于k1, k2是任意選取的, 所以事件B_i和C_j是相互獨立的,
p(A) = p(B_x) * p(C_x) = 1/(m^2)

2. 如果m不為質數:
這時m可以寫成m = a * b, (a, b不等于1或m)
假設事件D為k1和k2具有公因數a(或b), 概率為p(D),
(用~D表示D不發生, 即k1,k2互質)
* 這里p(D)我不會求, 不好意思, 不過概率論里面有, 結果是6/(pi^2) *
1) 那么, 如果在D不發生的情況下, 概率和1是一樣的,
即p(A|~D) = 1/(m^2)
2) 如果D發生, 假設k1 = c1 * a, k2 = c2 * a,
事件A可轉化為c1 mod b == c2 mod b,
即p(A|D) = 1/(b^2)
于是, 我們得到了p(A) = p(A|~D) + p(A|D)
= (1-p(D)) * 1/(m^2) + p(D) * 1/(b^2)
= 1/(m^2) + p(D) * (1/(b^2) - 1/(m^2))
顯然p(D) >= 0, 1/(b^2) - 1/(m^2) > 0,
于是, p(A) = 1/(m^2) + p(D) * (1/(b^2) - 1/(m^2)) > 1/(m^2)

綜上所述, 當m為質數時, 事件A即產生碰撞的概率比m不為質數時要小.
推廣到任意選取多個數的情況下也是成立的.

有些人可能會覺得對于任意的m, k mod m都能取到[0, m-1]的數的概率是
一樣的, 這確實沒錯. 但我們關注的問題是如何減少碰撞.

# re: 關于哈希表——一個常見的謬誤[未登錄]  回復  更多評論   

2013-01-25 16:54 by richard
不好意思, 上面關于p(D)的說明不太正確,改為

假設事件D為k1, k2, m具有公因數(a或b, 假設為a), 概率為p(D), (用~D表示D不發生)
* 這里p(D)我不會求, 不好意思, 不過兩個數互質的概率是6/(pi^2) *

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2013-03-02 01:13 by Aule
上面的證明我覺得有問題,

2) 如果D發生, 假設k1 = c1 * a, k2 = c2 * a,
事件A可轉化為c1 mod b == c2 mod b,

這一步隱含的內容是:
(c1*a) mod (a*b) = c1 mod b
但是同余并不具有可除性 這個等式是不成立的 因此這一步我認為是錯了

例如k1=2*7=14,k2=5*7=35
即 c1=2,c2=5,b=u7
c1,c2在模b環境下并不同余

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2014-02-23 23:11 by rookieaca
沒看過算法導論,不過我的理解是否均勻,要看 x 的特征,以及選取的算法。
對于,實際應用中, 基于內存地址來做HASH的話,可以標志內存的某一塊數據(OOP可以是堆中分配的對象的地址)。在這種情況下由于很多實際的機器實現的地址的對齊方式,分配的內存地址都是2的倍數。在這種情況下hash(address) = (address)MOD M,
你想想如果M=2*x的話, 分布情況會是怎么樣?

# re: 關于哈希表——一個常見的謬誤  回復  更多評論   

2014-03-25 16:13 by jaub
算法導論說的是正確的!
樓主說“,因為x是在自然數集合里任選的,當選取的次數非常多時,x mod M的結果應該是平均分布在[0,M-1]中”。那么如果存在這樣一個集合,它的元素的低位嚴重偏斜到某幾個值,x對M=2^n取余后,剩下的低位值決定元素在哈希表中的位置,而低位會聚集在某些值上,導致哈希表嚴重沖突。

只有注冊用戶登錄后才能發表評論。
網站導航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            久久国产精品久久精品国产 | 好吊成人免视频| 欧美高清视频一区二区| 久久久久久高潮国产精品视| 欧美一区二区视频网站| 久久精品人人做人人爽| 久久久亚洲一区| 欧美高潮视频| 国产精品高潮呻吟久久| 国产日韩欧美一区二区三区在线观看 | 正在播放亚洲一区| 午夜伦欧美伦电影理论片| 小黄鸭精品密入口导航| 久久蜜臀精品av| 欧美精品国产一区| 国产精品日本精品| 影音先锋成人资源站| 99精品视频免费全部在线| 先锋影音久久| 欧美激情视频一区二区三区不卡| 欧美在线视频导航| 一区二区欧美在线观看| 香蕉久久a毛片| 免费成人美女女| 国产精品成人一区二区| 国产综合色一区二区三区| 91久久精品美女| 小黄鸭精品密入口导航| 欧美不卡视频一区发布| 亚洲手机在线| 欧美激情国产精品| 黄色成人av网| 亚洲免费在线视频一区 二区| 狼人社综合社区| 夜夜爽www精品| 美脚丝袜一区二区三区在线观看| 国产精品美腿一区在线看| 亚洲国产视频a| 久久精品国产亚洲高清剧情介绍| 亚洲经典视频在线观看| 亚洲免费在线| 欧美日韩国产一区| 91久久精品www人人做人人爽| 欧美伊久线香蕉线新在线| 91久久香蕉国产日韩欧美9色 | 亚洲电影在线免费观看| 亚洲一区视频在线| 欧美日韩的一区二区| 亚洲国产精品v| 久久婷婷国产麻豆91天堂| 亚洲午夜国产成人av电影男同| 欧美大片免费观看| 亚洲国产欧美日韩另类综合| 久久免费视频在线| 香蕉免费一区二区三区在线观看| 欧美视频一区二区三区| 99国产精品| 最新热久久免费视频| 另类激情亚洲| 亚洲福利精品| 美女爽到呻吟久久久久| 久久国产精品久久国产精品 | 久久久久国产精品一区二区| 国产精品综合视频| 午夜精品久久久| 亚洲天堂av图片| 国产精品久久婷婷六月丁香| 亚洲一区二区三区中文字幕 | 99精品国产99久久久久久福利| 欧美国产日本在线| 99香蕉国产精品偷在线观看| 亚洲人成在线观看网站高清| 欧美电影在线观看完整版| 日韩亚洲欧美精品| 欧美激情在线| 亚洲激情成人网| 亚洲电影免费在线观看| 免费观看久久久4p| 亚洲经典自拍| 亚洲福利视频一区| 欧美日韩国产成人| 午夜精品久久久久久久99热浪潮| 亚洲午夜成aⅴ人片| 国产午夜精品久久久久久久| 久久阴道视频| 欧美激情综合色综合啪啪| 亚洲香蕉在线观看| 午夜一级在线看亚洲| 亚洲丶国产丶欧美一区二区三区 | 国产精品一区二区你懂得| 欧美伊人久久| 鲁大师影院一区二区三区| 在线午夜精品自拍| 久久精品国产清高在天天线 | 国产精品看片资源| 麻豆成人综合网| 欧美日韩国产色视频| 欧美一区二区精美| 欧美777四色影视在线| 亚洲一区二区高清| 久久婷婷国产综合精品青草| 亚洲午夜久久久久久久久电影院| 欧美在线视频二区| 一本一本久久| 久久久亚洲一区| 欧美亚洲视频一区二区| 免费日韩视频| 欧美中文在线字幕| 欧美日韩国产一中文字不卡| 久久午夜精品| 国产精品一区久久| 亚洲精品色婷婷福利天堂| 国产综合色精品一区二区三区| 亚洲日韩视频| 亚洲高清久久| 久久av红桃一区二区小说| 亚洲一二三区在线| 欧美成人精品不卡视频在线观看| 亚洲欧美日韩精品在线| 欧美精品系列| 欧美激情中文不卡| 黄页网站一区| 欧美在线观看视频在线| 亚洲欧美在线观看| 欧美欧美在线| 亚洲国产成人久久综合一区| 国产一区视频在线看| 亚洲综合国产精品| 亚洲女爱视频在线| 欧美性片在线观看| 日韩一级成人av| 亚洲精品在线观| 欧美成人69| 亚洲国产精品国自产拍av秋霞| 在线观看亚洲专区| 你懂的一区二区| 午夜精品999| 欧美一区二区视频在线观看2020| 欧美日韩专区在线| 亚洲免费黄色| 正在播放欧美一区| 欧美精品成人一区二区在线观看| 欧美刺激性大交免费视频| 亚洲第一在线综合网站| 久久综合九色综合欧美狠狠| 久久综合婷婷| 亚洲国产成人久久| 欧美阿v一级看视频| 亚洲国产裸拍裸体视频在线观看乱了中文 | 午夜精品久久久久久久99热浪潮| 亚洲无限av看| 欧美性大战久久久久久久蜜臀| 在线亚洲+欧美+日本专区| 亚洲欧美色婷婷| 国产视频在线一区二区| 久久精品导航| 亚洲国产经典视频| 亚洲一区二区在线看| 国产欧美另类| 久久人人爽爽爽人久久久| 亚洲国产欧美久久| 亚洲影院在线观看| 国产亚洲欧美另类中文| 久久伊人一区二区| 亚洲美女在线观看| 久久成人国产| 亚洲精品日韩一| 国产精品入口夜色视频大尺度| 久久成人免费网| 亚洲茄子视频| 久久国产精品久久久| 亚洲精品国精品久久99热一| 欧美亚州一区二区三区| 久久精品30| 亚洲九九精品| 久久人人爽爽爽人久久久| 99视频有精品| 国产一区视频网站| 欧美日韩亚洲三区| 久久精品卡一| 一区二区三区视频免费在线观看| 久久久噜噜噜久久狠狠50岁| 99re6热在线精品视频播放速度| 国产精品一卡二卡| 欧美精品在线极品| 久久精品成人一区二区三区蜜臀| 亚洲裸体俱乐部裸体舞表演av| 久久精品国产久精国产思思| 一本色道久久综合| 在线观看成人小视频| 国产精品任我爽爆在线播放| 欧美α欧美αv大片| 久久gogo国模裸体人体| 一区二区三区四区五区视频| 欧美电影免费观看| 老妇喷水一区二区三区| 欧美一级黄色录像| 亚洲婷婷免费| 狠狠色丁香久久婷婷综合_中| 久久激情综合|