• <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)自強(qiáng)而不息

            【ZT】哈希的原理和代價(jià)

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

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

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

            姓名 性別 年齡 學(xué)號(hào)
            張三 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ù)雜度會(huì)保持在log2n的范圍之內(nèi)。

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

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

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

            看看大體流程:


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

            a)直接定址法:

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

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

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

            .....
            這樣的一種定址方式,簡(jiǎn)單方便,適用于元數(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)鍵字被某個(gè)不大于哈希表表長(zhǎng)m的數(shù)p除后所得余數(shù)為哈希地址。H(key)=key MOD p (p<=m)

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

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

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

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

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


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

            評(píng)論

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

            cool  回復(fù)  更多評(píng)論   

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

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

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

            cool  回復(fù)  更多評(píng)論   

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

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


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


            公告

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            隨筆分類(178)

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

            搜索

            最新評(píng)論

            777午夜精品久久av蜜臀| 久久久噜噜噜久久熟女AA片| AV狠狠色丁香婷婷综合久久| 人妻久久久一区二区三区| 久久精品亚洲中文字幕无码麻豆| 狠狠色丁香久久婷婷综合五月| 99麻豆久久久国产精品免费| 久久久久亚洲AV无码专区桃色 | 久久精品九九亚洲精品| 91精品国产高清久久久久久io| 久久精品视频91| 久久这里只有精品18| 久久精品无码专区免费| 久久丫精品国产亚洲av不卡| 国产精品一区二区久久精品无码| 免费无码国产欧美久久18| 热久久这里只有精品| 人妻久久久一区二区三区| 久久这里只有精品视频99| 丰满少妇高潮惨叫久久久| 亚洲精品无码专区久久同性男| 97久久精品午夜一区二区| 国内精品久久久久影院薰衣草| 色综合久久综合网观看| 一本色道久久HEZYO无码| 欧美无乱码久久久免费午夜一区二区三区中文字幕 | 中文字幕热久久久久久久| 国产女人aaa级久久久级| 久久精品国产99久久无毒不卡| 久久亚洲精品成人无码网站| 欧美麻豆久久久久久中文| 国产精品久久久久久久久| 久久精品中文闷骚内射| 亚洲国产精品无码久久久蜜芽 | 99久久人妻无码精品系列| 99久久国产精品免费一区二区| 亚洲午夜无码AV毛片久久| 色99久久久久高潮综合影院 | 老男人久久青草av高清| 偷偷做久久久久网站| 亚洲综合精品香蕉久久网|