在耗费了大约两周的时间，终于用R完成了对50份招聘信息的简单文本挖掘，总结感受就是各种R语言包版本不一，解说不明。

鸡肋的tm包

  在网上搜索R语言数据挖掘，绝大多数人都会推荐用tm包，并称其为用R做文本挖掘的神器。然而真的用了之后，我觉得对于中文的文本分析说是神器不如说是鸡肋。下面说一下我的主要感受

1. 对中文支持差：因为tm包的制作者是外籍友人，同时因为中英文两种语言有着巨大的差异，所以，tm包对中文的支持程度实在是差到不能忍。尤其是在导入、分词以及去停用词上面。首先就是导入，英文作者给的解释文件中的例子是用的英文，所以再导入的时候没有任何问题。然而同样的函数对于中文却有着很多不同，最明显的就是建立语料库时language的选项问题，如果想要支持中文，还要通过对函数的编辑逻辑有着充分的了解，再对其参数做一些自己的设定，单单这一步就会造成许许多多无法想象的麻烦。然后就是分词和停用词的问题。因为中文不同于英文，许多意思的表达不是用一个单词就可以解释清楚的，所以单单的将每一个字分开显然不合乎中文的语言逻辑。所以经常用tm分完之后会看到许多不明所以的文字。
2. 版本繁杂：因为tm包作为文本挖掘中比较有名气的R包，所以在网上随手一搜找到的资料绝大多数都运用了tm包进行分析，尤其是在聚类的时候。然而这个时候问题就出现了，因为tm包也属于经典包了，也已经迭代了多个版本，网上的资料有三四年前的，也有比较新的，然而这和刚刚从CRAN下载的tm包都或多或少有些出路，尽管可以通过查看帮助文件明白其使用逻辑，但是鉴于上面的原因，其所更新后的包对中文的支持或许又有变化，所以，纵然可以通过研究源代码来探索，但毕竟过于耗时，对于只需要做简单聚类的人来说，有这样的时间已经可以自己变函数解决了。
3. 结构复杂：这里我重点说的是语料库。对作为一个刚刚接触文本挖掘的小白，一开始使用tm包我始终无法理解包中的语料库究竟是一种怎样的结构，也因此闹出了许多笑话，但是真的回过头来再看，必须要感叹tm包中对于语料库的简单解释了。因为不明白语料库的结构，我一直在上面迷惑了好久，而网上对语料库的解释也都是语焉不详。这实在是有些令人抓狂，尤其是许多文章用的例子是tm包的帮助文件中的例子，同时也就是简单的演示，套函数，而很少有人可以详细解读语料库到底是如何运作的。所以直到现在我也不是很懂语料库到底是一种什么样的存在。

  因为上述的这些原因，在我第三次尝试使用tm包无果之后我终于放弃了这个所谓的神器。或许tm包在处理英文上面确实神勇无比，只是遗憾我还是无法理解它的使用方法，所以，tm包再好于我而言不是神器而是鸡肋，既然如此不如早早弃之。

功臣Rwordseg包

  在此一定要感谢李健大大于12年~13年编写的Rwordseg包，在处理中文分词方面简直是一件不可多得的利器，尽管其需要提前设置java环境，但因为早前折腾别的语言包，rjava包早已被我降服，在此感谢师弟高原提供的java环境的安装包。

  因为要做中文的文本挖掘，根据中文与其他语言几乎完全不同的语法规则，导致在文本预处理的时候面临了一个十分麻烦的问题那就是分词。对于不同的句子，不同的语义，字与字之间是有着不同的组合的。由此便诞生了Rwordseg包。Rwordseg包在中文分词方面有着其他包无法比拟的优势，那就是添加字典。尽管包中所用的语料库已经是当前比较权威的语料库，但是对于许多这些年新诞生的词以及缩写词，还是会有很大的可能分辨不出来，Rwordseg包提供了一种解决方法，那就是利用手动添加词典的方式，近乎无限量的扩充其语料库的容量。因此使用Rwordseg包就可以几乎完美地完成中文分词的这一任务。

向量化编程

  因为弃用tm包的缘故，我不得不选择自己编程来实现对文本的聚类等分析。而这样，我也就早早地遇到了大数据的问题，仅仅是50个文本在TF-IDF提取特征词后，最后的矩阵的维数也已达到了四位数，不敢想象之后将文档提高到200,000后，这个数字会达到多少。因此我第一次清楚地意识到了向量化编程的重要性，尤其是在第n次电脑算地快要死机之后。因为R语言的特点，所以在编程时应该完全抛弃C++的编程思想，多用向量来计算还不是带入一个又一个的循环。三个以上的for循环真的会让你的电脑疯狂一阵，然后go die。

2016年4月24日写于南京