[
https://issues.apache.org/jira/browse/MATH-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627935#action_12627935
]
Luc Maisonobe commented on MATH-223:
------------------------------------
Thanks.
Could you please have a look at the new implementation on the subversion
repository, in 2.0 branch ?
Decomposition algorithms are currently being refactored a lot. One important
modification is to had directly solve method in the decomposition class, thus
removing the need for most user classes to call the getQ()/getR() or
getU()/getL() methods.
I am currently working on the Singular Value Decomposition implementation (most
probably using the wonderful MRRR algorithm). Once this will be done, I intend
to make a performance improvement pass on all decomposition algorithms, in
particular looking at cache-efficient implementations. Some ideas may be
extracted from http://eprints.ma.man.ac.uk/210/01/covered/MIMS_ep2006_56.pdf
(this is for bi-diagonalisation and this is using BLAS, but you get the idea).
> QRDecomposition can easily be made to run about twice as fast
> -------------------------------------------------------------
>
> Key: MATH-223
> URL: https://issues.apache.org/jira/browse/MATH-223
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: 1.2
> Environment: Any
> Reporter: John Mulcahy
> Priority: Minor
> Attachments: QRDecompositionImpl.java
>
>
> The QRDecomposition will run much faster (about twice as fast) if the qr and
> Q matrices are calculated as their transposes and the transposition is sorted
> out in the getQ() method. Using the transposes allows the loops to iterate
> over rows of the transposed matrices rather than columns. It might also be
> useful to cache the Q matrix locally when it is generated in case there are
> any subsequent calls to getQ() as this is the most expensive part of the
> decomposition.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
