[FEA] Standardize configuration parameters for nn-descent based ANN algorithms

[beckernick]

Is your feature request related to a problem? Please describe.

cuML currently enables using nn-descent based ANN for UMAP and HDBSCAN, which has several configuration parameters.

Currently, the parameters don't match across the estimators.

cuml/python/cuml/cuml/cluster/hdbscan/hdbscan.pyx

Lines 603 to 607 in 72e6458

	- `knn_n_clusters` (int, default=1): Number of clusters for data partitioning.
	Higher values reduce memory usage at the cost of accuracy. When `knn_n_clusters > 1`,
	HDBSCAN can process data larger than device memory.
	- `knn_overlap_factor` (int, default=2): Number of clusters each data point belongs to.

cuml/python/cuml/cuml/manifold/umap/umap.pyx

Lines 379 to 380 in 72e6458

	n_clusters = build_kwds.get("nnd_n_clusters", 1)
	overlap_factor = build_kwds.get("nnd_overlap_factor", 2)

We should unify these for a better UX.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context, code examples, or references to existing implementations about the feature request here.

[csadorf]

@jinsolp The request appears very reasonable to me and I'm happy to implement this change, but could you briefly weigh in on whether there is a reason for the discrepancy?

[csadorf]

I think one thing to consider here is that the nnd_n_clusters parameter in UMAP is only used in combination with build_algo='nn_descent'.

In HDBSCAN, the knn_n_clusters parameter is also used to initialize the n_clusters parameter for the brute-force algorithm. In so far, renaming it to nnd_n_clusters would be inaccurate/ misleading.

[jinsolp]

Yes thanks for pointing this out @beckernick ! We should be changing the param names in UMAP to knn_n_clusters. I'll assign myself to this.

If you're interested, the reason we have different param names is:
Using nn descent in HDBSCAN was added after the introduction of the all_neighbors API. This API supports n_clusters (i.e. batching) for both brute force and nn descent, therefore the option in HDBSCAN being knn_* instead of nnd_* to distinguish nn descent specific params from general batching params (the knn_n_clusters).

UMAP's nn descent option was introduced when the batching method was less generic and tied specifically to nn descent, therefore the name being nnd_n_clusters.
In UMAP we currently don't use the all-neighbors API for brute force, but it's just because we haven't updated it to do so yet. If we do, n_clusters will be supported for brute force as welll, and changing nnd_n_clusters to knn_n_clusters like HDBSCAN will make more sense! @csadorf

[csadorf]

@jinsolp Thank you for weighing in on this and happy for you to take this on. Please make sure to deprecate the old parameter names and mark the corresponding PR as breaking. Please explicitly tag me for review when the PR is ready. Thank you!

As an aside, do we have an issue to track the brute force support in UMAP yet?