-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Unified API #109
Comments
That makes sense to me. Might be nice to have an abstract dimensionality reduction type in there that linear, nonlinear, and latent variable types can subtype. |
That would be |
Whoops, don't know how I missed that... |
This seems great to me. As my primary interest in this is for plotting, one thing I'd like to know is whether there's a common method for obtaining a vector that would be used in a plot. I'm not super knowledgeable about the terminology, but I think different things are commonly plotted for different dimensionality reductions. For MDS and PCA (I think), one is supposed to plot the eigenvectors scaled by the square of the eigenvalue. But finding information on this has been a bit challenging for me, not knowing all of the jargon. |
Loadings are scaled eigenvectors. It will be easy to add them to every eigendecomposition-based method. |
Sounds like a good idea. Is the Also, shouldn't PCA implement |
Fantastic. What about things like LDA and CCA? I've definitely seen those plotted, but your schema above doesn't have I know this is somewhat orthogonal, I can open a separate issue if that would be useful. In any case, having unified APIs for this stuff will be fantastic. |
* refactor whitening for closer integration with StatsBase types (part of #109) * deprecate `indim` & `outdim`
Following #95, I looked at MV models/methods implemented in this package, trying to figure out what would be a type hierarchy and corresponding method interfaces for this package.
Here is a table of models and corresponding function names used by models.
I put
?
where a possible implementation is missing or called differently.So, I propose following type hierarchy
@nalimilan @ararslan Thoughts?
The text was updated successfully, but these errors were encountered: