Cuml: [FEA] Provide access to cuml.DBSCAN core samples

[ybdesire]

What is your question?

Is it possible for cuml.DBSCAN return core samples as sklearn.cluster.DBSCAN attribute core_sample_indices_? Or How can we get the cuml.DBSCAN core samples ?

I checked the cuML doc but still not find such api.

[ybdesire]

@teju85 Would it be possible to share some info about the question ?

[teju85]

@ybdesire currently even the underlying C++ implementation does not expose core samples information. How important is this information for you? (to help us prioritize this accordingly)

Also tagging @MatthiasKohl who's currently working on further improving dbscan implementation.

[MatthiasKohl]

As @teju85 writes, this would require a feature request. However, especially with the latest changes to DBScan, this would be quite a simple feature to implement.
Please keep me in the loop once this is prioritized.

[ybdesire]

Thanks @teju85 for the update.
core sample points could be used for incremental cluster (merge new sample to exists cluster if similar as core points). Also keep the API the same as sklearn is great for code compatible.

[JohnZed]

Converted this to a feature request - in scope for 0.15 unless we find that this will cause too much complexity.

[JohnZed]

Note from @teju85

In short: currently the core points are stored as a boolean array inside C++ interface. We'll have to write a "compaction routine", or use thrust or cub to convert them to indices, like sklearn does
The trick here is that the number of core points is dataset and hyper-params dependent, so cannot be allocated in advance. So, we'll have to allocate the core points inside c++ interface and also provide a way to delete them once it has gone out-of-scope, similar to have we currently do for support-vectors in SVMs.

[MatthiasKohl]

as a side-note : the memory requirements of DBScan are quite high in any case compared to the number of input points (even if the algorithm gets updated at some point) and the number of core-points is bounded by the number of input points.
So another option could be to just over-allocate the array of indexes in Python, then resize the array interface once we know the real size. On release, we just have to release the underlying (larger) array. I'm not sure how feasible this is with the current interfaces.