Re: Is there anything else that should be fixed for 2.9.5 or 2.1.73?

[David Bateman]

John W. Eaton wrote:
> I think I've fixed most of the serious problems in my queue so I'm
> planning to make a new set of snapshots, perhaps this weekend or on
> Monday.  If there are any other problems you know of that should be
> fixed before I do that, please speak up soon!
>
> Thanks,
>
> jwe
>
>   
Yes, I have one problem, which I'm not quite sure of the best  solution. 
In the sparse-dmsolve.cc file I call the SparseMatrix::solve and
SparseComplexMatrix::solve member function where I would have preferred 
to call the SparseMatrix::fsolve and SparseComplexMatrix::fsolve 
functions. The problem is that although the Dulmange Mendelsogn 
guarantees that the structural rank of the matrix called with the LU 
solvers is not rank deficient. The matrix can be numerically rank 
deficient. The result of the recent change I made where ::solve now 
itself calls ::dmsolve if a singular matrix is found can now cause an 
infinite loop for a structurally non-rank deficient matrix that is 
numerically rank deficient.

I tried making the dmsolve template functions friends of SparseMatrix 
and SparseComplexMatrix so that I could call fsolve, however having 
never trying doing something like this it appears that this is not 
possible. Barring that I see several solutions that are possible

1) Go back to the old sparse-xdiv.cc code where the singular solver is 
called separately from the main solver. The reason I made this change is 
that ::solve is now the only entry point into the sparse matrix solve 
code, which is much neater to me. So I'd prefer not to see this change, 
and in fact would like to see something similar for Matrix and 
ComplexMatrix, so the src/xdiv.cc code can disappear.
2) Add an argument to the solve code that is just there for the dmsolve 
function to prevent ::solve from recalling dmsolve. This is slightly 
ugly, but perhaps less than the above.
3) Try and rewrite the dmsolve template functions as a template class or 
as part of the SparseMatrix class itself. In the first case, the class  
can be made a friend of SparseMatrix and SpaseComplexMatrix,and the 
second it implicitly as access. This seems to be a relatively large 
change for limited gain, and I'm not sure that I can do it without code 
duplication, which was the reason to write the code as a template 
function in the first place.
4) Make fsolve public (is protected enough?) so dmsolve can access it.

John what solution do you want? I'd like to have this in 2.9.5 as the 
dmsolve code can lock up octave the way it is now...

Cheers
David