Dmitry Kobak

> As you can see, it's a pretty trivial wrapper anyway. Yes, makes sense. > Determining which affinity kernel to use would then be as simple as looking into adata.uns...

I hope everybody had a good New Year break! Just pinging @ivirshup again because I think it'd be great to move forward with this. Also wanted to ping @falexwolf as...

>> It would also make sense to add a tsne option to sc.pp.neighbors > > I would prefer for this to be a separate function, maybe neighbors_tsne? This could use...

Thanks! So my understanding is that you are saying that `neighbors` function is ALREADY too complicated, so we should not complicate it any further (and rather the existing function could...

> Why would you prefer uniform edge weights as input to your t-sne? I would think the information about relative distance is useful. My argument was mostly about API. But...

My primary wish here is very simple. I'd like the following sequence of commands: ``` sc.pp.neighbors(adata) sc.tl.tsne(adata) ``` to produce a reasonable t-SNE result that could be called "t-SNE" in...

> I think it would be sufficient for sc.tl.tsne to warn users if the graph it was passed looks unexpected Yes, warning is a good idea. But the warning IMHO...

> In general, are we agreed on these points? > tsne should allow weights to be passed through (whether perplexity based, or not) > There should be a warning to...

@pavlin-policar Have you had a chance to read our conversation above (I tried to summarize it in my last comment above)? What are your thoughts?

Sounds great to me! Looking forward. Would be interesting to compare these three t-SNEs: ``` sc.pp.neighbors() sc.tl.tsne(binarize=True) sc.tl.tsne(binarize=False) sc.pp.neighbors_tsne() sc.tl.tsne(binarize=False) ``` on a couple of datasets after the standard scanpy...