• <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>

            天行健 君子當(dāng)自強而不息

            【ZT】哈希的原理和代價

            哈希表和哈希函數(shù)是大學(xué)數(shù)據(jù)結(jié)構(gòu)中的課程,實際開發(fā)中我們經(jīng)常用到Hashtable這種結(jié)構(gòu),當(dāng)遇到鍵-值對存儲,采用Hashtable比ArrayList查找的性能高。為什么呢?我們在享受高性能的同時,需要付出什么代價,那么使用Hashtable是否就是一樁無本萬利的買賣呢?就此疑問,做以下分析,希望能拋磚引玉。

            1)hash它為什么對于鍵-值查找性能高

            學(xué) 過數(shù)據(jù)結(jié)構(gòu)的,都應(yīng)該曉得,線性表和樹中,記錄在結(jié)構(gòu)中的相對位置是隨機的,記錄和關(guān)鍵字之間不存在明確的關(guān)系,因此在查找記錄的時候,需要進行一系列的 關(guān)鍵字比較,這種查找方式建立在比較的基礎(chǔ)之上,在.net中(Array,ArrayList,List)這些集合結(jié)構(gòu)采用了上面的存儲方式。
            比如,現(xiàn)在我們有一個班同學(xué)的數(shù)據(jù),包括姓名,性別,年齡,學(xué)號等。假如數(shù)據(jù)有

            姓名 性別 年齡 學(xué)號
            張三 15 1
            李四 14 2
            王五 14 3

            假如,我們按照姓名來查找,假設(shè)查找函數(shù)FindByName(string name);

            1)查找“張三”
            只需在第一行匹配一次。
            2)查找"王五"
                在第一行匹配,失敗,
                在第二行匹配,失敗,
                在第三行匹配,成功

            上面兩種情況,分別分析了最好的情況,和最壞的情況,那么平均查找次數(shù)應(yīng)該為 (1+3)/2=2次,即平均查找次數(shù)為(記錄總數(shù)+1)的1/2。
            盡管有一些優(yōu)化的算法,可以使查找排序效率增高,但是復(fù)雜度會保持在log2n的范圍之內(nèi)。

            如 何更更快的進行查找呢?我們所期望的效果是一下子就定位到要找記錄的位置之上,這時候時間復(fù)雜度為1,查找最快。如果我們事先為每條記錄編一個序號,然后 讓他們按號入位,我們又知道按照什么規(guī)則對這些記錄進行編號的話,如果我們再次查找某個記錄的時候,只需要先通過規(guī)則計算出該記錄的編號,然后根據(jù)編號, 在記錄的線性隊列中,就可以輕易的找到記錄了 。

            注意,上述的描述包含了兩個概念,一個是用于對學(xué)生進行編號的規(guī)則,在數(shù)據(jù)結(jié)構(gòu)中,稱之為哈希函數(shù),另外一個是按照規(guī)則為學(xué)生排列的順序結(jié)構(gòu),稱之為哈希表。

            仍以上面的學(xué)生為例,假設(shè)學(xué)號就是規(guī)則,老師手上有一個規(guī)則表,在排座位的時候也按照這個規(guī)則來排序,查找李四,首先該教師會根據(jù)規(guī)則判斷出,李四的編號為2,就是在座位中的2號位置,直接走過去,“李四,哈哈,你小子,就是在這!”

            看看大體流程:


            從上面的圖中,可以看出哈希表可以描述為兩個筒子,一個筒子用來裝記錄的位置編號,另外一個筒子用來裝記錄,另外存在一套規(guī)則,用來表述記錄與編號之間的聯(lián)系。這個規(guī)則通常是如何制定的呢?

            a)直接定址法:

                我在前一篇文章對GetHashCode()性能比較的問題中談到,對于整形的數(shù)據(jù)GetHashCode()函數(shù)返回的就是整形   本身,其實就是基于直接定址的方法,比如有一組0-100的數(shù)據(jù),用來表示人的年齡

            那么,采用直接定址的方法構(gòu)成的哈希表為:

            0 1 2 3 4 5
            0歲 1歲 2歲 3歲 4歲 5歲

            .....
            這樣的一種定址方式,簡單方便,適用于元數(shù)據(jù)能夠用數(shù)字表述或者原數(shù)據(jù)具有鮮明順序關(guān)系的情形。

            b)數(shù)字分析法:

               有這樣一組數(shù)據(jù),用于表述一些人的出生日期

            75 10
            75 12 10
            75 02 14

            分析一下,年和月的第一位數(shù)字基本相同,造成沖突的幾率非常大,而后面三位差別比較大,所以采用后三位

            c)平方取中法
             取關(guān)鍵字平方后的中間幾位作為哈希地址

            d) 折疊法:
             將關(guān)鍵字分割成位數(shù)相同的幾部分,最后一部分位數(shù)可以不相同,然后去這幾部分的疊加和(取出進位)作為哈希地址,比如有這樣的數(shù)據(jù)20-1445-4547-3
            可以
                     5473
            +       4454
            +         201
            =     10128
            取出進位1,取0128為哈希地址

            e)取余法
            取關(guān)鍵字被某個不大于哈希表表長m的數(shù)p除后所得余數(shù)為哈希地址。H(key)=key MOD p (p<=m)

            f) 隨機數(shù)法
             選擇一個隨機函數(shù),取關(guān)鍵字的隨機函數(shù)值為它的哈希地址,即H(key)=random(key) ,其中random為隨機函數(shù)。通常用于關(guān)鍵字長度不等時采用此法。

            總之,哈希函數(shù)的規(guī)則是:通過某種轉(zhuǎn)換關(guān)系,使關(guān)鍵字適度的分散到指定大小的的順序結(jié)構(gòu)中。越分散,則以后查找的時間復(fù)雜度越小,空間復(fù)雜度越高。

            2)使用hash,我們付出了什么?

            hash 是一種典型以空間換時間的算法,比如原來一個長度為100的數(shù)組,對其查找,只需要遍歷且匹配相應(yīng)記錄即可,從空間復(fù)雜度上來看,假如數(shù)組存儲的是 byte類型數(shù)據(jù),那么該數(shù)組占用100byte空間。現(xiàn)在我們采用hash算法,我們前面說的hash必須有一個規(guī)則,約束鍵與存儲位置的關(guān)系,那么就 需要一個固定長度的hash表,此時,仍然是100byte的數(shù)組,假設(shè)我們需要的100byte用來記錄鍵與位置的關(guān)系,那么總的空間為 200byte,而且用于記錄規(guī)則的表大小會根據(jù)規(guī)則,大小可能是不定的,比如在lzw算法中,如果一個很長的用于記錄像素的byte數(shù)組,用來記錄位置 與鍵關(guān)系的表空間,算法推薦為一個12bit能表述的整數(shù)大小,那么足夠長的像素數(shù)組,如何分散到這樣定長的表中呢,lzw算法采用的是可變長編碼,具體 會在深入介紹lzw算法的時候介紹。

            注:hash表最突出的問題在于沖突,就是兩個鍵值經(jīng)過哈希函數(shù)計算出來的索引位置很可能相同,這個問題,下篇文章會令作闡述。
            注:之所以會簡單得介紹了hash,是為了更好的學(xué)習(xí)lzw算,學(xué)習(xí)lzw算法是為了更好的研究gif文件結(jié)構(gòu),最后,我將詳細(xì)的闡述一下gif文件是如何構(gòu)成的,如何高效操作此種類型文件。


            posted on 2008-06-14 12:56 lovedday 閱讀(5121) 評論(5)  編輯 收藏 引用 所屬分類: ▲ Data Structure And Algorithm

            評論

            # re: 【ZT】哈希的原理和代價 2010-05-28 15:30 欣萌

            cool  回復(fù)  更多評論   

            # re: 【ZT】哈希的原理和代價 2010-06-28 12:12 學(xué)生

            Very Cool  回復(fù)  更多評論   

            # re: 【ZT】哈希的原理和代價 2013-03-14 16:24 kim

            cool  回復(fù)  更多評論   

            # re: 【ZT】哈希的原理和代價[未登錄] 2016-01-31 02:03 張東升

            博客為什么這么久不更新了啊  回復(fù)  更多評論   


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            公告

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            隨筆分類(178)

            3D游戲編程相關(guān)鏈接

            搜索

            最新評論

            久久av免费天堂小草播放| 久久国产精品成人影院| 国内精品久久久久久久影视麻豆| 久久久久久综合一区中文字幕| 久久久久综合网久久| 日本加勒比久久精品| 亚洲中文字幕无码久久2020| 91久久精品91久久性色| 国产—久久香蕉国产线看观看| 久久精品视屏| 99久久国产宗和精品1上映| 久久精品中文字幕久久| 久久乐国产综合亚洲精品| 欧美一区二区三区久久综| 久久亚洲国产精品一区二区| 日韩久久无码免费毛片软件| 日韩精品久久久肉伦网站| 久久成人永久免费播放| 久久夜色精品国产噜噜麻豆| 久久精品中文字幕第23页| 久久国产精品99国产精| 久久久久亚洲精品日久生情| 久久国产福利免费| 国产一级持黄大片99久久 | 精品久久久无码人妻中文字幕豆芽| 日本精品久久久久中文字幕| 97精品伊人久久久大香线蕉| 久久涩综合| 久久久国产精品| 青青久久精品国产免费看| 国产午夜精品理论片久久| 国产成人综合久久久久久| 国产精品青草久久久久婷婷| 麻豆成人久久精品二区三区免费| 久久午夜免费视频| 久久久久久久91精品免费观看| 欧美久久久久久午夜精品| 久久久久亚洲AV成人网人人网站| 久久AⅤ人妻少妇嫩草影院| 国产精品免费久久| 久久影院亚洲一区|