Package Rank，假如cran也可以有英雄榜

因为大量信息的存在，人们有了排序的需要，因为链接布局的存在，就有了Page Rank排序，也就有了Google。

持久以来，我一直烦恼的一个工作是：如何挑选符合的R包来为我事情。因为cran中包的数量是那么多，即即是同一个任务，也大概有差异人的差异的实现。我称这种选择无力为幸福的烦恼。然而，有时这也并非老是幸福的，因为cran中的包素来以广袤而良莠不齐而著称，假如你选中了一个不靠谱的实现，最终功效你大概倒甘愿本身从头写一个。

一直以来我都依靠着直觉来帮本身作出筛选，如最近的更新时间、更新频率、依赖它的包的数量、文档的完备等等因素。然而作为一个算法攻城师，如此依赖直觉来辅佐决定终觉不爽，于是就有了Package Rank。这个名字长得很像Page Rank，道理也根基一致，但回收的链接布局酿成了包与包之间的depend干系，如A depend B，则意味着有一个从A到B的链接。对cran中数千个包所构成的depend矩阵应用Page Rank算法，即可为每个包获得一个Rank值，即名为Package Rank。假如你想查询任意一个包的rank值，可以去我的主页：http://www.wentrue.net

这个depend矩阵中的包来自于cran，总数2131个，不包罗R自带的根基包。计较获得的Package Rank值中，大于0的有844个，大于1的有384个。rank值在各个区间漫衍的环境如下：

> hist(data[[2]], breaks=0:10, plot=FALSE)

 $breaks

 [1]  0  1  2  3  4  5  6  7  8  9 10
$counts

 [1] 1747  197   79   56   27   15    4    3    1    2

可见，depend矩阵间的毗连并不细密，因为包与包之间的依赖性并不强。
对所有的包以rank值排序后，英雄榜前十位如下所示：
0 lattice 10.0
1 MASS 9.6212
2 survival 8.2219
3 mvtnorm 7.8478
4 Matrix 7.3402
5 zoo 7.0038
6 nlme 6.7743
7 rJava 6.3173
8 sp 6.1874
9 boot 6.012
这里有一两个包本是R自带的，它会呈现的原因是因为许多包的先容页面的depend城市显式地把它也写上去。
不敷及可改造之处：
1、因为数据是写爬虫从cran上抓取下来的，理会非布局化数据进程中有大概引入噪声，可能信息不完整。
2、这里只是一个粗拙的实现，只操作了depend信息来计较rank，其实我还同时抓取了suggest信息，假如操作suggest信息也做一个rank，可能把两者团结起来以增加矩阵的浓密度，功效也许又会纷歧样。