演算法文檔
『壹』 計算機軟體、程序和文檔,以及指令系統有什麼關系
軟體 = 程序+文檔 = 數據結構+演算法+文檔。
打個比方，軟體是一件衣服，那程序就是材料。軟體是由許多能實現某些固定任務的程序的集合。也就是說，軟體是由許許多多的程序組合而成的。程序是由編程人員通過某種編程語言，編寫出來能實現某些固定任務的代碼。
可這么說，編程人員能過 通過c語言或其他某種語言，編寫出一些能實現任務某些固定任務的函數，再把這些函數集合起來，通過編譯程序編成軟體，也就是我們通常在電腦上用的各種軟體了。
軟體和系統的關系：應用程序是軟體，操作系統也是軟體。cpu會將他們一視同仁，甚至，cpu不知道自己在執行的程序是操作系統還是一般應用軟體，cpu只知道去寄存器中指向的內存取指令並執行，它不知道什麼是操作系統，也無須知道。
操作系統是人想出來的，為了讓自己管理計算機方便而創造出來的一套管理辦法。應用程序要用某種語言編寫，而語言又是編譯器來提供的。其實根本就沒有什麼語言，有的只是編譯器。是編譯器決定怎樣解釋某種關鍵字及某種語法。
語言只是編譯器和大家的約定，只要寫入這樣的代碼，編譯器便將其翻譯成某種機器指令，翻譯成什麼樣取決於編譯器的行為，和語言無關，比如說c語言的printf函數，它的功能不是說一定要把字元列印到屏幕上，這要看編譯器對這種關鍵字的處理。
『貳』 演算法文檔怎麼寫
雞數=輸入雞數*2-輸入免數/2免數=輸入兔數/2-輸入雞數
『叄』 《演算法技術手冊第二版》pdf下載在線閱讀全文，求百度網盤雲資源
《演算法技術手冊第二版》網路網盤pdf最新全集下載:
鏈接：https://pan..com/s/1lCJqt0TaWP-kMsgwLvBObQ
簡介：本書使用實際代碼而非偽代碼來描述演算法，並以經驗主導支撐數學分析，側重於應用且規范嚴謹。本書提供了用多種程序設計語言實現的文檔化的實際代碼解決方案，還介紹了近40種核心演算法，其中包括用於計算點集的Voronoi圖的Fortune演算法、歸並排序、多線程快速排序、AVL平衡二叉樹實現以及空間演算法。
『肆』 word文檔加密演算法
下面我給出幾個加密的方法：
文件菜單設置：1、打開需要加密的Word文檔。2、選「文件」的「另存為」，出現「另存為」對話框，在「工具」中選「常規選項」，出現「保存」選項卡。3、分別在「打開許可權密碼」和「修改許可權密碼」中輸入密碼（這兩種密碼可以相同也可以不同）。4、再次確認「打開許可權密碼」和「修改許可權密碼」。按「確定」退出「保存」選項卡。5、文件存檔。
由工具菜單設置：1、打開需要加密的Word文檔。2、選「工具」菜單的「選項」命令，出現「選項對話框」。3、在「選項」對話框中選「保存」選項卡。4、分別在「打開許可權密碼」和「修改許可權密碼」中輸入密碼，點「確定」退出。5、將文件保存。
對模板加密
如果我們不想別人使用Word提供的通用模板（Narmal.dot）或自己精心創作的一個模板，可以對該模板進行加密，其方法是：1、打開通用模板文件（文件名是Narmal.dot，通常可以在C：＼ProgramFiles＼Mi－crosoft＼Templetas文件夾中找到）。2、按上面的兩種方法設置密碼。3、點「工具欄」中的保存（或選「文件」菜單的「保存」）。以後每次啟動Word時，就會提示你輸入密碼。
『伍』 程序等於演算法加文檔對嗎
不對。
程序等於數據結構加演算法目前正在做一個證券行業的項目，之前沒有在這個行業的案例。在開發的長路漫漫中，修改重構是在所難免的。
『陸』 Raft 演算法（詳細版）
在分布式系統中，一致性演算法至關重要。在所有一致性演算法中，Paxos 最負盛名，它由萊斯利·蘭伯特（Leslie Lamport）於 1990 年提出，是一種基於消息傳遞的一致性演算法，被認為是類似演算法中最有效的。
Paxos 演算法雖然很有效，但復雜的原理使它實現起來非常困難，截止目前，實現 Paxos 演算法的開源軟體很少，比較出名的有 Chubby、LibPaxos。此外，Zookeeper 採用的 ZAB（Zookeeper Atomic Broadcast）協議也是基於 Paxos 演算法實現的，不過 ZAB 對 Paxos 進行了很多改進與優化，兩者的設計目標也存在差異——ZAB 協議主要用於構建一個高可用的分布式數據主備系統，而 Paxos 演算法則是用於構建一個分布式的一致性狀態機系統。
由於 Paxos 演算法過於復雜、實現困難，極大地制約了其應用，而分布式系統領域又亟需一種高效而易於實現的分布式一致性演算法，在此背景下，Raft 演算法應運而生。
Raft 演算法在斯坦福 Diego Ongaro 和 John Ousterhout 於 2013 年發表的《In Search of an Understandable Consensus Algorithm》中提出。相較於 Paxos，Raft 通過邏輯分離使其更容易理解和實現，目前，已經有十多種語言的 Raft 演算法實現框架，較為出名的有 etcd、Consul 。
根據官方文檔解釋，一個 Raft 集群包含若干節點，Raft 把這些節點分為三種狀態：Leader、 Follower、Candidate，每種狀態負責的任務也是不一樣的。正常情況下，集群中的節點只存在 Leader 與 Follower 兩種狀態。
• Leader（領導者） ：負責日誌的同步管理，處理來自客戶端的請求，與Follower保持heartBeat的聯系；
• Follower（追隨者） ：響應 Leader 的日誌同步請求，響應Candidate的邀票請求，以及把客戶端請求到Follower的事務轉發（重定向）給Leader；
• Candidate（候選者） ：負責選舉投票，集群剛啟動或者Leader宕機時，狀態為Follower的節點將轉為Candidate並發起選舉，選舉勝出（獲得超過半數節點的投票）後，從Candidate轉為Leader狀態。
通常，Raft 集群中只有一個 Leader，其它節點都是 Follower。Follower 都是被動的，不會發送任何請求，只是簡單地響應來自 Leader 或者 Candidate 的請求。Leader 負責處理所有的客戶端請求（如果一個客戶端和 Follower 聯系，那麼 Follower 會把請求重定向給 Leader）。
為簡化邏輯和實現，Raft 將一致性問題分解成了三個相對獨立的子問題。
• 選舉（Leader Election） ：當 Leader 宕機或者集群初創時，一個新的 Leader 需要被選舉出來；
• 日誌復制（Log Replication） ：Leader 接收來自客戶端的請求並將其以日誌條目的形式復制到集群中的其它節點，並且強制要求其它節點的日誌和自己保持一致；
• 安全性（Safety） ：如果有任何的伺服器節點已經應用了一個確定的日誌條目到它的狀態機中，那麼其它伺服器節點不能在同一個日誌索引位置應用一個不同的指令。
根據 Raft 協議，一個應用 Raft 協議的集群在剛啟動時，所有節點的狀態都是 Follower。由於沒有 Leader，Followers 無法與 Leader 保持心跳（Heart Beat），因此，Followers 會認為 Leader 已經下線，進而轉為 Candidate 狀態。然後，Candidate 將向集群中其它節點請求投票，同意自己升級為 Leader。如果 Candidate 收到超過半數節點的投票（N/2 + 1），它將獲勝成為 Leader。
第一階段：所有節點都是 Follower。
上面提到，一個應用 Raft 協議的集群在剛啟動（或 Leader 宕機）時，所有節點的狀態都是 Follower，初始 Term（任期）為 0。同時啟動選舉定時器，每個節點的選舉定時器超時時間都在 100~500 毫秒之間且並不一致（避免同時發起選舉）。
第二階段：Follower 轉為 Candidate 並發起投票。
沒有 Leader，Followers 無法與 Leader 保持心跳（Heart Beat），節點啟動後在一個選舉定時器周期內未收到心跳和投票請求，則狀態轉為候選者 Candidate 狀態，且 Term 自增，並向集群中所有節點發送投票請求並且重置選舉定時器。
注意，由於每個節點的選舉定時器超時時間都在 100-500 毫秒之間，且彼此不一樣，以避免所有 Follower 同時轉為 Candidate 並同時發起投票請求。換言之，最先轉為 Candidate 並發起投票請求的節點將具有成為 Leader 的「先發優勢」。
第三階段：投票策略。
節點收到投票請求後會根據以下情況決定是否接受投票請求（每個 follower 剛成為 Candidate 的時候會將票投給自己）：
請求節點的 Term 大於自己的 Term，且自己尚未投票給其它節點，則接受請求，把票投給它；
請求節點的 Term 小於自己的 Term，且自己尚未投票，則拒絕請求，將票投給自己。
第四階段：Candidate 轉為 Leader。
一輪選舉過後，正常情況下，會有一個 Candidate 收到超過半數節點（N/2 + 1）的投票，它將勝出並升級為 Leader。然後定時發送心跳給其它的節點，其它節點會轉為 Follower 並與 Leader 保持同步，到此，本輪選舉結束。
注意：有可能一輪選舉中，沒有 Candidate 收到超過半數節點投票，那麼將進行下一輪選舉。
在一個 Raft 集群中，只有 Leader 節點能夠處理客戶端的請求（如果客戶端的請求發到了 Follower，Follower 將會把請求重定向到 Leader） ，客戶端的每一個請求都包含一條被復制狀態機執行的指令。Leader 把這條指令作為一條新的日誌條目（Entry）附加到日誌中去，然後並行得將附加條目發送給 Followers，讓它們復制這條日誌條目。
當這條日誌條目被 Followers 安全復制，Leader 會將這條日誌條目應用到它的狀態機中，然後把執行的結果返回給客戶端。如果 Follower 崩潰或者運行緩慢，再或者網路丟包，Leader 會不斷得重復嘗試附加日誌條目（盡管已經回復了客戶端）直到所有的 Follower 都最終存儲了所有的日誌條目，確保強一致性。
第一階段：客戶端請求提交到 Leader。
如下圖所示，Leader 收到客戶端的請求，比如存儲數據 5。Leader 在收到請求後，會將它作為日誌條目（Entry）寫入本地日誌中。需要注意的是，此時該 Entry 的狀態是未提交（Uncommitted），Leader 並不會更新本地數據，因此它是不可讀的。
第二階段：Leader 將 Entry 發送到其它 Follower
Leader 與 Followers 之間保持著心跳聯系，隨心跳 Leader 將追加的 Entry（AppendEntries）並行地發送給其它的 Follower，並讓它們復制這條日誌條目，這一過程稱為復制（Replicate）。
有幾點需要注意：
1. 為什麼 Leader 向 Follower 發送的 Entry 是 AppendEntries 呢？
因為 Leader 與 Follower 的心跳是周期性的，而一個周期間 Leader 可能接收到多條客戶端的請求，因此，隨心跳向 Followers 發送的大概率是多個 Entry，即 AppendEntries。當然，在本例中，我們假設只有一條請求，自然也就是一個Entry了。
2. Leader 向 Followers 發送的不僅僅是追加的 Entry（AppendEntries）。
在發送追加日誌條目的時候，Leader 會把新的日誌條目緊接著之前條目的索引位置（prevLogIndex）， Leader 任期號（Term）也包含在其中。如果 Follower 在它的日誌中找不到包含相同索引位置和任期號的條目，那麼它就會拒絕接收新的日誌條目，因為出現這種情況說明 Follower 和 Leader 不一致。
3. 如何解決 Leader 與 Follower 不一致的問題？
在正常情況下，Leader 和 Follower 的日誌保持一致，所以追加日誌的一致性檢查從來不會失敗。然而，Leader 和 Follower 一系列崩潰的情況會使它們的日誌處於不一致狀態。Follower可能會丟失一些在新的 Leader 中有的日誌條目，它也可能擁有一些 Leader 沒有的日誌條目，或者兩者都發生。丟失或者多出日誌條目可能會持續多個任期。
要使 Follower 的日誌與 Leader 恢復一致，Leader 必須找到最後兩者達成一致的地方（說白了就是回溯，找到兩者最近的一致點），然後刪除從那個點之後的所有日誌條目，發送自己的日誌給 Follower。所有的這些操作都在進行附加日誌的一致性檢查時完成。
Leader 為每一個 Follower 維護一個 nextIndex，它表示下一個需要發送給 Follower 的日誌條目的索引地址。當一個 Leader 剛獲得權力的時候，它初始化所有的 nextIndex 值，為自己的最後一條日誌的 index 加 1。如果一個 Follower 的日誌和 Leader 不一致，那麼在下一次附加日誌時一致性檢查就會失敗。在被 Follower 拒絕之後，Leader 就會減小該 Follower 對應的 nextIndex 值並進行重試。最終 nextIndex 會在某個位置使得 Leader 和 Follower 的日誌達成一致。當這種情況發生，附加日誌就會成功，這時就會把 Follower 沖突的日誌條目全部刪除並且加上 Leader 的日誌。一旦附加日誌成功，那麼 Follower 的日誌就會和 Leader 保持一致，並且在接下來的任期繼續保持一致。
第三階段：Leader 等待 Followers 回應。
Followers 接收到 Leader 發來的復制請求後，有兩種可能的回應：
寫入本地日誌中，返回 Success；
一致性檢查失敗，拒絕寫入，返回 False，原因和解決辦法上面已做了詳細說明。
需要注意的是，此時該 Entry 的狀態也是未提交（Uncommitted）。完成上述步驟後，Followers 會向 Leader 發出 Success 的回應，當 Leader 收到大多數 Followers 的回應後，會將第一階段寫入的 Entry 標記為提交狀態（Committed），並把這條日誌條目應用到它的狀態機中。
第四階段：Leader 回應客戶端。
完成前三個階段後，Leader會向客戶端回應 OK，表示寫操作成功。
第五階段，Leader 通知 Followers Entry 已提交
Leader 回應客戶端後，將隨著下一個心跳通知 Followers，Followers 收到通知後也會將 Entry 標記為提交狀態。至此，Raft 集群超過半數節點已經達到一致狀態，可以確保強一致性。
需要注意的是，由於網路、性能、故障等各種原因導致「反應慢」、「不一致」等問題的節點，最終也會與 Leader 達成一致。
前面描述了 Raft 演算法是如何選舉 Leader 和復制日誌的。然而，到目前為止描述的機制並不能充分地保證每一個狀態機會按照相同的順序執行相同的指令。例如，一個 Follower 可能處於不可用狀態，同時 Leader 已經提交了若乾的日誌條目；然後這個 Follower 恢復（尚未與 Leader 達成一致）而 Leader 故障；如果該 Follower 被選舉為 Leader 並且覆蓋這些日誌條目，就會出現問題，即不同的狀態機執行不同的指令序列。
鑒於此，在 Leader 選舉的時候需增加一些限制來完善 Raft 演算法。這些限制可保證任何的 Leader 對於給定的任期號（Term），都擁有之前任期的所有被提交的日誌條目（所謂 Leader 的完整特性）。關於這一選舉時的限制，下文將詳細說明。
在所有基於 Leader 機制的一致性演算法中，Leader 都必須存儲所有已經提交的日誌條目。為了保障這一點，Raft 使用了一種簡單而有效的方法，以保證所有之前的任期號中已經提交的日誌條目在選舉的時候都會出現在新的 Leader 中。換言之，日誌條目的傳送是單向的，只從 Leader 傳給 Follower，並且 Leader 從不會覆蓋自身本地日誌中已經存在的條目。
Raft 使用投票的方式來阻止一個 Candidate 贏得選舉，除非這個 Candidate 包含了所有已經提交的日誌條目。Candidate 為了贏得選舉必須聯系集群中的大部分節點。這意味著每一個已經提交的日誌條目肯定存在於至少一個伺服器節點上。如果 Candidate 的日誌至少和大多數的伺服器節點一樣新（這個新的定義會在下面討論），那麼它一定持有了所有已經提交的日誌條目（多數派的思想）。投票請求的限制中請求中包含了 Candidate 的日誌信息，然後投票人會拒絕那些日誌沒有自己新的投票請求。
Raft 通過比較兩份日誌中最後一條日誌條目的索引值和任期號，確定誰的日誌比較新。如果兩份日誌最後條目的任期號不同，那麼任期號大的日誌更加新。如果兩份日誌最後的條目任期號相同，那麼日誌比較長的那個就更加新。
如同 4.1 節介紹的那樣，Leader 知道一條當前任期內的日誌記錄是可以被提交的，只要它被復制到了大多數的 Follower 上（多數派的思想）。如果一個 Leader 在提交日誌條目之前崩潰了，繼任的 Leader 會繼續嘗試復制這條日誌記錄。然而，一個 Leader 並不能斷定被保存到大多數 Follower 上的一個之前任期里的日誌條目 就一定已經提交了。這很明顯，從日誌復制的過程可以看出。
鑒於上述情況，Raft 演算法不會通過計算副本數目的方式去提交一個之前任期內的日誌條目。只有 Leader 當前任期里的日誌條目通過計算副本數目可以被提交；一旦當前任期的日誌條目以這種方式被提交，那麼由於日誌匹配特性，之前的日誌條目也都會被間接的提交。在某些情況下，Leader 可以安全地知道一個老的日誌條目是否已經被提交（只需判斷該條目是否存儲到所有節點上），但是 Raft 為了簡化問題使用了一種更加保守的方法。
當 Leader 復制之前任期里的日誌時，Raft 會為所有日誌保留原始的任期號，這在提交規則上產生了額外的復雜性。但是，這種策略更加容易辨別出日誌，即使隨著時間和日誌的變化，日誌仍維護著同一個任期編號。此外，該策略使得新 Leader 只需要發送較少日誌條目。
raft 的讀寫都在 leader 節點中進行，它保證了讀的都是最新的值，它是符合強一致性的（線性一致性），raft 除了這個還在【客戶端交互】那塊也做了一些保證，詳情可以參考論文。但是 zookeeper 不同，zookeeper 寫在 leader，讀可以在 follower 進行，可能會讀到了舊值，它不符合強一致性（只考慮寫一致性，不考慮讀一致性），但是 zookeeper 去 follower 讀可以有效提升讀取的效率。
對比於 zab、raft，我們發現他們選舉、setData 都是需要過半機制才行，所以他們針對網路分區的處理方法都是一樣的。
一個集群的節點經過網路分區後，如一共有 A、B、C、D、E 5個節點，如果 A 是 leader，網路分區為 A、B、C 和 D、E，在A、B、C分區還是能正常提供服務的，而在 D、E 分區因為不能得到大多數成員確認（雖然分區了，但是因為配置的原因他們還是能知道所有的成員數量，比如 zk 集群啟動前需要配置所有成員地址，raft 也一樣），是不能進行選舉的，所以保證只會有一個 leader。
如果分區為 A、B 和 C、D、E ，A、B 分區雖然 A 還是 leader，但是卻不能提供事務服務（setData），C、D、E 分區能重新選出 leader，還是能正常向外提供服務。
1）我們所說的日誌（log）與狀態機（state machine）不是一回事，日誌指還沒有提交到狀態機中的數據。
2）新 leader 永遠不會通過計算副本數量提交舊日誌，他只能復制舊日誌都其他 follower 上，對於舊日誌的提交，只能是新 leader 接收新的寫請求寫新日誌，順帶著把舊日誌提交了。
『柒』 3d演算法文檔//求翻譯
因此，如果來自相機的照片按照一個因子來縮放，則其所有參數應按同樣的因子被縮放（相應地乘或除）。內在參數的矩陣並不依賴於我們看到的景象。所以一旦估算完，只要焦距一定（在使用聚焦鏡頭的情況下），它就可以被重復使用。聯合的旋轉-翻譯矩陣[R|t]被稱為外在參數矩陣。它被用來描述相機圍繞著靜止景象的動作，或反之，在靜止鏡頭前物體按部就班的動作。即[R|t]將一點(X,Y,Z)的坐標翻譯成一個相對於相機而固定的坐標系統。上述轉換等價於下面的內容（當z不等於0時）：
『捌』 大數據演算法：分類演算法
KNN演算法，即K近鄰（K Nearest Neighbour）演算法，是一種基本的分類演算法。其主要原理是：對於一個需要分類的數據，將其和一組已經分類標注好的樣本集合進行比較，得到距離最近的K個樣本，K個樣本最多歸屬的類別，就是這個需要分類數據的類別。下面我給你畫了一個KNN演算法的原理圖。
圖中，紅藍綠三種顏色的點為樣本數據，分屬三種類別 、 、 。對於待分類點 ，計算和它距離最近的5個點（即K為5），這5個點最多歸屬的類別為 （4個點歸屬 ，1個點歸屬 ），那麼 的類別被分類為 。
KNN的演算法流程也非常簡單，請看下面的流程圖。
KNN演算法是一種非常簡單實用的分類演算法，可用於各種分類的場景，比如新聞分類、商品分類等，甚至可用於簡單的文字識別。對於新聞分類，可以提前對若干新聞進行人工標注，標好新聞類別，計算好特徵向量。對於一篇未分類的新聞，計算其特徵向量後，跟所有已標注新聞進行距離計算，然後進一步利用KNN演算法進行自動分類。
讀到這你肯定會問，如何計算數據的距離呢？如何獲得新聞的特徵向量呢？
KNN演算法的關鍵是要比較需要分類的數據與樣本數據之間的距離，這在機器學習中通常的做法是：提取數據的特徵值，根據特徵值組成一個n維實數向量空間（這個空間也被稱作特徵空間），然後計算向量之間的空間距離。空間之間的距離計算方法有很多種，常用的有歐氏距離、餘弦距離等。
對於數據 和 ，若其特徵空間為n維實數向量空間 ，即 ， ，則其歐氏距離計算公式為
這個歐式距離公式其實我們在初中的時候就學過，平面幾何和立體幾何里兩個點之間的距離，也是用這個公式計算出來的，只是平面幾何（二維幾何）里的n=2，立體幾何（三維幾何）里的n=3，而機器學習需要面對的每個數據都可能有n維的維度，即每個數據有n個特徵值。但是不管特徵值n是多少，兩個數據之間的空間距離的計算公式還是這個歐氏計算公式。大多數機器學習演算法都需要計算數據之間的距離，因此掌握數據的距離計算公式是掌握機器學習演算法的基礎。
歐氏距離是最常用的數據計算公式，但是在文本數據以及用戶評價數據的機器學習中，更常用的距離計算方法是餘弦相似度。
餘弦相似度的值越接近1表示其越相似，越接近0表示其差異越大，使用餘弦相似度可以消除數據的某些冗餘信息，某些情況下更貼近數據的本質。我舉個簡單的例子，比如兩篇文章的特徵值都是：「大數據」「機器學習」和「極客時間」，A文章的特徵向量為（3, 3, 3），即這三個詞出現次數都是3；B文章的特徵向量為（6, 6, 6），即這三個詞出現次數都是6。如果光看特徵向量，這兩個向量差別很大，如果用歐氏距離計算確實也很大，但是這兩篇文章其實非常相似，只是篇幅不同而已，它們的餘弦相似度為1，表示非常相似。
餘弦相似度其實是計算向量的夾角，而歐氏距離公式是計算空間距離。餘弦相似度更關注數據的相似性，比如兩個用戶給兩件商品的打分分別是（3, 3）和（4, 4），那麼兩個用戶對兩件商品的喜好是相似的，這種情況下，餘弦相似度比歐氏距離更合理。
我們知道了機器學習的演算法需要計算距離，而計算距離需要還知道數據的特徵向量，因此提取數據的特徵向量是機器學習工程師們的重要工作，有時候甚至是最重要的工作。不同的數據以及不同的應用場景需要提取不同的特徵值，我們以比較常見的文本數據為例，看看如何提取文本特徵向量。
文本數據的特徵值就是提取文本關鍵詞，TF-IDF演算法是比較常用且直觀的一種文本關鍵詞提取演算法。這種演算法是由TF和IDF兩部分構成。
TF是詞頻（Term Frequency），表示某個單詞在文檔中出現的頻率，一個單詞在一個文檔中出現的越頻繁，TF值越高。
詞頻：
IDF是逆文檔頻率（Inverse Document Frequency），表示這個單詞在所有文檔中的稀缺程度，越少文檔出現這個詞，IDF值越高。
逆文檔頻率：
TF與IDF的乘積就是TF-IDF。
所以如果一個詞在某一個文檔中頻繁出現，但在所有文檔中卻很少出現，那麼這個詞很可能就是這個文檔的關鍵詞。比如一篇關於原子能的技術文章，「核裂變」「放射性」「半衰期」等詞彙會在這篇文檔中頻繁出現，即TF很高；但是在所有文檔中出現的頻率卻比較低，即IDF也比較高。因此這幾個詞的TF-IDF值就會很高，就可能是這篇文檔的關鍵詞。如果這是一篇關於中國原子能的文章，也許「中國」這個詞也會頻繁出現，即TF也很高，但是「中國」也在很多文檔中出現，那麼IDF就會比較低，最後「中國」這個詞的TF-IDF就很低，不會成為這個文檔的關鍵詞。
提取出關鍵詞以後，就可以利用關鍵詞的詞頻構造特徵向量，比如上面例子關於原子能的文章，「核裂變」「放射性」「半衰期」這三個詞是特徵值，分別出現次數為12、9、4。那麼這篇文章的特徵向量就是（12, 9, 4），再利用前面提到的空間距離計算公式計算與其他文檔的距離，結合KNN演算法就可以實現文檔的自動分類。
貝葉斯公式是一種基於條件概率的分類演算法，如果我們已經知道A和B的發生概率，並且知道了B發生情況下A發生的概率，可以用貝葉斯公式計算A發生的情況下B發生的概率。事實上，我們可以根據A的情況，即輸入數據，判斷B的概率，即B的可能性，進而進行分類。
舉個例子：假設一所學校里男生佔60%，女生佔40%。男生總是穿長褲，女生則一半穿長褲一半穿裙子。假設你走在校園中，迎面走來一個穿長褲的學生，你能夠推斷出這個穿長褲學生是男生的概率是多少嗎？
答案是75%，具體演算法是：
這個演算法就利用了貝葉斯公式，貝葉斯公式的寫法是：
意思是A發生的條件下B發生的概率，等於B發生的條件下A發生的概率，乘以B發生的概率，除以A發生的概率。還是上面這個例子，如果我問你迎面走來穿裙子的學生是女生的概率是多少。同樣帶入貝葉斯公式，可以計算出是女生的概率為100%。其實這個結果我們根據常識也能推斷出來，但是很多時候，常識受各種因素的干擾，會出現偏差。比如有人看到一篇博士生給初中學歷老闆打工的新聞，就感嘆讀書無用。事實上，只是少見多怪，樣本量太少而已。而大量數據的統計規律則能准確反映事物的分類概率。
貝葉斯分類的一個典型的應用場合是垃圾郵件分類，通過對樣本郵件的統計，我們知道每個詞在郵件中出現的概率 ，我們也知道正常郵件概率 和垃圾郵件的概率 ，還可以統計出垃圾郵件中各個詞的出現概率 ，那麼現在一封新郵件到來，我們就可以根據郵件中出現的詞，計算 ，即得到這些詞出現情況下，郵件為垃圾郵件的概率，進而判斷郵件是否為垃圾郵件。
現實中，貝葉斯公式等號右邊的概率，我們可以通過對大數據的統計獲得，當有新的數據到來的時候，我們就可以帶入上面的貝葉斯公式計算其概率。而如果我們設定概率超過某個值就認為其會發生，那麼我們就對這個數據進行了分類和預測，具體過程如下圖所示。
訓練樣本就是我們的原始數據，有時候原始數據並不包含我們想要計算的維度數據，比如我們想用貝葉斯公式自動分類垃圾郵件，那麼首先要對原始郵件進行標注，需要標注哪些郵件是正常郵件、哪些郵件是垃圾郵件。這一類需要對數據進行標注才能進行的機器學習訓練也叫作有監督的機器學習。
『玖』 急！！求二十一個演算法的文檔，要求寫出： 1 輸入什麼，輸出什麼， 2 形式化定義，即用數學符號表示
隨便什麼演算法都可以嗎
『拾』 程序等於演算法加文檔嗎
不是，程序=演算法+數據結構。
程序（Program）是計算機系統的必備元素，因為計算機系統由硬體、操作系統以及軟體構成，而程序又是軟體的組成部分。對於程序的理解，計算機科學家Niklaus Wirth（尼古拉斯·沃斯）從本質上給出了簡潔的定義「程序=演算法+數據結構」。所以請記住，「軟體=程序+文檔=演算法+數據結構+文檔」。