inconsistencies with tsne/umap projection helper functions

[jfx319]

In runUMAP(), why are the coordinates stored under object@tsne_coords -- shouldn't this be named umap_coords? The runTSNE() overwrites this.... I would think you'd want to keep them separate as they are different projections and mean different styles for users.

• https://github.com/MacoskoLab/liger/blob/1f1a7b98753ceca8ff6c7be78e26c1d19529f19c/R/liger.R#L2465
• fixing this would have implications for all other functions that inaccurately call on this as UMAP

In runTSNE(), the current liger code makes the user specify a FIt-SNE folder path, just to import the fast_tsne.R wrapper, which then has some hardcoding of the fast_tsne binary location anchored to that folder. Although not ideal and somewhat round about, the more pressing problem is that the liger.R currently comments out loading of this wrapper's function (implying the user needs to source() the wrapper manually (probably not what you would want):

• https://github.com/MacoskoLab/liger/blob/1f1a7b98753ceca8ff6c7be78e26c1d19529f19c/R/liger.R#L2392
• if this does get fixed, I suggest borrowing from Seurat's example, where a parameter lets the user specify the binary executable fast_tsne_path directly -- I think this would be more flexible and more direct, particularly since users can put the binary in different locations after compiling (it doesn't have to be tied to the FIt-SNE source folder).
  • https://github.com/satijalab/seurat/blob/b51801bc4b1a66aed5456473c9fe0be884994c93/R/dimensional_reduction.R#L1815
  • if so, just make sure to also add an initialization parameter since fast_tsne does offer several types, but only the random initialization is not dependent on installing yet another package.

[jfx319]

ah.. I see that a utilities.R is in progress but not ready yet -- that should eventually address the fast_tsne part above

• https://github.com/MacoskoLab/liger/blob/1f1a7b98753ceca8ff6c7be78e26c1d19529f19c/R/utilities.R#L693
• as a heads up, should keep an eye out on the FIt-SNE version update: FIt-SNE wrapper requires upgrading to 1.2.0 satijalab/seurat#2792

[samuel-marsh]

Looks like the ability to store both tsne and UMAP is also in progress but no changes have been made in while, see #94
I'd second the desire for the ability to store multiple dim reductions in the same object!

Thanks!
Sam

[skpalan]

Hi Jeff and Sam, thanks for your comments. We fixed fast_tsne issue a long time ago, so it shouldn't be a problem anymore. For the dim reduction coords issue, it has been on our list for a while and it will be addressed in the future.