用excel開啟資料集，有208行60列特徵（值域為0到1），標籤為r/m。表示208個觀察物件，60個不同角度返回的力度值，二分類結果是岩石/金屬。
注：from csv import reader 連線中少了個r
決策樹方差高——引入bagging降低方差——bagging下的樹相似，**相似——引入列取樣（本例中採用特徵數的平方根）
bagging低方差——使用的決策樹需低偏差，要深
load_csv:讀取csv檔案，按行儲存到陣列dataset中。
str_column_to_float:將某列字元去掉前後空格，並轉換為浮點數格式
str_column_to_int：根據分類種類建立字典，標號0,1,2...將字元列轉化為整數
cross_validation_split：使用randrange函式將資料集劃分為n個無重複元素的子集
accuracy_metric：計算準確率
evaluate_algorithm：使用交叉驗證，建立n個訓練集和測試集，返回各模型誤差陣列
test_split：根據特徵及特徵閾值分割左右子樹集合
gini_index：在某個點分成了幾個子節點放在groups中，這些樣本的類有多種，類集合為classes，計算該點基尼指數：
gini=∑按group（1-∑按同一group中的類p^1）*n1/n。
get_split：限定列取樣特徵個數n_features,基尼指數代表的是不純度，gini指數越小越好，對列取樣特徵中的每個特徵的每個 值計算分割下的最小gini值，作為分割依據
to_terminal：輸出group中出現次數最多的標籤，實質上就是多數表決法
split：根據樹的最大深度、葉子節點最少樣本數、列取樣特徵個數，迭代創作子分類器直到分類結束
build_tree：建立一棵樹
predict：用一棵樹**類
subsample：按照一定比例bangging取樣
bagging_predict：用多棵樹模型的**結果做多數表決
random_forest:隨機森林演算法，返回測試集各個樣本做多數表決後的**值
即：對每種樹規模（1,5,10）執行5次，取均值作為最後模型效果。
執行結果：
trees: 1
scores: [56.09756097560976, 63.41463414634146, 60.97560975609756, 58.536585365853654, 73.17073170731707]
mean accuracy: 62.439%
trees: 5
scores: [70.73170731707317, 58.536585365853654, 85.36585365853658, 75.60975609756098, 63.41463414634146]
mean accuracy: 70.732%
trees: 10
scores: [75.60975609756098, 80.48780487804879, 92.6829268292683, 73.17073170731707, 70.73170731707317]
mean accuracy: 78.537%
結果分析：
scores內部差異不大，畢竟只是搞了下交叉驗證。但可以看出隨著trees數目的增加，準確率上公升了
基於RF無線通訊的糧倉監測系統
基於rf無線通訊的糧倉監測系統 糧食在儲存期間，由於環境 氣候和通風條件等因素的變化，糧倉內的溫度或濕度會發生異常，容易造成糧食的腐爛或發生蟲害。同時糧倉中糧食儲存質量還受到糧倉中氣體 微生物以及蟲害等因素的影響。針對糧食儲存的特殊性，糧倉監控系統一般以糧倉和糧食的溫度與濕度為主要檢測引數，糧倉內氣...
基於docker開發的最佳實踐
翻譯自docker官方文件，原文 下面的開發模式已被證明是對基於docker開發應用的人們有幫助的。如果你發現了其他我們應該加入的東西，請告訴我們。小的映象能更快地通過網路拉取而且在啟動容器或服務時能更快地載入到記憶體。下面是一些保持映象小巧的經驗法則 rules of thumb run apt ...
基於Decorator的元件擴充套件實踐
在前端業務開發中，元件化已經成為我們的共識。沉澱和復用元件，是提高開發效率的利器。但在元件復用的過程中，我們往往會遇到這樣的問題，元件相似，卻在結構或互動上有些許差別，需要對元件進行改造方可滿足需求。這個問題之前在 react實踐 component generator 就有所提及。之初，我們提出了...