J'utilise cv.glmnet
pour trouver des prédicteurs. La configuration que j'utilise est la suivante:
lassoResults<-cv.glmnet(x=countDiffs,y=responseDiffs,alpha=1,nfolds=cvfold)
bestlambda<-lassoResults$lambda.min
results<-predict(lassoResults,s=bestlambda,type="coefficients")
choicePred<-rownames(results)[which(results !=0)]
Pour vous assurer que les résultats sont reproductibles I set.seed(1)
. Les résultats sont très variables. J'ai exécuté exactement le même code 100 pour voir à quel point les résultats étaient variables. Dans les courses 98/100, un prédicteur particulier était toujours sélectionné (parfois juste de lui-même); d'autres prédicteurs ont été sélectionnés (le coefficient était non nul), généralement 50/100 fois.
Donc, cela me dit que chaque fois que la validation croisée s'exécute, elle va probablement sélectionner un meilleur lambda différent, car la randomisation initiale des plis est importante. D'autres ont vu ce problème ( résultats CV.glmnet ) mais il n'y a pas de solution suggérée.
Je pense que celui qui apparaît 98/100 est probablement assez fortement corrélé à tous les autres? Les résultats ne se stabilisent si je viens de lancer LOOCV ( ), mais je suis curieux de savoir pourquoi ils sont si variables quand .
la source
set.seed(1)
courez une fois puis que vous courezcv.glmnet()
100 fois? Ce n'est pas une excellente méthodologie pour la reproductibilité; mieux àset.seed()
droite avant chaque course, sinon maintenez les plis constants d'une course à l'autre. Chacun de vos appels àcv.glmnet()
appellesample()
N fois. Donc, si la longueur de vos données change, la reprodubilité change.Réponses:
Le point ici est que dans
cv.glmnet
le K les plis ("pièces") sont choisis au hasard.Dans la validation croisée des plis en , l'ensemble de données est divisé en K parties, et K - 1 parties sont utilisées pour prédire la K-ème partie (cela se fait K fois, en utilisant une partie K différente à chaque fois). Ceci est fait pour tous les lambdas, et c'est celui qui donne la plus petite erreur de validation croisée.K K- 1 K K
lambda.min
C'est pourquoi lorsque vous utilisez les résultats ne changent pas: chaque groupe est composé d'un, donc pas beaucoup de choix pour les K groupes.n fo l ds = n K
Du
cv.glmnet()
manuel de référence:MSE est le bloc de données contenant toutes les erreurs pour tous les lambdas (pour les 100 exécutions),
lambda.min
est votre lambda avec l'erreur moyenne minimale.la source
cv.glmnet(...)$lambda
. Mon alternative corrige ceci: stats.stackexchange.com/a/173895/19676Ensuite, pour chaque prédicteur, j'obtiens:
De cette façon, j'obtiens une description assez solide de l'effet du prédicteur. Une fois que vous avez des distributions pour les coefficients, vous pouvez exécuter toutes les statistiques que vous pensez être utiles pour obtenir les valeurs CI, p, etc ... mais je n'ai pas encore enquêté.
Cette méthode peut être utilisée avec plus ou moins n'importe quelle méthode de sélection à laquelle je peux penser.
la source
J'ajouterai une autre solution, qui gère le bogue de @ Alice en raison de lambdas manquants, mais ne nécessite pas de packages supplémentaires comme @Max Ghenis. Merci à toutes les autres réponses - tout le monde fait des remarques utiles!
la source
La réponse d'Alice fonctionne bien dans la plupart des cas, mais parfois des erreurs se produisent en raison du
cv.glmnet$lambda
retour parfois de résultats de longueur différente, par exemple:OptimLambda
ci-dessous devrait fonctionner dans le cas général, et est également plus rapide en optimisant lemclapply
traitement parallèle et en évitant les boucles.la source
Vous pouvez contrôler le caractère aléatoire si vous définissez explicitement foldid. Voici un exemple de CV multiplié par 5
Maintenant, exécutez cv.glmnet avec ces foldids.
Vous obtiendrez les mêmes résultats à chaque fois.
la source