• <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)系,因此在查找記錄的時候,需要進(jì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)。

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

            注意,上述的描述包含了兩個概念,一個是用于對學(xué)生進(jìn)行編號的規(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ù)可以不相同,然后去這幾部分的疊加和(取出進(jìn)位)作為哈希地址,比如有這樣的數(shù)據(jù)20-1445-4547-3
            可以
                     5473
            +       4454
            +         201
            =     10128
            取出進(jìn)位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空間?,F(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 閱讀(5120) 評論(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ù)  更多評論   

            公告

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            隨筆分類(178)

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

            搜索

            最新評論

            久久国产成人午夜aⅴ影院| 久久国产精品99国产精| 久久国产精品免费| 久久夜色撩人精品国产小说| 久久人人爽人人爽人人片AV高清| 91精品国产91久久久久福利| 91精品国产91久久久久久青草| 久久久99精品一区二区| 国产aⅴ激情无码久久| 亚洲嫩草影院久久精品| 久久涩综合| 久久综合久久综合九色| 亚洲精品美女久久久久99| 久久国产福利免费| 国产精品久久网| 亚洲精品乱码久久久久久 | 麻豆亚洲AV永久无码精品久久| 91精品国产综合久久精品| 模特私拍国产精品久久| 色成年激情久久综合| 久久这里只有精品首页| www亚洲欲色成人久久精品| 蜜臀久久99精品久久久久久小说 | 久久中文字幕精品| 国产成人综合久久久久久| 少妇精品久久久一区二区三区| 亚洲国产综合久久天堂| 91精品国产高清久久久久久91| 99久久精品国内| 国产V亚洲V天堂无码久久久| 亚洲αv久久久噜噜噜噜噜| 麻豆久久久9性大片| 久久人人爽人爽人人爽av| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 色偷偷888欧美精品久久久| …久久精品99久久香蕉国产 | 精品免费久久久久国产一区 | 97超级碰碰碰久久久久| 国产精品久久网| 久久久久综合网久久| 国产高潮久久免费观看|