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

step by step

 

散列3

  散列這是最后一章了,快畢業(yè)了,這幾天趕快把論文寫完,到回家還不到兩個月,答應(yīng)張老師再去實(shí)驗室把做的東西總結(jié)一下,其實(shí)打算在實(shí)驗室再呆兩個月,臘月底再回,想寫的東西嘛,我想研究一下opencv的內(nèi)存管理機(jī)制,結(jié)合我買的那本Applied C++,順便推銷一下這本書,這本書很薄,兩百多頁,介紹如何應(yīng)用c++來解決開發(fā)商業(yè)軟件時所固有的問題,最難能可貴的是,從頭至尾提供了一個圖像處理框架,對于想在數(shù)字圖像處理,機(jī)器視覺方向深入探究(不是具體算法,而是整個軟件架構(gòu))有挺大的啟發(fā)意義的(雖然網(wǎng)上評價不是太好,可能比較牛的人看不上吧,也有可能這本書比較偏重于數(shù)字圖像領(lǐng)域),還想學(xué)的東西呢,年前和年后幾個月的時間Bjarne Stroustrup的那本c++,Mark Allen Weiss的那本數(shù)據(jù)結(jié)構(gòu),Jon Kleinberg 的那本算法設(shè)計,后兩本書是俺在圖像室的圖書角找到的,非常的不錯哦,可惜畢業(yè)前就要還,正好督促我趕緊看,在聯(lián)合書城看到Richard Johnsonbaugh的Discrete Mathematics,竟然是第七版了,只能怪我資質(zhì)太差看不懂knuth的那三本圣經(jīng),只好咬著牙買下來先琢磨琢磨了算是打基礎(chǔ)了,公司有項目做嵌入式平臺上的編譯器,要是有時間的話看看嵌入式操作系統(tǒng)和編譯原理吧,很想寫個編譯器,這么多好書要看,有時候真不想回家過年了,嘿嘿,說著玩的,到時候家里肯定殺豬了,不回去真是太可惜了。

1.再散列
   其實(shí)就是前兩篇中有提到的rehash了,對于使用平方探測的開放定制散列法,如果表的元素填得太滿,那么操作的運(yùn)行時間將開始消耗過長,且插入操作可能失敗。這可能發(fā)生在有太多刪除和插入混合的場合。此時,一個解決方法是建立另外一個大約兩倍大的表(而且使用一個相關(guān)的新散列函數(shù)),掃描整個原始散列表,計算每個(未刪除的)元素的新散列值并將其插入到新表中。整個操作成為再散列(rehashing)。這顯然是一種非常昂貴的操作;其運(yùn)行時間為O(N),因為有N個元素要再散列而且表的大小約為2N,不過,因為不是經(jīng)常發(fā)生,所以實(shí)際效果并沒有這么差。特別是,在最后的再散列之前已經(jīng)存在N/2次插入,因此添加到每個插入上的花費(fèi)基本是一個常數(shù)開銷。如果這種數(shù)據(jù)結(jié)構(gòu)是程序的一部分,那么其影響是不明顯的。另一方面,如果再散列作為交互系統(tǒng)一部分運(yùn)行,那么其插入引起再散列的用戶將會感到速度減慢。
    再散列可以用平方預(yù)測以多種方法實(shí)現(xiàn)。一種做法是只要表滿一半就再散列。另一種極端的方法是只有當(dāng)插入失敗時才再散列。第三種方法即途中(middle-of-the-road)策略:當(dāng)表到達(dá)某一個裝填因子時進(jìn)行再散列。由于隨著裝填因子的增加,表的性能的確在下降,因此,以好的截至點(diǎn)實(shí)現(xiàn)的第三種策略,可能是最好的策略。
 1//對探測散列表和分離鏈接散列表的再散列
 2void rehash()
 3{
 4    vector<HashEntry> oldArray = array;
 5    array.resize( nextPrime( 2* oldArray.size() ) );
 6    forint j = 0; j<array.size(); j++ )
 7        array[j].info = EMPTY;
 8    currentSize = 0;
 9    forint i = 0; i<oldArray.size(); i++ )
10        if( oldArray[i].info == ACTIVE )
11            insert( oldArray[i].element );
12}

13
14void rehash()
15{
16    vector<list<HashedObj> > oldLists = theLists;
17    theLists.resize( nextPrime( 2* theLists.size() ) );
18    forint j = 0; j<theLists.size(); j++ )
19        theLists[j].clear();
20    currentSize = 0;
21    forint i = 0; i<oldLists.size(); i++ )
22    {
23        list<HashedObj>::iterator itr = OldLists[i].begin();
24        while ( itr != oldLists[i].end() )
25            insert( *itr++ );
26    }

27}


2.標(biāo)準(zhǔn)庫中的散列表
    標(biāo)準(zhǔn)庫中不包括set和map的散列表實(shí)現(xiàn)。但是,許多的編譯器提供具有與set和map類相同的成員函數(shù)的hash_set和hash_map.
    要使用hash_set和hash_map,就必須有相應(yīng)的包含指令,而且,可能也需要相應(yīng)的命名空間。這兩者都是和編譯器相關(guān)的。接下來還必須提供相應(yīng)的類型參數(shù)來說明
hash_set和hash_map。對于hash_map,這些類型參數(shù)包括鍵的類型,值的類型,散列函數(shù)(返回?zé)o符號整數(shù))和一個相等性操作符。遺憾的是,至于鍵和值的類型參數(shù)如何
表示還是編譯器相關(guān)的。
    下一次c++的較大的修訂將不可避免地包括這些hash_set和hash_map中的一個。

3.可擴(kuò)散列
    最后討論數(shù)據(jù)量太大以至于裝不進(jìn)主存的情況,此時主要考慮的是檢索數(shù)據(jù)所需的磁盤存取次數(shù)。假設(shè)在任意時刻都有N個記錄要存儲,N的值隨時間而變化。此外,最多可把M個記錄放入一個磁盤區(qū)塊,設(shè)M=4,如果使用探測散列或分離鏈接散列,那么主要的問題在于,即使是理想分布的散列表,在一次查找操作中,沖突也可能引起對多個區(qū)塊的訪問。不僅如此,當(dāng)表變得過慢的時候,必須執(zhí)行代價巨大的再散列這一步,它需要O(N)的磁盤訪問。
    一種聰明的選擇成為可擴(kuò)散列(extendible hashing),它允許用兩次磁盤訪問執(zhí)行一次查找。插入操作也需要很少的磁盤訪問.
   Extendible hashing from Wikipedia
   Extendible hashing
is a type of hash system which treats a hash as a bit string, and uses a trie for bucket lookup. Because of the hierarchal nature of the system, re-hashing is an incremental operation (done one bucket at a time, as needed). This means that time-sensitive applications are less affected by table growth than by standard full-table rehashes.

   

This is a more simplistic example from Fagin et al. (1979).

Assume that the hash function h(k) returns a binary number. The first i bits of each string will be used as indices to figure out where they will go in the "directory" (hash table). Additionally, i is the smallest number such that the first i bits of all keys are different.

Keys to be used:

h(k1) = 100100
h(k2) = 010110
h(k3) = 110110

Let's assume that for this particular example, the bucket size is 1. The first two keys to be inserted, k1 and k2, can be distinguished by the most significant bit, and would be inserted into the table as follows:

 directory
---------
|    0    |-----------> Bucket A (contains k2)
|---------|
|    1    |-----------> Bucket B (contains k1)
---------

Now, if k3 were to be hashed to the table, it wouldn't be enough to distinguish all three keys by one bit (because k3 and k1 have 1 as their leftmost bit. Also, because the bucket size is one, the table would overflow. Because comparing the first two most significant bits would give each key a unique location, the directory size is doubled as follows:

  directory
----------
|    00    |-----\
|----------|      ----------> Bucket A (contains k2)
|    01    |-----/
|----------|
|    10    |-----------> Bucket B (contains k1)
|----------|
|    11    |-----------> Bucket C (contains k3)
----------

And so now k1 and k3 have a unique location, being distinguished by the first two leftmost bits. Because k2 is in the top half of the table, both 00 and 01 point to it because there is no other key to compare to that begins with a 0.

4.小結(jié)
    散列表可以用來以常數(shù)平均時間實(shí)現(xiàn)insert和contains操作。當(dāng)使用散列表時,注意諸如裝填因子這樣的細(xì)節(jié)是特別重要的,否則時間界將不再有效。當(dāng)鍵不是短字符串或整數(shù)時,仔細(xì)選擇散列函數(shù)也是很重要的。
    對于分離鏈接散列法,雖然裝彈因子不大時性能并不明顯降低,但裝填因子還是應(yīng)該接近于1,對于探測散列,除非完全不可避免,否則裝填因子不應(yīng)該超過0.5,如果使用線性探測,那么性能隨著裝填因子接近于1而急速下降。再散列運(yùn)算可以通過使表增長(或收縮)來實(shí)現(xiàn),這樣可以保持合理的裝填因子。對于空間緊缺并且不可能聲明巨大散列表的情況,這是很重要的。
    二叉查找樹也可以用來實(shí)現(xiàn)insert和contains操作。雖然平均時間界為O(logN),但是二叉查找樹也支持那些需要排序的例程,從而功能更強(qiáng)大,使用散列表不可能找出最小元素。除非準(zhǔn)確知道一個字符串,否則散列表也不可能有效地查找它。二叉查找樹可以迅速找到一定范圍內(nèi)的所有項,散列表卻做不到。不僅如此,因為查找樹不需要乘法和除法,O(logN)這個時間界也不必比O(1)大那么多。
    另一方面,散列的最壞情形一般來自于實(shí)現(xiàn)錯誤,而有序的輸入?yún)s可能使二叉樹運(yùn)行得很差。平衡查找樹實(shí)現(xiàn)的代價相當(dāng)高。因此,如果不需要排序的信息或者不確定輸入是否已經(jīng)排序,那么就應(yīng)該選擇散列這種數(shù)據(jù)結(jié)構(gòu)。
    散列的應(yīng)用很廣。編譯器使用散列表跟蹤源代碼中聲明的變量,這種數(shù)據(jù)結(jié)構(gòu)叫做符號表(symbol table)。散列表時這種問題的理想選擇。標(biāo)識符一般都不長,因此散列函數(shù)能夠迅速完成運(yùn)算。此外,按字母順序排序變量通常也是不必要的。
    散列表適用于任何其節(jié)點(diǎn)有實(shí)名而不是數(shù)字名的圖論問題。這里,當(dāng)輸入被讀入的時候,定點(diǎn)則按照它們出現(xiàn)的順序從1開始指定為一些整數(shù)。再有,輸入很可能有一組按字母順序排列的項。例如,頂點(diǎn)可以是計算機(jī)。此時,如果一個特定的計算中心把它的計算機(jī)列表成ibm1,ibm2,ibm3...那么,若使用查找樹則在效率方面很可能會有戲劇性的結(jié)果。
   散列表的第三種常見的用途實(shí)在為游戲編制的程序中。當(dāng)程序搜索游戲的不同的運(yùn)動路徑時,它通過計算基于位置的散列函數(shù)而跟蹤一些已知的位置(并把對于該位置的移動存儲起來)。如果同樣的位置再次出現(xiàn),程序通常通過簡單的移動變換來避免昂貴的重復(fù)計算。游戲程序的這種一般特點(diǎn)叫做置換表(transposition table).
   散列的另一個用途是在線拼寫檢查程序。如果拼寫檢查程序的主要功能是檢查拼寫錯誤(而非糾正錯誤),那么可以預(yù)先將整個詞典進(jìn)行散列,這樣就可以在常數(shù)時間內(nèi)檢查單詞拼寫。散列表很適合這項工作,因為以字母順序排列單詞并不重要,而以它們在文件中出現(xiàn)的順序顯示錯誤拼寫當(dāng)然也是可以接受的。

posted on 2009-11-27 17:14 小羅羅 閱讀(999) 評論(7)  編輯 收藏 引用

評論

# re: 散列3 2009-11-27 18:34 OwnWaterloo

研究opencv的內(nèi)存管理? 如果是為了使用opencv,可以去研究。

如果是為了研究內(nèi)存管理…… opencv的內(nèi)存管理其實(shí)很磋……
當(dāng)然,opencv可能只是為了開發(fā)一個足夠庫自身使用的內(nèi)存管理與動態(tài)數(shù)據(jù)結(jié)構(gòu)而已。就這個需求來說,opencv是達(dá)到了。


但"足夠庫自身使用"不一定就能滿足用戶的所有需求。
而opencv也不提供任何方法讓用戶擴(kuò)展它的庫。
從這方面來說,opencv是相當(dāng)?shù)氖竽看绻狻?br>

比如opencv提供的CvCapture。其內(nèi)部是有一個C實(shí)現(xiàn)的capture接口與capture工廠。
可是它不將接口定義暴露給用戶。
用戶需要自己的capture時怎么辦? 等著opencv去支持嗎? 那是不可能的。只能自己動手。
這個需求還好, 大不了讓自己的capture返回image(image or matrix),然后丟給opencv去處理就可以了。
image的格式opencv還算厚道,暴露出來了。
用戶如果想要實(shí)現(xiàn)得好一些,更c(diǎn)apture無關(guān),就需要自己再抽象一個capture接口,然后將opencv的capture包含進(jìn)去 —— 基本就是將CvCapture的代碼再實(shí)現(xiàn)一遍 —— 因為那短視的opencv沒將這個可擴(kuò)展點(diǎn)暴露出來。



如果用戶不滿意CvMemStorage和CvSeq的行為,哼哼……
必須屈服,除非用戶想自己重寫opencv —— 換句話說,就是放棄opencv。

CvMemStorage實(shí)現(xiàn)的是一個"多次取、整體放"的策略。
所有的動態(tài)數(shù)據(jù)結(jié)構(gòu)都將數(shù)據(jù)存放在CvMemStorage分配的內(nèi)存上。
沒有單獨(dú)釋放數(shù)據(jù)結(jié)構(gòu)中某個元素的方式,只能釋放整個Storage。
可是opencv沒有定義出一個接口,作為CvMemStorage和CvSeq之間的中間層,而是CvSeq直接使用CvMemStorage。

CvMemStorage本身也不咋嘀。甚至還有一個單次分配大小的上限……

一句話,opencv需要輸出動態(tài)數(shù)據(jù)結(jié)構(gòu)的算法和CvSeq綁死了,CvSeq又和CvMemStorage綁死了,而CvMemStorage又實(shí)現(xiàn)得不咋嘀……
你要使用opencv嗎?請忍受CvMemStorage……
相比CvCapture可以繞過去;這個問題幾乎無解。

  回復(fù)  更多評論   

# re: 散列3 2009-11-27 20:41 小羅羅

@OwnWaterloo
謝謝您指點(diǎn),因為我以前只是用過opencv里的函數(shù),從沒有關(guān)心它的實(shí)現(xiàn),我的打算是通過學(xué)習(xí)它的內(nèi)存機(jī)制來加深對它內(nèi)部結(jié)構(gòu)的了解,并且我現(xiàn)在還在用一個叫mil的庫,它不是開源的,相比較而言,我就選擇opencv來學(xué)習(xí),不管怎樣,我覺得opencv還是值得我現(xiàn)在的水平拿來學(xué)習(xí)的,只有真正學(xué)過了,才有資格評論,是吧?  回復(fù)  更多評論   

# re: 散列3 2009-11-27 20:56 OwnWaterloo

@小羅羅
只看源碼很枯燥,而且有些細(xì)節(jié)很難理解。
看這本書吧:《C語言接口與實(shí)現(xiàn):創(chuàng)建可重用軟件的技術(shù)》
http://www.china-pub.com/14974

里面的arena,思想和CvMemStorage是一樣的"零取整放"。
CvMemStorage比arena多一些功能。

書里將arena的同時,會把內(nèi)存分配器的一些細(xì)節(jié)說清楚,這些可能是看源代碼多遍都看不出來的。
反正arena章節(jié)也不多……

  回復(fù)  更多評論   

# re: 散列3 2009-11-27 23:44 小羅羅

看了簡介,很不錯的樣子,好的,聽你的,豁出去了,買了  回復(fù)  更多評論   

# re: 散列3 2009-11-27 23:50 OwnWaterloo

@小羅羅
這…… 那鏈接上不是說已經(jīng)絕版了嗎?
  回復(fù)  更多評論   

# re: 散列3 2009-11-27 23:52 OwnWaterloo

http://download.csdn.net/source/747860

掃描版的,湊合著看吧……
源代碼在這里:
http://code.google.com/p/cii/downloads/list

  回復(fù)  更多評論   

# re: 散列3 2009-11-28 00:00 小羅羅

OwnWaterloo ,我下載下來了,現(xiàn)在開始看。


  回復(fù)  更多評論   


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


導(dǎo)航

統(tǒng)計

常用鏈接

留言簿

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            国产精品一区二区在线观看网站| 国产欧美综合在线| 亚洲精品少妇30p| 免费久久久一本精品久久区| 久久精品国产精品亚洲| 一区福利视频| 亚洲高清一区二区三区| 老司机精品导航| 日韩午夜精品| 亚洲手机成人高清视频| 国产视频一区二区在线观看| 久久久国产精品一区二区中文| 欧美在线亚洲在线| 亚洲大胆视频| 一本不卡影院| 国产午夜精品麻豆| 欧美激情免费观看| 国产精品成人免费精品自在线观看 | 亚洲——在线| 在线高清一区| 日韩视频一区二区三区在线播放免费观看 | 亚洲在线一区二区三区| 亚洲欧美日韩精品久久亚洲区| 好吊色欧美一区二区三区视频| 亚洲成人在线视频网站| 欧美午夜精品久久久久免费视| 久久精品日韩一区二区三区| 欧美成人免费全部| 欧美中文字幕在线视频| 免费不卡在线观看| 欧美在线一二三| 欧美国产在线观看| 久久一区中文字幕| 欧美日韩一区二区视频在线观看 | 性欧美xxxx视频在线观看| 久久久久88色偷偷免费| 亚洲视频在线观看视频| 久久综合九色综合欧美狠狠| 小黄鸭精品密入口导航| 久久综合一区二区三区| 亚洲在线第一页| 美女视频黄免费的久久| 久久激情五月丁香伊人| 欧美日韩综合在线免费观看| 亚洲成色777777女色窝| 国产亚洲精品久久久久久| 野花国产精品入口| 99国产精品久久久| 免费中文字幕日韩欧美| 久久午夜影视| 国产日韩高清一区二区三区在线| 亚洲精品欧美一区二区三区| 一区二区在线视频| 欧美在线观看网站| 欧美一区二区三区久久精品| 欧美性猛交xxxx免费看久久久| 亚洲国产福利在线| 在线电影一区| 久久久久久国产精品一区| 欧美一区二区三区播放老司机 | 久久久欧美一区二区| 久久成人在线| 国产日韩欧美在线看| 亚洲直播在线一区| 亚洲影院一区| 国产精品高潮呻吟久久av无限 | 一本色道久久加勒比88综合| 亚洲精品国偷自产在线99热| 母乳一区在线观看| 亚洲国产一区二区精品专区| 亚洲欧洲一级| 欧美女主播在线| 亚洲日韩中文字幕在线播放| 99re成人精品视频| 欧美人与性动交cc0o| 99热在这里有精品免费| 亚洲香蕉视频| 国产精品女人网站| 性久久久久久久久久久久| 久久国产精品久久国产精品| 国产综合色在线视频区| 久久嫩草精品久久久久| 亚洲国产成人精品久久| 亚洲视频免费在线| 国产日韩精品在线| 久久婷婷av| 亚洲三级影院| 性感少妇一区| 在线视频国产日韩| 欧美精品自拍| 亚洲女人小视频在线观看| 久久亚洲综合| 夜夜嗨一区二区三区| 国产精品乱码一区二三区小蝌蚪| 性欧美暴力猛交69hd| 麻豆久久婷婷| 亚洲一区二区精品| 国产亚洲免费的视频看| 免费观看在线综合色| 99re8这里有精品热视频免费| 欧美一区二区黄色| 91久久精品一区| 国产精品久久久免费| 久久亚洲国产精品日日av夜夜| 日韩一级黄色片| 久久久久久一区二区三区| 夜夜夜久久久| 激情综合自拍| 国产精品久久综合| 欧美激情精品久久久六区热门| 在线午夜精品自拍| 欧美激情aaaa| 久久久国产视频91| 亚洲一区二区免费| 亚洲激情av| 国产综合色产在线精品| 欧美日韩天天操| 欧美freesex交免费视频| 亚洲欧美中文另类| 亚洲精品国产精品国产自| 久久综合九色综合久99| 亚洲一区二区成人| 日韩视频在线免费观看| 激情亚洲一区二区三区四区| 国产精品久久久久久久久免费| 欧美v日韩v国产v| 久久激情五月激情| 亚洲一区二区三区中文字幕在线 | 欧美亚洲在线观看| 99精品视频网| 亚洲精品视频在线| 亚洲国产成人午夜在线一区| 牛夜精品久久久久久久99黑人| 欧美在线999| 校园春色综合网| 午夜影院日韩| 亚洲欧美色婷婷| 亚洲在线免费| 亚洲欧美日韩一区二区三区在线观看| 亚洲欧洲午夜| 99xxxx成人网| 日韩视频精品在线| 亚洲久久成人| 日韩亚洲精品在线| 日韩特黄影片| 中文亚洲视频在线| 制服丝袜激情欧洲亚洲| 亚洲视频欧美在线| 亚洲一区二三| 欧美一区二区三区免费在线看| 亚洲欧美日韩成人高清在线一区| 亚洲午夜久久久久久久久电影网| 日韩网站在线看片你懂的| 一本不卡影院| 午夜影院日韩| 麻豆freexxxx性91精品| 欧美成人中文| 亚洲国产一区二区三区在线播| 亚洲精品在线一区二区| 亚洲免费观看高清完整版在线观看| 日韩亚洲欧美一区| 午夜精品久久一牛影视| 久久精品国产清高在天天线| 久久三级福利| 欧美日韩亚洲一区二| 国产精品a久久久久久| 国产一区二区在线免费观看| 狠狠色丁香婷综合久久| 亚洲欧洲在线看| 亚洲午夜精品17c| 久久亚洲影音av资源网| 亚洲精品护士| 新狼窝色av性久久久久久| 久久综合狠狠综合久久综合88| 欧美精品一区二区三区在线播放| 国产精品二区影院| 1000部精品久久久久久久久| 亚洲视屏在线播放| 久久婷婷激情| 99热免费精品| 久久亚洲私人国产精品va| 欧美日韩第一区| 国内成人精品视频| 亚洲深夜影院| 欧美91大片| 亚洲欧美在线一区二区| 欧美成人情趣视频| 国内精品国语自产拍在线观看| 一本大道久久a久久综合婷婷| 久久精品观看| 夜夜嗨av一区二区三区免费区 | 一区二区av| 久久免费视频一区| 国产精品嫩草影院一区二区| 亚洲国产精品专区久久| 性久久久久久久久| 亚洲免费观看高清完整版在线观看熊 | 久久人人爽人人爽| 国产精品综合色区在线观看| 日韩午夜激情电影|