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 PR regarding this concern by @glemaitre.
The main concern is that in order to do a check into a sparse matrix, this needs to be materialized and @glemaitre is wandering if it could be computed directly from the sparse matrix. The underlying computation is this one:
which could be changed (for the sparse case) by something this:
The problem comes when the instances of 0 need to be waited. Which is the case here. And any feedback is wellcome.
Some notes, that I don't know how to include into the discussion but that are important when taking a decission. (They are listed with no particular order).
1 - The case of sparase matrix and weights is never tested. See this breakpoint and travis still all green.
2 - Two different signatures of
self._mode
:KNeighborsClassifier::_mode (self,neigh,weights)
andRadiusNeighborsClassifier::_mode (self,pred_labels,weights,inliers)
. More over neither of them useself
inside. So shouldn't we unify the signature and use it as a free function. Or in case of really being a class method shouldn't they have the same signature and be added to a parent class?3 - In order to unify the call and simply the code weights could always be provided (at expenses of some computing time) and we could even add sparse support to
sklearn.utils.extmath.weighted_mode
: