Closed Fil closed 3 years ago
Would a new "module" for graphs make sense? For TopoMap i needed to implement a (Euclidean) Minimum Spanning Tree algorithm, which needs also its own place.
Thanks for opimizing and fixing :)
I also work on UMAP right now, i made a mistake with the parameters _localconnectivity and _nneighbors. The parameter _localconnectivity does nothing atm.
Thanks for merging, it will be easier to experiment.
However I think we should think a bit more about the API:
Performance issue: it looks to me that the returned graph being symmetric, so why do we need to have i->j and j->i?
(EDIT: I'm not sure it's symmetric!)
This branch allows to return the UMAP graph. I don't like the API but wanted to share the concept with you. (It also contains a few optimizations I saw in passing.)
An application / use case is to compute the positions with d3-force rather than with the original UMAP's optimize_layout:
I think it looks much nicer (smooooooth movements), and the approach also allows to add other types of forces (forceCollide and so on), reuse the previous positions when the underlying data changes, allow direct interaction with the mouse, and so on.
I would however understand if you consider this to be out of scope :)
x-Ref: https://github.com/lmcinnes/umap/issues/509#issuecomment-718777075