其他

對於英文文檔，其分詞的過程很簡單。中文文本的分類難度較大，主要是因為漢語分詞問題的困難，即為此需要建立完整的漢語概念體系、漢語文法、語義和語用分析是十分複雜的。 lucene包內建的三種中文分詞：以“我是中國人”這句話作分詞舉例1.StandardAnalyzer：我－是－中－國－人2.CJKAnalyzer：我是－是中－中國－國人3.SmartChineseAnalyzer：我－是－中國－人第一種是一元分詞，第二種是二元分詞，第三種應該比較複雜了，沒看源碼，我猜應該是根據中文語義來分的，有興趣

在前面已經安裝好的glusterfs基礎上，用兩台虛擬機器test1,test2來分布式儲存測試，IP分別為：192.168.30.6,192.168.30.71.首先確保這兩台虛擬機器執行sudo /etc/init.d/glusterd start啟動正常2.用其中一台來執行gluster命令，形式分布式叢集，例如本人用的是test1(192.168.30.6)這台機器來3.在test1這台機器上，首先執行sudo gluster peer probe

 運行官網上的mahout kmeas樣本，結果檔案夾有clusteredPoints，clusters-N，data，用命令mahout seqdumper仔細看了一下結果檔案clusteredPoints：存放的是最後聚類的結果，將cluster-id和documents-id都展示出來了，用mahout

因為solr產生的索引是放在本地磁碟的，為了把搜尋索引放到HDFS上，所以最近看了一下搭建分布式Nutch和Nutch+solr的整合Nutch的抓取流程：對目標網站完成抓取後， 在儲存抓取資料目錄crawl 下產生了五個子目錄： crawldb，linkdb，segments，indexes 和 index 。資料庫 crawldb 中包含頁面的數目等；linkdb 包含頁面在資料庫中的連結，這是抓取器真正抓取網站時由頁面的連結數目決定；Segments

學習設計模式的過程應該是一個迭代的過程，學東西的時候不用追求一遍就掌握、理解透徹（很多情況也是不可能的）。看書看不懂、思想沒有理解，可以反覆去讀、去思考。因為實戰經驗少，書中給出的例子也有限，所以設計模式的學習可以先大概按書中的例子理解，至於真正應用，可以在後面實踐中嘗試將這些思維融合到考慮過程中。先將這些模式大概瞭解一下，因為現在實戰有限，所以很多模式只能表層體會，後面有時間再回過頭來再重新學習，可能會有更深層次的體會1.裝飾模式定義：動態地給一個對象添加一些額外的職責（不重要的功能，只是偶然

題目描述：設有n個正整數，將它們串連成一排，組成一個最小的多位整數程式輸入：n個數程式輸出：串連成的多位元例如：n=2時，2個整數32，321串連成的最小整數為：32132n=4時，4個整數55，31，312，33串連成的最小整數為：312313355實現代碼如下：#include <iostream>#include <string>using namespace std;//將整數轉換成字串來比較int cmp(char* strA,char*

提出問題-分析問題-解決問題，這是一般寫議論文的常規思路，正是通常文章採用這種方法來寫的，所以學習一種理論，也是順著這個思想來的，學習設計模式也不例外。在學任何一種模式前，一定要首先搞清楚這種模式產生的背景，即實際編碼或修改維護代碼中遇到的問題，然後分析出現的問題，是否違背了設計模式的原則或物件導向的思想，然後在引出解決這個問題用到的設計模式，最後對比總結，歸納出此種模式適用的場合及優缺點。1.Factory

nutch-1.0 的分布式查詢部署    nutch-1.0整合了hadoop的mapreduce實現分布式爬蟲方式，抓取的網頁及索引等都存放在HDFS上，但hdfs用於查詢是不切實際的，所以建議copy到本地之後做搜尋查詢。但如果索引檔案很多，索引資料量大，在一台機器上部署查詢勢必很慢，這時可以考慮分散式查詢方式，將索引分散在多個機器中；下面是分散式查詢方式的部署方式：首先定義兩點：1. search-servers.txt 所在的機器為主節點，設IP為172.16.100.1；2.

通過近一段時間的學習，大概看了一些模式，可是還是很困惑，看了之後好像沒有留下什麼深刻印像，當時看的時候好像挺懂，但沒有練習，導致現在不知道怎麼運用到實際中，估計是沒有對它們進行仔細比較，所以想著等後面遇到具體問題時，在分析問題的過程中，再將設計模式的思想融入進去再寫出來。關於設計模式的學習，先告一段落，最近工作也簽了，可以重新開始論文方面的工作了。在學校，一般做的都是小程式，所以一般很少用到設計模式思想，而且一個程式完成後,可能就永遠不會再改了，所以都是怎麼簡單實現就怎麼做，而在公司做的東西，會

 1、選秀節目打分，分為專家評委和福士評委，score[] 數組裡面儲存每個評委打的分數，judge_type[] 裡儲存與 score[] 數組對應的評委類別，judge_type[i] == 1，表示專家評委，judge_type[i] == 2，表示福士評委，n表示評委總數。打分規則如下：專家評委和福士評委的分數先分別取一個平均分（平均分取整），然後，總分 = 專家評委平均分  * 0.6 + 福士評委 * 0.4，總分取整。如果沒有福士評委，則 總分 =

 1.簡單原廠模式先看範例程式碼，然後結合例子說明問題，理論聯絡執行個體是初學者入門的最好方法下面是實現一個簡單計算機的小例子Operation.h#include <iostream>using namespace std;class Operation{private:double _numberA;double _numberB;public:double getNumberA(){return _numberA;}void setNumberA(double value)

 1.四則混合運算input=“1+4*5-8/3”，output=19#include <iostream>#include <stack>using namespace std;//不帶括弧的四則運算，如果帶括弧，操作符的優先順序就有'='//比較兩個操作符的優先順序char optCompare(char a,char b){if(a=='+' || a=='-'){if(b=='+' || b=='-'){return '>';}else{return '&

原文出自於：http://www.cnblogs.com/chenlong/archive/2009/10/20/1586952.html什麼是物件導向    剛接觸編程的時候，多數人本能的反映可能是面向過程(OP)的，而不是物件導向(OO)的。這種現象其實是很正常的，改變思維方式是需要一個過程的，我大體歸納了一下其形成的原因：1、直接原因    你還沒有養成物件導向分析問題和解決問題的習慣。建立物件導向的思維方式需要一定時間的訓練和揣摩才能形成，所以你可以在學習或具體項目中刻意地強化這種意識。

大資料需要大檔案系統，這就是開放源碼的 GlusterFS 檔案系統在即將發布的GlusterFS 3.3版本的設計目標。Gluster 項目在本周出了GlusterFS 3.3的第二個測試版本，最終發行版預計在今年年底前。新的發行版提供了與Apache Hadoop 的整合點，可以讓Hadoop使用者使用Gluster儲存。對於Gluster，其檔案系統和 Hadoop 的 HDFS （Hadoop 檔案系統）都是註冊的(comptable不會翻譯)，但是 Gluster

1.統計單詞頻率#include <iostream>#include <string>#include <map>#include <vector>using namespace std;void countWord(char *ptr,char *highword,char *lowword){map<string,int> word;string input=ptr;//char temp[10]={0};string temp;

設計模式對理解物件導向的三大特徵有很好的啟發，不看設計模式，很難深層地體會到物件導向開發帶來的好處在剛開始學習中，很難做到將這些模式融匯貫通，所以這個需要我們在編碼前多思考，等想充分了，在開始實踐編碼，就像一篇作文一樣，如果思維信馬由韁，想到哪寫到哪，那將很容易偏離主題，顯得整篇文章混亂不堪。可以看到現在很多考試，真正讓考生去寫的並不多，重點都放到考察考生的思維過程中去了。所以在做任何一件事情前，總體設計(即作文構思)要充分考慮，細節可以先不用管，就像盜夢空間，剛開始規劃時，就是三層夢境，每一層

7.3 Hello World：運行一個簡單的聚類執行個體(這個內容，我在前面博文“mahout中的kmeans簡單一實例”中已介紹過)7.4 Exploring distance measures(距離度量擴充)在上面的簡單聚類樣本中，我們用的是EuclideanDistanceMeasure(歐式距離)來計算點之間的距離。雖然它在我們上節的聚類執行個體中被證明是有效度量方法，但在Mahout包中還有其他相似的度量方法實現。這些類被命名為 DistanceMeasure(距離度量)

      很長一段時間不寫部落格了，因為最近要弄論文，但看到我的部落格上被CSDN加了個“恒”的小表徵圖，要求是每個月發四篇日誌以上，以鼓勵大家多把東西拿出來分享。這一點其實挺好的，很多程式員擅長於編碼，但並不一定講解的很好或清晰的寫出來。一個技術牛人曾說過：技術人員能把一項技術完成，僅能得及格分，如果能把操作過程寫下來，能得70分，而如果能做好、能寫出來，並且清晰的講給大家聽，那才可以得滿分。    

由於工作上班了，很長時間沒有上CSDN，抱歉有幾位兄弟的問題也沒能及時回覆，好多當時做的東西也忘了，果然是好記性比不過爛筆頭，寫日記是個很好的習慣，以前不覺得，工作後更是發現日記是個好東西，簡單說一下三件事:1.今天做了什麼 2.今天遇到了什麼問題 3.明天準備做什麼