Why does this matrix contain different values depending on how it is accessed?

I am reading an mps file with the built-in matlab function mpsread. Specifically, I am trying to read the kb2 problem from the NETLIB database. The resulting left-hand side constraint matrix (that is sparse) exhibits some odd behavior. The following two commands result in different outcomes (the matrix's name is Aineq):

Aineq % shows that its entry on (15,41) is -0.31
Aineq(15,:) % shows that its entry on (15,41) is 0

Is this a common bug in using mpsread or is something else going on here?

EDIT: The following screenshot should correctly indicate what is going on:

Here, one would say that the first command would also have to include the entry found in row 15, column 41 that the second command does print. I have attached the matrix in a '.mat' file as well.

[Guillaume]

Can you save your matrix in a mat file and attach that to your question? That would greatly help in finding out what is going on.

[Walter Roberson]

I confirm your tests. I think somehow it is constructing a corrupt sparse matrix. Unfortunately the code at toolbox/optim/optim/private/readMPSfile.p is not readable so we can't see exactly what it is doing.

[Walter Roberson]

Notice:

[r,c] = find(Aineq - full(Ain))
r =
    10
    11
    12
    15
c =
    41
    41
    41
    41

That should be impossible.

[Ernst Roos]

This, indeed, should be impossible. Seeing that the matrix in question only has 4 entries in this column, this might be caused by some error/inconsistency in the mps file at this variable. I'll try to look into it, thanks for your efforts so far.

[Walter Roberson]

It should not matter what the (text) file has, sparse matrices are not supposed to have inconsistent values. I think it is a bug in the internal code for readMPSfile.p; I recommend you create a bug report.

[Cedric]

DISP, SPY, FIND, all find this -0.31 value, converting to full and back to sparse eliminates the corruption. And it's not just a display issue (when indexed):

 >> a = A(15,:) ;  % Var a is corrupted as well 
 >> a
 a =
   (1,35)    98.500000000000000
   (1,40)    -0.810000000000000

 >> a = A(15,41)
 a =
   All zero sparse: 1×1

 >> a = A(14:15,41)
 a =
   (2,1)     -0.310000000000000

[Ernst Roos]

Thanks for your work and comments. For now, I'll convert it to full and back and submit a bug report on the readMPSfile function.

Answer 1

[James Tursa]

This sparse matrix is invalid. The SPOK utility from the FEX by Tim Davis reveals the problem:

>> spok(A)
Warning: 2 jumbled row indices, 0 explicit zeros 
ans =
     0

Whatever process/program/function that was used to generate this sparse matrix did so incorrectly.

You can see the jumbled row indices simply by printing the values to the screen:

>> A
A =
  1.0e+002 *
   (1,1)     -0.991855900000000
   (2,1)     -0.946356800000000
   (3,1)     -0.980897600000000
   (4,1)     -1.030581000000000
   (5,1)     -0.987027700000000
   (6,1)     -1.020219100000000
  (17,1)      0.060000000000000
  (19,1)      0.040000000000000
  (20,1)      0.503000000000000
     :               :
  (15,41)    -0.003100000000000
  (11,41)     0.010000000000000
  (12,41)     0.010000000000000
  (10,41)     0.010000000000000

The sparse printing utility simply prints the row/col/value data as they appear in memory. In a correctly built sparse matrix, these should be in column order. That is, the row indexes should be increasing for each column that is printed. Once a column is completely printed, then the next column is printed. But you can see in the above display that the row indexes for the 41st column are not increasing ... they are "jumbled". This sparse matrix was incorrectly built and will cause downstream issues. Going to full and then back to sparse fixes the problem because this causes the sparse matrix to be rebuilt from scratch from the full data with the row indexes in the proper order:

>> sparse(full(A))
ans =
  1.0e+002 *
   (1,1)     -0.991855900000000
   (2,1)     -0.946356800000000
   (3,1)     -0.980897600000000
   (4,1)     -1.030581000000000
   (5,1)     -0.987027700000000
   (6,1)     -1.020219100000000
  (17,1)      0.060000000000000
  (19,1)      0.040000000000000
  (20,1)      0.503000000000000
     :               :
  (10,41)     0.010000000000000
  (11,41)     0.010000000000000
  (12,41)     0.010000000000000
  (15,41)    -0.003100000000000

https://www.mathworks.com/matlabcentral/fileexchange/20186-spok--checks-if-a-matlab-sparse-matrix-is-ok

*** EDIT ***

spok has been removed from the FEX. You can use my replacement function sarek instead:

https://www.mathworks.com/matlabcentral/fileexchange/158161-sarek-sparse-analyzer-real-et-komplex?s_tid=srchtitle

[Ernst Roos]

Thanks for your elaborate explanation! I did not know of this spok function, thanks for bringing this to my attention!