Add a facewise (tensor) version of the crossprod() function #317
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In PLS-like analysis, operations of the type$X^T Y$ are performed pretty often, so it clocked me earlier today that it would probably be worth adding a simple tensor version of this to save some computation time.
UPDATE: for some reason it's actually slower on benchmarks so putting this on hold...R's
crossprod()
is slower on my machine even for matrix inputs.Minor: also added a parameter check and unit test for
tplsda
FINAL NOTE
See https://stackoverflow.com/questions/79049231/crossprodm1-m2-is-running-slower-than-tm1-m2-on-my-machine. I asked this question a few days back and there's some pretty handy benchmarks and discussion from some knowledgeable people, but no definitive reason / answer as of yet.
This is actually a more complex issue than I can bother for now, as it seems the default NETLIB linalg routines that ships by default with R (on both Mac and Windows as we have tested) actually result in
crossprod()
being slower, which I found when benchmarking the new facewise crossproduct version which is resultingly slower too. I'm not sure how complex or odd this issue may be, but it seems that this might be fixed in the future potentially even upstream in R, who knows? If this happens I'll changetpls
at a later date to use the (meant to be quicker)crossprod()
based version.My guess is most MixOmics2 users are probably going to be relying on these NETLIB linalg routines on a personal computer without linking to any fancier BLAS or LAPACK libs, there'll be no changes to
tpls
I'll just commit this new function and its unit tests as a public function that's probably a bit useless for now. Also, a good lesson learnt for me in making premature (probably unneeded) optimizations.