¿Por qué el lazo en matlab es mucho más lento que glmnet en R (10 min frente a ~ 1 s)?

Observé que la función lazo en MATLAB es relativamente lenta. Corro muchos problemas de regresión, con típicamente 1 a 100 predictores y 200 a 500 observaciones. En algunos casos, el lazo resultó ser extremadamente lento (para resolver un problema de regresión, tomó varios minutos). Descubrí que este era el caso cuando los predictores estaban altamente correlacionados (p. Ej., Series temporales de temperatura del aire en puntos de cuadrícula vecinos de un modelo atmosférico).

Comparé las actuaciones del siguiente ejemplo en matlab y en R.

y es el vector predictivo con 163 elementos (que representan observaciones) yx es la matriz predictora con 100 filas y 163 observaciones correspondientes a las observaciones en y. Apliqué el lazo de la función MATLAB de la siguiente manera:

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

Lo mismo en R, usando glmnet:

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

Tanto MATLAB como R se basan en un algoritmo de descenso coordinado. El valor predeterminado para el número de valores lambda es 100 para lazo y glmnet. El umbral de convergencia para el descenso de coordenadas es por defecto 10 ^ -4 en matlab, e incluso más bajo en R (10 ^ -7).

La función R tarda un segundo en mi computadora. Matlab toma varios minutos, con la mayor parte del tiempo de cálculo empleado en el algoritmo de descenso de coordenadas.

Cuando los predictores están menos correlacionados (p. Ej., Diferentes tipos de variables de un modelo atmosférico numérico) el lazo en Matlab no es tan lento, pero aún tarda ~ 30, en comparación con ~ 1 s en R).

¿Matlab Lasso es realmente mucho más ineficiente que glmnet, o me pierdo algo?

glmneten R es rápido porque usa lo que se llama rutas de regularización . Básicamente, selecciona una secuencia ordenada de parámetros de penalización . La solución para se utiliza como un inicio en caliente para , la solución para utiliza como un inicio en caliente para , y así sucesivamente. Esto se debe a que las soluciones deben estar cercanas entre sí. Entonces, ajustando el modelo para el parámetro de penalización , no comienza el descenso de coordenadas desde un lugar completamente aleatorio en el espacio de parámetros. En lugar de empezar desde algún lugar que ya está cerca de la solución: los parámetros para el º modelo.$\lambda_1, \ldots \lambda_m$$\lambda_1$$\lambda_{2}$$\lambda_2$$\lambda_3$$(n+1)$$n$

Si ejecuta glmnetllamadas separadas para cada , es considerablemente más lento y, de hecho, la documentación indica lo siguiente sobre el parámetro:$\lambda$?glmnetlambda

ADVERTENCIA: usar con cuidado. No proporcione un valor único para el suministro [...] lambda, sino una secuencia decreciente de valores lambda. glmnetse basa en sus cálidos comienzos para la velocidad, y a menudo es más rápido adaptarse a un camino completo que calcular un solo ajuste.

El énfasis es mío. Entonces, en el momento en que un enfoque de ruta de no regularización calcula la solución para una la basada en la ruta de regularización ya ha hecho todas las s y comenzó en el siguiente pliegue. Vea también el comentario a esta respuesta de Chris Haug. Aparentemente tiene acceso a MATLAB, que yo no tengo. Sus hallazgos parecen confirmar mi sospecha de que la diferencia en la velocidad proviene del uso de la ruta de regularización.$\lambda$$\lambda$