From octave-maintainers-request at bevo dot che dot wisc dot edu  Tue May 11 15:04:25 1999
Subject: bug in expm
From: "Ross A. Lippert" <ripper at cs dot sandia dot gov>
To: "octave-maintainers at bevo dot che dot wisc dot edu"   <octave-maintainers@bevo.che.wisc.edu>
Date: Tue, 11 May 1999 14:03:52 -0600


Hmmm it gets worse and worse.  OK, so there is this weird nonassignment
to retval that
happens in dMatrix::exp which should be taken care of somehow (even a
warning message
so it is not such a surprise), but not on to how we get there in the
first place.

dMatrix::exp ends up solving a very ill-conditioned system bc the first
preconditioning
step is performed via AEPBALANCE, performing a balancing similarity
transformation
(interchange and rescale the rows and columns of M until you are
happy).  To undo the
balancing the code employs the .solve() function to invert the balancing
matrix.  Not
only is this a waste of time for something that is just a permutation
with rescaling,
but it will take solve down the nonassigning path is M is exceptionally
ill-conditioned.

That is, while any monkey can invert [1 0; 0 1e-16] perfectly well,
.solve() can't.
I conclude from this that .solve() is not the right way to undo the
balancing step and
I will try to formulate an alternative.

sound good?

-r