I have been looking at the "eigen" function and have reintroduced the ability to compute (right) eigenvalues and vectors for non-symmetric matrices. I've also made "eigen" complex capable. The code is based on the eispack entry points RS, RG, CH, CG (which is what S appears to use too). The problem with both the S and R implementations is that they consume huge amounts of memory. Some of this is due to purely ".Fortran" overhead, which I think I can cure. But some of the bloat is due to the inclusion of special eigenvalues-only code from eispack. The question is: Should I drop this special code and always compute both eigenvalues and eigenvectors? This would substantially reduce code size, but might increase computational cost in the case where only eigenvalues are needed. PS: For the lapack fans out there ... I looked hard at using lapack as an alternative to eispack, but it's written in a fashion which does not make its addition to R as simple as linpack and eispack. When we all have SMP desktop machines it will become more of an issue. Ross =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
R-alpha: Eigenvalue Computation Query
4 messages · Ross Ihaka, Kurt Hornik, Friedrich Leisch +1 more
1 day later
Ross Ihaka writes:
I have been looking at the "eigen" function and have reintroduced the ability to compute (right) eigenvalues and vectors for non-symmetric matrices. I've also made "eigen" complex capable.
The code is based on the eispack entry points RS, RG, CH, CG (which is what S appears to use too). The problem with both the S and R implementations is that they consume huge amounts of memory. Some of this is due to purely ".Fortran" overhead, which I think I can cure. But some of the bloat is due to the inclusion of special eigenvalues-only code from eispack.
The question is:
Should I drop this special code and always compute both eigenvalues and eigenvectors? This would substantially reduce code size, but might increase computational cost in the case where only eigenvalues are needed.
I'd say, reduce code size. -k =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On Tue, 20 May 1997 08:18:22 +0200, Kurt Hornik wrote:
Ross Ihaka writes:
I have been looking at the "eigen" function and have reintroduced the ability to compute (right) eigenvalues and vectors for non-symmetric matrices. I've also made "eigen" complex capable.
The code is based on the eispack entry points RS, RG, CH, CG (which is what S appears to use too). The problem with both the S and R implementations is that they consume huge amounts of memory. Some of this is due to purely ".Fortran" overhead, which I think I can cure. But some of the bloat is due to the inclusion of special eigenvalues-only code from eispack.
The question is:
Should I drop this special code and always compute both eigenvalues and eigenvectors? This would substantially reduce code size, but might increase computational cost in the case where only eigenvalues are needed.
I'd say, reduce code size.
probably one shouldn't disagree with his boss openly ... but we are the ones actually doing all the simulations :-) do you know how much the difference in computational cost is? if it's worth the increase in code size I'd rather prefer only computing the required eigenvalues best, fritz =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friedrich Leisch <Friedrich.Leisch@ci.tuwien.ac.at> writes:
I'd say, reduce code size.
probably one shouldn't disagree with his boss openly ... but we are the ones actually doing all the simulations :-) do you know how much the difference in computational cost is? if it's worth the increase in code size I'd rather prefer only computing the required eigenvalues
As I understand it, the difference is between getting all the eigenvalues and all eigenvalues and -vectors. Getting only the top or bottom few is not an option in Splus either, but that would be where the real savings lie. I'd say do the small thing now and rethink the whole numerics business later (could we lift all of libcruft.a out of the octave source, for instance?). If you need some special eispack routines, you can always dyn.load them in.
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-