consistently avoid dense matrix conversion for glmnet(x = ...) #1315
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(This is a more complete version of the fix submitted for #1096.)
Currently, some of the functions for the
glmnet
model check if the training data is asparseMatrix
, and some don't. The result is that initial operations intrain()
might succeed, and then later in the workflow, a step will fail (usually with "Cholmod error 'problem too large'" for asparseMatrix
with very large dimensions) because some of the training data is inadvertently converted to a (impossibly large) denseMatrix
.For instance, this bug currently occurs whenever
prob()
inglmnet.R
is called (which happens iftrainControl(classProbs = TRUE)
), or iftuneLength
is used instead oftuneGrid
fortrain()
, becausetuneLength = ...
triggers a call togrid()
inglmnet.R
which does not check for a sparseMatrix before executingMatrix::as.matrix()
.