[Octave-bug-tracker] [bug #29768] logm fix

[Jaroslav Hajek]

Follow-up Comment #12, bug #29768 (project octave):

Ugh, yes. One thing is that we need a complex schur instead of the real
(quasi-triangular) one; without that, the triangular sqrtm optimizations won't
take place. The newest Octave recognizes the Matlab-compatible syntax schur
(a, "complex"); that alone should give you a much better performance. On a
random 500x500 matrix, it cuts down time from 14s to 4.8s for me.

It still lags behind the original logm, however. Measuring the individual
stages, I get:

octave:4> logm (a);
schur decomposition
Elapsed time is 1.62743 seconds.
square roots
Elapsed time is 1.76724 seconds.
pade approximation
Elapsed time is 1.13181 seconds.
recovery
Elapsed time is 0.195883 seconds.

we could save some time and memory in stages 2 and 3 by rewriting code into
C++, so that it can avoid temporary matrices. 

There is still a problem with the costly complex schur decomposition. This is
currently done simply by converting into complex. By contrast, real schur
decomposition is 2x faster, but does not give us a triangular factor.

I don't reckon we can beat the original logm in terms of speed, probably not
even if we code it in C++ (although that can get us closer). So it all comes
down to speed vs. accuracy issues. Probably those who really use logm may
comment.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?29768>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/