[ https://issues.apache.org/jira/browse/MATH223?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=12627935#action_12627935 ]
Luc Maisonobe commented on MATH223:

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 cacheefficient implementations. Some ideas may be extracted from http://eprints.ma.man.ac.uk/210/01/covered/MIMS_ep2006_56.pdf (this is for bidiagonalisation and this is using BLAS, but you get the idea).
> QRDecomposition can easily be made to run about twice as fast
> 
>
> Key: MATH223
> URL: https://issues.apache.org/jira/browse/MATH223
> 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.