Tue 08 Feb 2011 11:53:48 PM UTC, comment #2:
Strictly speaking the sparse code doesn't need to make the assumption that the row indexes are in order, however doing so makes some code simpler, while making other code more difficult. I made the choice when I started writing the sparse code to assume that the row indexes were ordered and all of the sparse code would have to be gone over to remove this assumption. So probably the best thing to do here is to modify PM * SM so that it to orders the row indexes. Fortunately, by its nature SM * PM already does so.
Here is a patch that I think does the right thing but its received little testing
D.
(file #22632)
|
Tue 08 Feb 2011 07:57:56 AM UTC, comment #1:
[Reposting because I screwed up a verbatim tag and the report on the web was incomplete; I wish this thing had a preview button...]
While investigating the following bug report
https://mailman.cae.wisc.edu/pipermail/bug-octave/2011-February/017300.html
I uncovered a problem with multiplying permutation and sparse matrices.
Given
I was trying to verify that
was numerically zero, but found
Note the strange result that some elements apparently have two values!
However,
returns a matrix of zeros. Playing around a bit more, I noticed
Note the elements in columns 7 and 8 are out of order. I assume that the sparse matrix multiplication algorithm assumes that the elements in each column are ordered by ascending row number.
I've looked at the code in Sparse-perm-op-defs.h, but I think it will take me a while to figure this out, so I would really appreciate it if someone who understands this code better could take a look at this problem.
I'm adding the following people to the CC list for this report: Jason Reidy since he is listed as the author of Sparse-perm-op-defs.h, Jaroslav Hajek because he is the author of the permutation matrix code, and David Bateman because he has good knowledge of the sparse matrix code.
|