Tempo aleatório de computação na floresta em R

Estou usando o pacote de festa no R com 10.000 linhas e 34 recursos, e alguns recursos de fator têm mais de 300 níveis. O tempo de computação é muito longo. (Demorou 3 horas até agora e ainda não terminou.)

Quero saber quais elementos têm um grande efeito no tempo de computação de uma floresta aleatória. Está tendo fatores com muitos níveis? Existem métodos otimizados para melhorar o tempo de computação de RF?

A complexidade geral da RF é algo como ; se você quiser acelerar seus cálculos, tente o seguinte:$\text{ntree}\cdot\text{mtry}\cdot(\text{# objects})\log( \text{# objects})$

1. Use em randomForestvez de party, ou, melhor ainda, rangerou Rborist(embora ambos ainda não tenham sido testados em batalha).
2. Não use fórmula, ou seja, chame em randomForest(predictors,decision)vez de randomForest(decision~.,data=input).
3. Use o do.traceargumento para ver o erro OOB em tempo real; Dessa forma, você pode detectar que pode diminuir ntree.
4. Sobre fatores; O RF (e todos os métodos de árvore) tentam encontrar um subconjunto ideal de níveis, varrendo assim possibilidades; para esse fim, é bastante ingênuo que esse fator possa fornecer muitas informações - sem mencionar que o randomForest não comerá fatores com mais de 32 níveis. Talvez você possa simplesmente tratá-lo como ordenado (e, portanto, equivalente a uma variável numérica normal para RF) ou agrupá-lo em alguns grupos, dividindo esse atributo em vários?$2^\text{(# of levels-1)}$
5. Verifique se o seu computador não ficou sem memória RAM e se está usando espaço de troca. Nesse caso, compre um computador maior.
6. Finalmente, você pode extrair algum subconjunto aleatório de objetos e fazer algumas experiências iniciais sobre isso.

Como randomForest é uma coleção de carros independentes treinados em um subconjunto aleatório de recursos e registros, ele se presta à paralelização. A combine()função no pacote randomForest unirá florestas treinadas independentemente. Aqui está um exemplo de brinquedo. Como afirma a resposta do @mpq, você não deve usar a notação de fórmula, mas passar um quadro de dados / matriz de variáveis ​​e um vetor de resultados. Eu descaradamente tirei isso dos documentos.

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)
}

Passei a função de combinação randomForest para o parâmetro .combine de nome semelhante (que controla a função na saída do loop. O lado negativo é que você não obtém taxa de erro OOB ou importância tragicamente mais variável.

Editar:

Depois de reler o post, percebo que não falo nada sobre a questão dos 34 ou mais fatores. Uma resposta não-pensada poderia ser representá-los como variáveis ​​binárias. Esse é cada fator uma coluna que é codificada com fator de nível 0/1 sobre sua presença / não presença. Ao fazer uma seleção de variáveis ​​sobre fatores sem importância e removê-los, você pode impedir que o espaço do recurso fique muito grande.

Eu sugeriria alguns links:

1) O número reduzido de níveis de uma variável de fator é um link para uma pergunta stackoverflowpara lidar com um problema semelhante ao usar o randomForestpacote. Especificamente, trata do uso apenas dos níveis que ocorrem com mais frequência e da atribuição de um novo nível para todos os outros níveis que ocorrem com menos frequência.

A idéia veio daqui: 2009 KDD Cup Slow Challenge . Os dados para esta competição tinham muitos fatores com vários níveis e discutem alguns dos métodos usados ​​para reduzir os dados de 50.000 linhas por 15.000 colunas para rodar em um laptop com 2 núcleos / 2 GB de RAM.

Minha última sugestão seria analisar a execução do problema, como sugerido acima, em paralelo em uma instância do Amazon EC2 com alta CPU.

Não consigo falar com a velocidade de algoritmos específicos em R, mas deve ser óbvio o que está causando um longo tempo de computação. Para cada árvore em cada ramo, o CART está procurando a melhor divisão binária. Portanto, para cada um dos 34 recursos, mais se observa as divisões fornecidas por cada um dos níveis das variáveis. Multiplique o tempo de execução de cada divisão em uma árvore pelo número de galhos na árvore e depois multiplique pelo número de árvores na floresta e você terá um longo tempo de execução. Quem sabe? Talvez, mesmo com um computador rápido, isso possa levar anos para terminar?

A melhor maneira de acelerar as coisas, eu acho, seria agrupar alguns níveis juntos, de modo que cada variável caia para talvez 3 a 5 níveis em vez de até 300. É claro que isso depende de ser capaz de fazer isso sem perder importantes informações em seus dados.

Depois disso, talvez você possa ver se existe algum algoritmo inteligente que pode acelerar o tempo de pesquisa para a divisão em cada nó das árvores individuais. pode ser que em uma árvore específica a pesquisa dividida seja uma repetição de uma pesquisa já feita para uma árvore anterior. Portanto, se você pode salvar as soluções das decisões divididas anteriores e identificar quando está repetindo, talvez essa estratégia possa economizar um pouco de tempo de computação.