背景
一直在搞高維數據檢索，研究成果沒出多少，愛鑽牛角尖。時間長了，發現連基本的解決問題的能力都沒有了。視野太狹窄，所以決定到kaggle上惡補一番。
Digit Recognition是一個最基本的手寫識別問題，是對數字[0-9]手寫的識別。共有42000份訓練樣本，28000份待識別樣本。
kNN初步嘗試
先提交第一份結果建立自信吧。感謝wepon_的kaggle入門帖的啓發。原來自己一直在研究的k近鄰(k nearest neighbor, kNN)查詢技術竟然可以直接用於解該問題。
原理：
- 將每個28 x 28的圖像轉化成784維的向量，直接作爲該圖像的特徵向量，這是最簡單的特徵向量構建方案
- 如果兩份圖像表示的內容相似，則兩幅圖像特徵向量的距離（我用的是歐式距離）就會很小
- 因此，將42000份訓練圖像作爲kNN查詢的基本數據集(baseset)，28000份圖像作爲kNN的查詢集合(queryset)，爲每個查詢向量在baseset中搜索
這麼簡單的思路，我竟然都沒轉過彎來，看來真是鑽牛角尖鑽得夠深了啊。
思路有了，二話不說開始實施，很快在matlab裏實現了（其實花了1個多小時）。不過用的是brute-force查詢。等會，28000個查詢點，尼瑪，那得跑多久啊，不過幸好計算機內核比較多（12核），還能跑並行，而且baseset四萬多的體量也太小了。不夠跑下來就蒙了，還是太慢。
幸好自己平時積累了一些c/c++實現的kNN算法，直接取來。我用的是[Sharadh Ramaswamy 2011年TKDE上的一篇文章][1]，簡稱HB。
“` python
./main -ds digit -K 50 -h 1 -nq 28000 -k 20
花了24分鐘生成kNN查詢結果，到matlab翻譯成識別結果（每個查詢點取得票最多的標籤值），提交，0.95857，排名1081。乍一看準確度還挺高的95%，不過是1161個誤判呀。還是可怕。感覺是
細化提升
- Markdown和擴展Markdown簡潔的語法
- 代碼塊高亮
- 圖片鏈接和圖片上傳
- LaTex數學公式
- UML序列圖和流程圖
- 離線寫博客
- 導入導出Markdown文件
- 豐富的快捷鍵
表格
Markdown Extra 表格語法：
| 項目 | 價格 |
|---|---|
| Computer | $1600 |
| Phone | $12 |
| Pipe | $1 |
可以使用冒號來定義對齊方式：
| 項目 | 價格 | 數量 |
|---|---|---|
| Computer | 1600 元 | 5 |
| Phone | 12 元 | 12 |
| Pipe | 1 元 | 234 |
定義列表
- Markdown Extra 定義列表語法：
- 項目１
- 項目２
- 定義 A
- 定義 B
- 項目３
- 定義 C
-
定義 D
定義D內容
代碼塊
代碼塊語法遵循標準markdown代碼，例如：
“` python
@requires_authorization
def somefunc(param1=”, param2=0):
”’A docstring”’
if param1 > param2: # interesting
print ‘Greater’
return (param2 - param1 + 1) or None
class SomeClass:
pass
message = ”’interpreter
… prompt”’
離線寫博客
即使用戶在沒有網絡的情況下，也可以通過本編輯器離線寫博客（直接在曾經使用過的瀏覽器中輸入write.blog.csdn.net/mdeditor即可。Markdown編輯器使用瀏覽器離線存儲將內容保存在本地。
用戶寫博客的過程中，內容實時保存在瀏覽器緩存中，在用戶關閉瀏覽器或者其它異常情況下，內容不會丟失。用戶再次打開瀏覽器時，會顯示上次用戶正在編輯的沒有發表的內容。
博客發表後，本地緩存將被刪除。
用戶可以選擇 把正在寫的博客保存到服務器草稿箱，即使換瀏覽器或者清除緩存，內容也不會丟失。
注意：雖然瀏覽器存儲大部分時候都比較可靠，但爲了您的數據安全，在聯網後，請務必及時發表或者保存到服務器草稿箱。
瀏覽器兼容
- 目前，本編輯器對Chrome瀏覽器支持最爲完整。建議大家使用較新版本的Chrome。
- IE９以下不支持
- IE９，１０，１１存在以下問題
- 不支持離線功能
- IE9不支持文件導入導出
- IE10不支持拖拽文件導入
[1]: Ramaswamy S, Rose K. Adaptive cluster distance bounding for high-dimensional indexing[J]. IEEE Transactions on Knowledge and Data Engineering, 2011, 23(6): 815-830.