R中的随机森林计算时间

我在R中使用具有10,000行和34个特征的party包，并且某些要素特征具有300多个级别。计算时间过长。（到目前为止，已花费了3个小时，但尚未完成。）

我想知道哪些元素对随机森林的计算时间有很大影响。它的因素过多吗？是否有优化的方法来缩短RF计算时间？

RF的整体复杂性类似于；如果您想加快计算速度，可以尝试以下方法：$\text{ntree}\cdot\text{mtry}\cdot(\text{# objects})\log( \text{# objects})$

1. 使用randomForest代替party，或什至更好，ranger或者Rborist（尽管尚未经过实战测试）。
2. 不要使用公式，即调用randomForest(predictors,decision)而不是randomForest(decision~.,data=input)。
3. 使用do.trace参数实时查看OOB错误；这样，您可能会发现可以降低ntree。
4. 关于因素；RF（和所有树方法）试图找到级别的最佳子集，从而扫描可能性；为此，这个因素可以为您提供太多信息是很幼稚的，更不用说randomForest不会食用超过32个水平的因素。也许您可以简单地将其视为有序的变量（从而等效于RF的普通数字变量），或将其分为几类，将一个属性拆分为几个？$2^\text{(# of levels-1)}$
5. 检查您的计算机是否还没有用完RAM，是否正在使用交换空间。如果是这样，请购买一台更大的计算机。
6. 最后，您可以提取对象的一些随机子集，并对此进行一些初始实验。

因为randomForest是一组独立的手推车的集合，这些手推车经过特征的随机子集训练并记录下来，因此很容易实现并行化。combine()randomForest软件包中的功能会将经过独立培训的森林拼接在一起。这是一个玩具示例。正如@mpq的答案指出的那样，您不应使用公式符号，而应传入变量和结果向量的数据框/矩阵。我无耻地从文档中删除了这些。

library("doMC")
library("randomForest")
data(iris)

registerDoMC(4) #number of cores on the machine
darkAndScaryForest <- foreach(y=seq(10), .combine=combine ) %dopar% {
   set.seed(y) # not really needed
   rf <- randomForest(Species ~ ., iris, ntree=50, norm.votes=FALSE)
}

我将randomForest合并函数传递给了类似命名的.combine参数（该函数在循环的输出上控制该函数。不利的一面是您没有OOB错误率或更悲惨的变量重要性。

编辑：

重新阅读该帖子后，我意识到我没有谈论34+因素问题。一个完全没有考虑的答案可能是将它们表示为二进制变量。即，每个因子是关于其存在/不存在被编码为0/1级因子的列。通过对不重要的因素进行一些变量选择并将其删除，可以防止要素空间过大。

我建议几个链接：

1）缩小因子变量级别的数量 是stackoverflow在使用randomForest软件包时要处理类似问题的问题的链接。具体来说，它仅处理使用频率最高的级别，并为所有其他频率较低的级别分配新级别。

它的想法来自这里：2009年KDD杯慢速挑战赛。该竞赛的数据具有很多因素，涉及很多层次，并且讨论了他们用来将数据从50,000行减15,000列缩减为在2核/ 2GB RAM笔记本电脑上运行的一些方法。

我的最后建议是，按照上述建议，在Hi-CPU Amazon EC2实例上并行运行问题。

我不能说R中特定算法的速度，但是很明显是什么导致了较长的计算时间。对于每个分支处的每个树，CART都在寻找最佳的二进制拆分形式。因此，对于这34个功能中的每个功能，它最着眼于每个变量级别给出的拆分。将树中每个拆分的运行时间乘以树中分支的数量，然后乘以森林中的树数量，则运行时间很长。谁知道？也许即使是一台快速的计算机，也可能需要数年才能完成？

我认为最好的加速方法是将某些级别集中在一起，以便每个变量降低到3到5个级别，而不是多达300个级别。当然，这取决于能否做到这一点而又不会失去重要的您数据中的信息。

在那之后，您可能会看看是否有一些聪明的算法可以加快在单个树的每个节点处进行拆分的搜索时间。可能是在特定树上，拆分搜索是对先前树已经执行的搜索的重复。因此，如果您可以保存先前拆分决策的解决方案并确定何时重复，则该策略可能会节省一些计算时间。