Por que o laço no matlab é muito mais lento que o glmnet em R (10 min versus ~ 1 s)?

Observei que a função laço no MATLAB é relativamente lenta. Eu corro muitos problemas de regressão, com tipicamente 1 a 100 preditores e 200 a 500 observações. Em alguns casos, o laço mostrou-se extremamente lento (para resolver problemas de regressão, levou vários minutos). Descobri que esse era o caso quando os preditores eram altamente correlacionados (por exemplo, séries temporais de temperatura do ar em pontos de grade vizinhos de um modelo atmosférico).

Comparei as performances do exemplo abaixo no matlab e no R.

y é o vetor preditivo com 163 elementos (representando observações) e x é a matriz preditora com 100 linhas e 163 observações correspondentes às observações em y. Eu apliquei o laço da função MATLAB da seguinte maneira:

[beta_L,stats]=lasso(x,y,'cv',4);

O mesmo em R, usando glmnet:

fit.lasso=cv.glmnet(predictor.ts,predictand.ts,nfolds=4)

MATLAB e R são baseados em um algoritmo de descida de coordenadas. O valor padrão para o número de valores lambda é 100 para laço e glmnet. O limite de convergência para a descida de coordenadas é por padrão 10 ^ -4 no matlab e ainda mais baixo em R (10 ^ -7).

A função R leva um segundo no meu computador. O Matlab leva vários minutos, com a maior parte do tempo de computação gasto no algoritmo de descida de coordenadas.

Quando os preditores são menos correlacionados (por exemplo, diferentes tipos de variáveis ​​de um modelo atmosférico numérico), o laço no Matlab não é tão lento, mas ainda leva ~ 30 - comparado a ~ 1 s em R).

O laço do matlab é realmente muito mais ineficiente do que o glmnet, ou sinto falta de algo?

glmnetem R é rápido porque usa os chamados caminhos de regularização . Basicamente, você seleciona uma sequência ordenada de parâmetros de penalização . A solução para é usada como um início quente para , a solução para usada como um início quente para e assim por diante. Isso ocorre porque as soluções devem estar próximas umas das outras. Portanto, ajustando o modelo para o ésimo parâmetro de penalização, você não inicia a descida de coordenadas de um local completamente aleatório no espaço de parâmetros. Em vez de começar de algum lugar que já está perto da solução: os parâmetros para o º modelo.$\lambda_1, \ldots \lambda_m$$\lambda_1$$\lambda_{2}$$\lambda_2$$\lambda_3$$(n+1)$$n$

Se você executar glmnetchamadas separadas para cada , é consideravelmente mais lento e, de fato, a documentação declara o seguinte sobre o parâmetro:$\lambda$?glmnetlambda

AVISO: use com cuidado. Não forneça um valor único para o fornecimento [...] lambda em vez de uma sequência decrescente de valores lambda. glmnetconfia nos seus aquecimentos começa para a velocidade, e geralmente é mais rápido ajustar-se a um caminho inteiro do que calcular um único ajuste.

Ênfase minha. Portanto, no tempo em que uma abordagem de caminho de não-regularização calcula a solução para um a abordagem baseada no caminho de regularização já executou todos os iniciou na próxima dobra. Veja também o comentário a esta resposta de Chris Haug. Aparentemente, ele tem acesso ao MATLAB, o que eu não tenho. Suas descobertas parecem confirmar minha suspeita de que a diferença de velocidade vem do uso do caminho da regularização.$\lambda$$\lambda$