背景
一直在搞高维数据检索，研究成果没出多少，爱钻牛角尖。时间长了，发现连基本的解决问题的能力都没有了。视野太狭窄，所以决定到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.