其他

今天碰到了這樣一個Bug：有一個InputStream A，A中有10個位元組的資料可讀,，兩個BufferedReader B1、B2封裝了A。先調用了B1的read方法，正常執行。再調用B2的read方法，發現讀不到資料。思索半天，得出一個猜想，B1把A中的全部資料都讀進了自己的緩衝去，於是B2再讀的時候A中已經沒有資料了。於是，我寫了下面一個小例子：byte[] buf="Hello Leen\nhello".getBytes();InputStream input=new

面對分詞系統中的具名實體識別已經很難下手提高精度，中斷了一段時間去做完了一個有趣的拼音IME，在快撰寫完相關專利申請文稿的時候，又有些百無聊賴了，想想下面又要回去面對那個代碼似乎已經很漂亮而精度卻難於提升的分詞標註系統，一片空白。自然語言處理行當就是如此，總會遇上難題，很愁，又難以繞過，只能冥思苦想。好多天來，我都近乎無可奈何，這種狀態會讓我覺得空虛度日。昨天博士問我下面NER怎麼進行，我敷衍說先看看論文吧。今天他又談及系統的錯誤切分，為了不再敷衍人家，我開始先分析現在的瓶頸（其實是在拖延時間好

問題背景並發量是多線程系統的一個效能瓶頸。制約系統並發量的直接因素是線程數。在資源一定的情況下，線程數有個臨界值，一旦超過這個臨界值系統的效能就會隨線程增加而降低。所以，一般伺服器都會設定一個最大線程數，這個數值也就是並發量的最大值。上述情況帶來了一個效能問題，那就是：有可能系統中的其它資源還有空餘，但並發量達到了最大值，以至於系統不能處理更多的任務。試想，如果將系統改為單線程運作，那麼線程數這個制約因素就會消失，系統的效能就會提升到一個更高的水平。那麼，問題就出現了，什麼樣的系統可以單線程運作

偵錯工具時,出現“System.StackOverflowException”類型的異常！解決：這在修改表單控制項時容易碰到，將對應表單檔案resx檔案開啟，移除資源即可然後我又上網搜了一下，發現有一些代碼也可能會導致這個異常，大致如下：1、使用了一個或多個非常非常大的對象（比如一個幾千萬字的字串或對一篇長文章沒有使用StringBuilder而直接用string類進行加減和replace等操作）      2、使用了層次很深的遞迴調用（可能是無限遞迴。。）因為在父函數進入子函數的時候需要把父函

聽說哈工大和計算所有句法分析開源，滿懷欣喜地想借鑒一下研究之作，卻沒想其層層設限，根本無從下載。大悟，原來這就是他們所謂的開源！揣想我們中文自然語言處理的舉步不前，難道和這些可笑的“敝帚自珍”之舉毫無關係嗎？其實即算能夠付諸實用的句法分析器也不過是個小的cookie而已，談何以怕人商用而徒加屏障呢，須知商用的東西比之高校個人之作而言要有太多的講究，真是可笑。憤怒之餘，亦是無奈，只得愈加努力，希望早日看到sourceforge上我的開源之作可以帶給別人一點點有益的借鑒，讓更多的人去完善中文句法分析

    sogouIME推出不到一年，號稱以詞庫之技領先，雖市場未有盛氣淩人之勢，卻在網路大亨google倉促推出的IME下，名聲大噪（這樣說有點誇張，不過“抄襲”事件的確在無意中讓更多人知道了sogouIME），同時也讓google中國陷入難以脫困的“詞庫門”事件，估計自稱深諳中國文化的google中國高層也沒有想到自己竟然讓“有意栽花花不放，無心插柳柳成陰”的中國賢文成了詛咒！   

一、什麼是Intent：在一個Android應用中，Intent是對執行某個操作的一個抽象描述，Intent 負責提供組件之間相互調用的相關資訊傳遞，實現調用者和被調用者之間的解耦。二、Intent的屬性：Intent是對執行某個操作的一個抽象描述，其描述的內容包括，對執行動作Action的描述、對操作資料的描述、還有4種附加屬性的描述。分別介紹如下：Action ，對執行動作的描述，是個字串，是對所將執行的動作的描述，在Intent類中定義了一些字串常量作為標準動作，譬如：public

最佳化原理  

緩衝區有主要有兩個作用，第一，提高傳輸效率。第二，解決速度不匹配問題。1、提高傳輸效率緩衝區通過增加單次傳輸的資料量來減少資料傳送的次數，所以提高了資料轉送的效率。至於為什麼減少資料傳送次數可以提高效率，需要參考IO方面的知識。下面的Java代碼示範了使用緩衝區與不使用緩衝區，輸出同樣的資料所消耗的時間：int count=1000000;FileOutputStream out = new

    採用取成員函數指標的地址的方法，先把指向成員函數指標的指標強制轉化為別的類型，如unsigned*，當然同樣可以通過此轉化後的指標經過相反的變換來調用成員函數。於是乎要轉化為void*的問題也隨之可解，如下樣本：/* VS2003下編譯運行 */class AbstractMethod{public: virtual void show(){}  // = 0;  // 可以是純虛函數，這裡為了測試方便不使用純虛函數！ void fun() {  cout << "I

    多維拼音IME“秀才”版本(1.0正式版)在beta版本發布半年後發布，其間因為工作上的波折，時間和精力上都讓我無暇顧及IME的改進，致使其時間上有所拖延。經過多方面的努力，“秀才”版本之於beta版本，無論是演算法還是介面上都進行了比較大的改進。    多維拼音IME首頁仍然採用sourceforge：http://davepy.sourceforge.net/    多維拼音IME的相關討論仍然在其專用blog上：http://davepy.spaces.live.com/    1

   游標跟隨是IME系統最常見的特性。要實現這一特性，需要擷取IME支援程式（最常見如word，notepad等）中插入符號caret的座標位置。在Windows的IME環境中，可以通過使用IME核心資料結構INPUTCONTEXT的cfCompForm成員來擷取IME宿主程式中文本游標位置。cfCompForm具有如下結構：typedef tagCANDIDATEFORM {

    一直對Lemur有所熟悉，有感於國外大學在研究和實踐上的並駕齊驅，特翻譯並撰寫Indri開源搜尋引擎的相關文章，以供志趣相同者共同參考。    Indri是一個完整的開源搜尋引擎，由卡耐基－梅隆大學Lemur項目組維護並持續開發。儘管只是Lemur資訊擷取工具系列的一部分，然而由於其使用最新的語言模型，高效的索引技術，完整的搜尋引擎解決方案，不乏為搜尋相關專業及愛好者研究之典範。    支援結構化查詢語言 (SQL)INQUERY；   

     留意過bbs上合集的同學可能會發現，一個火的文章，跟者雲集，並且跟貼的話題頻頻變化，但是一般最後會回到最初的主題上來，看看水木上主題豐富熱火朝天的WL板塊就知道。雖然經常瀏覽合集，但是起初這個現象我倒沒有留心，偶爾一次lp在旁邊嘀咕，說這種五花八門的回帖要是有個程式分析一下輸出一個映像，就像google trends一樣，那感情有趣。   

STL中的容器主要分兩類，一是順序儲存的，如vector；一是以紅/黑樹狀結構形式儲存的，如map。下面分別以vector和map為例，說明怎樣利用迭代器在遍曆的同時刪除容器內元素。下面樣本程式首先往容器中添加一定元素，然後迴圈刪除其中連續或不連續的元素。程式在VS2003以及g++3.4下調試，不同編譯器下可能結果不同。// vector sample for Windows and Linuxint main(){ vector<int>

編寫遞迴程式有幾個重要的原則可以遵循：    1. 要解決的問題可拆分為幾個與原問題類似的子問題（子問題仍可拆分）。    2. 每個子問題必須比原來問題的規模更小（即使小一號也行，當然如果能夠迅速減小規模更好）。    3. 遇到足夠小的子問題時就直接解決之，防止問題無限細分下去，也就是防止無限遞迴（遞迴終止條件很重要）。 先看一個最簡單的遞迴程式，下面程式求整數n的階乘：int factorial(int n){    return n <= 1 ? 1 :

鑒於上次“如此開源”之痛，所以花了幾天時間，邊看《誅仙》邊完成了一個通用的中文句法分析器，採用Earley的Chart Parsing演算法，當然也基於我強大的中文分詞標註一體化系統。偶然想到在這個一體化系統上再融合進句法分析，實在是一個不錯的升華想法，不過還沒有弄到Penn Chinese

為了維護和更新的方便，多維拼音IME現在主要通過其官方部落格以及Sourceforge上的davepy項目對外進行展示，相關地址清單如下，隨著新版本的發布，此列表中有可能繼續增加，屆時將會對其進行及時更新。Sourceforge中davepy項目首頁：http://davepy.sourceforge.net/Sourceforge中davepy：https://sourceforge.net/projects/davepy/部落格通blogtom提供的高速下載：http://www.blogt

多維拼音IMEDavepy戴維作品 　 多維拼音IME Davepy V1.0 Beta 簡體中文版姓　　名：多維拼音IME (Davepy)綽　　號：書生 (Beta版本)修鍊等級：1 (1.0版本)獨門絕技：智能提示，音形混合輸入擅長功夫：強大流暢的整句輸入，發達的智能記憶與自學習機制更新時間：2007-1-1