Closed dkobak closed 1 month ago
For the time being, should openTSNE be a separate method? It might be helpful because I think a lot of people might just use the scanpy implementation params.
I don't know if it's of interest here to benchmark different implementations of the same method, including implementations that are known to be suboptimal... Personally, I don't think so. So I'd vote to replace Scanpy.TSNE with openTSNE. But I guess it's up for discussion.
In terms of managing PRs/merging across different people it might be cleaner to add new files now and delete the existing scanpy implementation later. Probably doesn't make a lot of difference though so whatever you decide.
This issue has been automatically closed because it has not had recent activity.
t-SNE is already implemented in the dimensionality reduction task, but through Scanpy. Scanpy's implementation is slow and has suboptimal parameters. I would strongly suggest to use openTSNE with default parameters. We are in the process of switching Scanpy to openTSNE, but it will take some time still: https://github.com/theislab/scanpy/issues/1233.
See https://github.com/pavlin-policar/openTSNE.