bugGNU Octave - Bugs: bug #45622, Sparsity of sparse matrix when...

 
 

bug #45622: Sparsity of sparse matrix when assigning all elements

Submitted by:  Amro <amro_octave>
Submitted on:  Sat 25 Jul 2015 04:13:18 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: WTF, Matlab?!?
Status: Wont FixAssigned to: None
Originator Name: Open/Closed: Closed
Release: 4.0.0Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 25 Jul 2015 05:37:13 PM UTC, comment #3:

Thanks for testing. I think we can leave this as a Matlab quirk and not introduce it to Octave. I much prefer to see programmer's make a conscious choice, by using full (M), if they want a full matrix rather than having the conversion from sparse to full be a side effect of a particular value assignment.

Rik <rik5>
Project Administrator
Sat 25 Jul 2015 04:20:26 PM UTC, comment #2:

Interesting, I didn't know about the "sparse_auto_mutate" option!

As for your interpretation of the expression M(:), I'm not sure it applies to MATLAB, it being similar in behavior to REPMAT...

The above is no different from the previous code with "M(:) = 1" when run in MATLAB.

As for mixing different data types, there are well-defined rules for up/down-casting between unlike classes, as described in this documentation page:

http://www.mathworks.com/help/matlab/matlab_prog/valid-combinations-of-unlike-classes.html

So according to the previous link, the matrix stays uint8 as expected, and the 1.1 elements are basically rounded to 1, i.e equivalent to writing "M(:) = uint8(1.1)". I view sparsity as an attribute of the array not a data type on its own.

The way I see it, "M(:) = ..." is simply treated as a special case in MATLAB, and the sparse matrix gets converted to full unless the scalar value 0 is used as in "A(:)=0".

I'm not necessarily asking to reproduce the behavior in Octave... Personally I think a sparse matrix should remain so no matter what operation is performed on it, excluding of course explicit conversion to FULL.

Amro <amro_octave>
Sat 25 Jul 2015 03:42:09 PM UTC, comment #1:

I don't think we want to mimic this behavior. The expression M(:) refers to all elements in an array, but it appears that Matlab is interpreting this to mean the matrix itself. In pseudo-code,

which takes its characteristics (full or sparse) from the first argument to repmat.

What does Matlab do for the following?

If they are consistent, then class of M will change to double, but that is most definitely not what you want. Another test, just for fun.

Does that preserve sparsity?

Octave also supports the sparse_auto_mutate variable which will convert sparse matrices to full ones when the storage is smaller as a full matrix. It is off by default, but try

Rik <rik5>
Project Administrator
Sat 25 Jul 2015 04:13:18 AM UTC, original submission:

I was reading bug #45589, and I found other incompatibilities with regard to sparse matrices.

Consider the following example:

In the latest MATLAB R2015a, the matrix "M" becomes full, while in Octave 4.0.0 it maintains its sparsity.

I guess MATLAB determined that it was more space-efficient to just convert the matrix to full rather than just keep it in sparse storage, seeing that we fill all the elements with non-zero values.

Note that the outcome is different from the following code:

where the matrix "M" stays sparse in both MATLAB and Octave.


Another inconsistency:

In Octave, all three cases are the same, and the resulting matrix remains sparse.
However in MATLAB, "A1" is the only one that stays sparse, and the other two "A2" and "A3" are converted to full. Also note that the "A1" storage (nzmax) is expanded to one.

So it seems that "A(:) = scalar" is treated differently from "A(:) = vector/matrix" in MATLAB, even if scalar/vector/matrix are all zeros...

Amro <amro_octave>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by amro_octave (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 25 Jul 2015 05:37:13 PM UTCrik5StatusNone=>Wont Fix
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1