ENH Isomap supports radius-based neighbors - #19794
Conversation
|
I had a quick look at the diff and it looks good. Please document the change under I am trying to think of a case where radius based isomap would make a qualitative difference. Have you tried it on "real" datasets? Is there an existing example (under the |
|
Hi @TomDLT, sorry for the late action. I've made the suggested changes. |
|
Thanks ! It seems like you have an git issue on this branch, many commits do not belong here. |
Move radius to the last argument Co-authored-by: Tom Dupré la Tour <[email protected]>
update isomap tests Co-authored-by: Tom Dupré la Tour <[email protected]>
|
Apology for the git mess, should be fixed now :) |
Co-authored-by: Olivier Grisel <[email protected]>
| path_methods = ['auto', 'FW', 'D'] | ||
|
|
||
| N_per_side = 5 | ||
| Npts = N_per_side ** 2 |
There was a problem hiding this comment.
Since we change those line, let's name those variable more explicitly use either lower case or all upper case to respect scikit-learn conventions:
N_GRID_TICKS_PER_SIDE = 5
N_GRID_POINTS = N_GRID_TICKS_PER_SIDE ** 2
Co-authored-by: Olivier Grisel <[email protected]>
Co-authored-by: Tom Dupré la Tour <[email protected]>
Co-authored-by: Tom Dupré la Tour <[email protected]>
Co-authored-by: Tom Dupré la Tour <[email protected]>
TomDLT
left a comment
There was a problem hiding this comment.
We should add a test that a warning is raised, using with pytest.warns.
Co-authored-by: Tom Dupré la Tour <[email protected]>
|
@MaxwellLZH: I've corrected the status of this branch, merging Part of this PR changes (e.g https://github.com/scikit-learn/scikit-learn/pull/19794/files#diff-6f9bfaa7a4978e0d1aa64c5f613eb7a4bd988fb1b7227b170f825657693c056aR243-R247) might need some adaptation due to some change made by @TomDLT in #20531 in the meantime. |
thomasjpfan
left a comment
There was a problem hiding this comment.
Thanks for the PR @MaxwellLZH !
I left a comment for reviewers regarding the behavior when both n_neighbors and radius are set.
| "Radius is ignored when both n_neighbors and radius " | ||
| "are provided, n_neighbors should be set to None " | ||
| "explicitly when radius is passed." |
There was a problem hiding this comment.
If we are not raising an error, then I think n_neighbors should be the one that gets ignored when both parameters are not None. The default for n_neighbors is 5. Lets say one writes Isomap(radius=0.8), then radius is ignored and n_neighbors is set to 5. That feels very counter initiative.
For the record, I do prefer raising an error here instead of raising a warning.
There was a problem hiding this comment.
Good catch, I agree this is counter intuitive and we should ignore n_neighbors.
I am also ok raising an error instead (see #19794 (comment)), but then the same problem would arise, because Isomap(radius=0.8) would raise an error. To solve this issue, we could have both parameters default to None, and if none are provided use n_neighbors=5. WDYT ?
There was a problem hiding this comment.
If we error, I was thinking of letting Isomap(radius=0.8) error and recommending Isomap(radius=0.8, n_neighbors=None).
To solve this issue, we could have both parameters default to None, and if none are provided use n_neighbors=5. WDYT ?
I am +0.75 with this. It is the only solution we have to make Isomap(radius=0.8) work. The downside is that one needs to read the docstring to get the default value. Explaining the behavior in the docstring is slightly move involved:
n_neighbors : If `None` and `radius` is `None`, then the default is 5.
radius : Can be set only when `n_neighbors` is None.There was a problem hiding this comment.
Recommending Isomap(radius=0.8, n_neighbors=None) is a bit heavier, but I agree it is simpler to explain/understand, and more explicit than a default hidden in the docstring. Let's do that.
There was a problem hiding this comment.
I've updated the code to raise a ValueError when both arguments are set, might need some help with the phrasing of the error message
1edb983 to
d7508b3
Compare
Co-authored-by: Thomas J. Fan <[email protected]>
Co-authored-by: Thomas J. Fan <[email protected]>
thomasjpfan
left a comment
There was a problem hiding this comment.
Minor nits, otherwise LGTM
Co-authored-by: Thomas J. Fan <[email protected]>
Co-authored-by: Thomas J. Fan <[email protected]>
jjerphan
left a comment
There was a problem hiding this comment.
LGTM. Thank you, @MaxwellLZH.
Co-authored-by: Tom Dupré la Tour <[email protected]> Co-authored-by: Olivier Grisel <[email protected]> Co-authored-by: Thomas J. Fan <[email protected]> Co-authored-by: Julien Jerphanion <[email protected]>
Reference Issues/PRs
This is an implementation for #19744.
What does this implement/fix? Explain your changes.
The implementation added a
radiusargument toIsomapclass.When
n_neighborsargument is provided, we continue usingkneighbors_graphto build the underlying graph as we did before, so it's backward compatible. Whenn_neighborsis None, we useradius_neighbors_graphinstead to build the graph.Corresponding test cases are also added.