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

            step by step

             

            散列3

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

            1.再散列
               其實就是前兩篇中有提到的rehash了,對于使用平方探測的開放定制散列法,如果表的元素填得太滿,那么操作的運行時間將開始消耗過長,且插入操作可能失敗。這可能發生在有太多刪除和插入混合的場合。此時,一個解決方法是建立另外一個大約兩倍大的表(而且使用一個相關的新散列函數),掃描整個原始散列表,計算每個(未刪除的)元素的新散列值并將其插入到新表中。整個操作成為再散列(rehashing)。這顯然是一種非常昂貴的操作;其運行時間為O(N),因為有N個元素要再散列而且表的大小約為2N,不過,因為不是經常發生,所以實際效果并沒有這么差。特別是,在最后的再散列之前已經存在N/2次插入,因此添加到每個插入上的花費基本是一個常數開銷。如果這種數據結構是程序的一部分,那么其影響是不明顯的。另一方面,如果再散列作為交互系統一部分運行,那么其插入引起再散列的用戶將會感到速度減慢。
                再散列可以用平方預測以多種方法實現。一種做法是只要表滿一半就再散列。另一種極端的方法是只有當插入失敗時才再散列。第三種方法即途中(middle-of-the-road)策略:當表到達某一個裝填因子時進行再散列。由于隨著裝填因子的增加,表的性能的確在下降,因此,以好的截至點實現的第三種策略,可能是最好的策略。
             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.標準庫中的散列表
                標準庫中不包括set和map的散列表實現。但是,許多的編譯器提供具有與set和map類相同的成員函數的hash_set和hash_map.
                要使用hash_set和hash_map,就必須有相應的包含指令,而且,可能也需要相應的命名空間。這兩者都是和編譯器相關的。接下來還必須提供相應的類型參數來說明
            hash_set和hash_map。對于hash_map,這些類型參數包括鍵的類型,值的類型,散列函數(返回無符號整數)和一個相等性操作符。遺憾的是,至于鍵和值的類型參數如何
            表示還是編譯器相關的。
                下一次c++的較大的修訂將不可避免地包括這些hash_set和hash_map中的一個。

            3.可擴散列
                最后討論數據量太大以至于裝不進主存的情況,此時主要考慮的是檢索數據所需的磁盤存取次數。假設在任意時刻都有N個記錄要存儲,N的值隨時間而變化。此外,最多可把M個記錄放入一個磁盤區塊,設M=4,如果使用探測散列或分離鏈接散列,那么主要的問題在于,即使是理想分布的散列表,在一次查找操作中,沖突也可能引起對多個區塊的訪問。不僅如此,當表變得過慢的時候,必須執行代價巨大的再散列這一步,它需要O(N)的磁盤訪問。
                一種聰明的選擇成為可擴散列(extendible hashing),它允許用兩次磁盤訪問執行一次查找。插入操作也需要很少的磁盤訪問.
               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.小結
                散列表可以用來以常數平均時間實現insert和contains操作。當使用散列表時,注意諸如裝填因子這樣的細節是特別重要的,否則時間界將不再有效。當鍵不是短字符串或整數時,仔細選擇散列函數也是很重要的。
                對于分離鏈接散列法,雖然裝彈因子不大時性能并不明顯降低,但裝填因子還是應該接近于1,對于探測散列,除非完全不可避免,否則裝填因子不應該超過0.5,如果使用線性探測,那么性能隨著裝填因子接近于1而急速下降。再散列運算可以通過使表增長(或收縮)來實現,這樣可以保持合理的裝填因子。對于空間緊缺并且不可能聲明巨大散列表的情況,這是很重要的。
                二叉查找樹也可以用來實現insert和contains操作。雖然平均時間界為O(logN),但是二叉查找樹也支持那些需要排序的例程,從而功能更強大,使用散列表不可能找出最小元素。除非準確知道一個字符串,否則散列表也不可能有效地查找它。二叉查找樹可以迅速找到一定范圍內的所有項,散列表卻做不到。不僅如此,因為查找樹不需要乘法和除法,O(logN)這個時間界也不必比O(1)大那么多。
                另一方面,散列的最壞情形一般來自于實現錯誤,而有序的輸入卻可能使二叉樹運行得很差。平衡查找樹實現的代價相當高。因此,如果不需要排序的信息或者不確定輸入是否已經排序,那么就應該選擇散列這種數據結構。
                散列的應用很廣。編譯器使用散列表跟蹤源代碼中聲明的變量,這種數據結構叫做符號表(symbol table)。散列表時這種問題的理想選擇。標識符一般都不長,因此散列函數能夠迅速完成運算。此外,按字母順序排序變量通常也是不必要的。
                散列表適用于任何其節點有實名而不是數字名的圖論問題。這里,當輸入被讀入的時候,定點則按照它們出現的順序從1開始指定為一些整數。再有,輸入很可能有一組按字母順序排列的項。例如,頂點可以是計算機。此時,如果一個特定的計算中心把它的計算機列表成ibm1,ibm2,ibm3...那么,若使用查找樹則在效率方面很可能會有戲劇性的結果。
               散列表的第三種常見的用途實在為游戲編制的程序中。當程序搜索游戲的不同的運動路徑時,它通過計算基于位置的散列函數而跟蹤一些已知的位置(并把對于該位置的移動存儲起來)。如果同樣的位置再次出現,程序通常通過簡單的移動變換來避免昂貴的重復計算。游戲程序的這種一般特點叫做置換表(transposition table).
               散列的另一個用途是在線拼寫檢查程序。如果拼寫檢查程序的主要功能是檢查拼寫錯誤(而非糾正錯誤),那么可以預先將整個詞典進行散列,這樣就可以在常數時間內檢查單詞拼寫。散列表很適合這項工作,因為以字母順序排列單詞并不重要,而以它們在文件中出現的順序顯示錯誤拼寫當然也是可以接受的。

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

            評論

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

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

            如果是為了研究內存管理…… opencv的內存管理其實很磋……
            當然,opencv可能只是為了開發一個足夠庫自身使用的內存管理與動態數據結構而已。就這個需求來說,opencv是達到了。


            但"足夠庫自身使用"不一定就能滿足用戶的所有需求。
            而opencv也不提供任何方法讓用戶擴展它的庫。
            從這方面來說,opencv是相當的鼠目寸光。


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



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

            CvMemStorage實現的是一個"多次取、整體放"的策略。
            所有的動態數據結構都將數據存放在CvMemStorage分配的內存上。
            沒有單獨釋放數據結構中某個元素的方式,只能釋放整個Storage。
            可是opencv沒有定義出一個接口,作為CvMemStorage和CvSeq之間的中間層,而是CvSeq直接使用CvMemStorage。

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

            一句話,opencv需要輸出動態數據結構的算法和CvSeq綁死了,CvSeq又和CvMemStorage綁死了,而CvMemStorage又實現得不咋嘀……
            你要使用opencv嗎?請忍受CvMemStorage……
            相比CvCapture可以繞過去;這個問題幾乎無解。

              回復  更多評論   

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

            @OwnWaterloo
            謝謝您指點,因為我以前只是用過opencv里的函數,從沒有關心它的實現,我的打算是通過學習它的內存機制來加深對它內部結構的了解,并且我現在還在用一個叫mil的庫,它不是開源的,相比較而言,我就選擇opencv來學習,不管怎樣,我覺得opencv還是值得我現在的水平拿來學習的,只有真正學過了,才有資格評論,是吧?  回復  更多評論   

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

            @小羅羅
            只看源碼很枯燥,而且有些細節很難理解。
            看這本書吧:《C語言接口與實現:創建可重用軟件的技術》
            http://www.china-pub.com/14974

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

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

              回復  更多評論   

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

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

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

            @小羅羅
            這…… 那鏈接上不是說已經絕版了嗎?
              回復  更多評論   

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

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

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

              回復  更多評論   

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

            OwnWaterloo ,我下載下來了,現在開始看。


              回復  更多評論   

            導航

            統計

            常用鏈接

            留言簿

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            色妞色综合久久夜夜| 国产精品99久久久久久猫咪| 久久久WWW成人| 久久婷婷国产剧情内射白浆| 午夜久久久久久禁播电影| 四虎国产永久免费久久| 亚洲精品综合久久| 91精品国产色综久久 | 美女写真久久影院| 精品多毛少妇人妻AV免费久久| 久久综合给久久狠狠97色 | 99久久精品国产一区二区三区| 久久本道久久综合伊人| 久久精品国产亚洲AV高清热| 亚洲а∨天堂久久精品9966| 久久精品国产一区二区三区日韩| 波多野结衣久久一区二区| 国产成人香蕉久久久久| 亚洲国产精品无码久久一区二区| 久久精品国产免费| 亚洲精品无码久久久久去q | 亚洲午夜无码AV毛片久久| 久久精品九九亚洲精品天堂| 一本久久免费视频| 久久婷婷五月综合97色直播| 久久婷婷人人澡人人| 青青青国产成人久久111网站| 久久精品国产亚洲AV蜜臀色欲| 久久av免费天堂小草播放| 国产日产久久高清欧美一区| 久久夜色精品国产噜噜麻豆| 久久受www免费人成_看片中文| 中文精品久久久久人妻| 久久精品夜色噜噜亚洲A∨ | 久久精品人人做人人爽电影| 精品久久久久久无码专区不卡| 国产精品久久久久久福利漫画| 99久久99久久精品国产片| 91久久精品电影| 狠狠精品久久久无码中文字幕| 国产精品成人精品久久久|