Pourquoi le lasso dans matlab est-il beaucoup plus lent que glmnet dans R (10 min contre ~ 1 s)?

J'ai observé que la fonction lasso dans MATLAB est relativement lente. Je gère de nombreux problèmes de régression, avec généralement 1 à 100 prédicteurs et 200 à 500 observations. Dans certains cas, le lasso s'est avéré extrêmement lent (pour résoudre un problème de régression, il a fallu plusieurs minutes). J'ai découvert que c'était le cas lorsque les prédicteurs étaient fortement corrélés (par exemple, les séries chronologiques de la température de l'air aux points de grille voisins d'un modèle atmosphérique).

J'ai comparé les performances de l'exemple ci-dessous en matlab et en R.

y est le vecteur prédictif avec 163 éléments (représentant les observations) et x est la matrice prédictive avec 100 lignes et 163 observations correspondant aux observations en y. J'ai appliqué le lasso de la fonction MATLAB comme suit:

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

La même chose dans R, en utilisant glmnet:

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

MATLAB et R sont tous deux basés sur un algorithme de descente de coordonnées. La valeur par défaut du nombre de valeurs lambda est 100 pour le lasso et le glmnet. Le seuil de convergence pour la descente de coordonnées est par défaut 10 ^ -4 dans matlab, et encore plus bas dans R (10 ^ -7).

La fonction R prend une seconde sur mon ordinateur. Matlab prend plusieurs minutes, la plupart du temps de calcul étant passé dans l'algorithme de descente de coordonnées.

Lorsque les prédicteurs sont moins corrélés (par exemple, différents types de variables d'un modèle atmosphérique numérique), le lasso dans Matlab n'est pas si lent, mais prend toujours ~ 30 - contre ~ 1 s dans R).

Matlab Lasso est-il vraiment beaucoup plus inefficace que glmnet, ou est-ce que je manque quelque chose?

glmnetdans R est rapide car il utilise ce qu'on appelle des chemins de régularisation . Fondamentalement, vous sélectionnez une séquence ordonnée de paramètres de pénalisation . La solution pour est utilisée comme démarrage à chaud pour , la solution pour utilisée comme démarrage à chaud pour , etc. En effet, les solutions doivent être proches les unes des autres. Donc, en ajustant le modèle pour le e paramètre de pénalisation, vous ne commencez pas la descente de coordonnées à partir d'un endroit complètement aléatoire dans l'espace des paramètres. Au lieu de cela, vous partez d'un endroit déjà proche de la solution: les paramètres du ème modèle.$\lambda_1, \ldots \lambda_m$$\lambda_1$$\lambda_{2}$$\lambda_2$$\lambda_3$$(n+1)$$n$

Si vous exécutez des glmnetappels distincts pour chaque , c'est beaucoup plus lent, et en effet la documentation dans indique ce qui suit sur le paramètre:$\lambda$?glmnetlambda

AVERTISSEMENT: utiliser avec précaution. Ne fournissez pas une seule valeur pour lambda Fournissez [...] plutôt une séquence décroissante de valeurs lambda. glmnetrepose sur ses départs chauds pour la vitesse, et son souvent plus rapide pour s'adapter à un chemin entier que de calculer un seul ajustement.

Je souligne. Donc, dans le temps, une approche de chemin de non-régularisation calcule la solution pour un celle basée sur le chemin de régularisation a déjà fait tous les et a commencé au pli suivant. Voir aussi le commentaire de cette réponse de Chris Haug. Apparemment, il a accès à MATLAB, ce que je n'ai pas. Ses résultats semblent confirmer ma suspicion que la différence de vitesse provient de l'utilisation du chemin de régularisation.$\lambda$$\lambda$