Mon 21 Nov 2016 07:42:22 PM UTC, comment #7:
At least we understand what behavior needs to be implemented. At a minimum, Octave needs to check whether each operand contains a NaN and it needs to specifically guarantee that those locations result in NaN at the output. The subsequent decision, about whether to convert to full if it would save space, should probably be left up to Octave, or to the sparse_auto_mutate code.
Pseudo-code which might work for Z = X op Y:
Of course, all of that would need to be in C++.
Another choice would be to look carefully at the code which performs the operation 'op'. For sparse matrices, I believe the code is equivalent to
The "intersection" function for sparse matrices in C++ could be changed to include elements where only one of the matrices had a NaN.
|
Mon 21 Nov 2016 05:49:15 PM UTC, comment #6:
Matlab R2016a:
Rik, I understand your suggestion may not be worse than the current status, but it seems the memory issue does happen in Matlab.
|
Mon 21 Nov 2016 04:44:23 PM UTC, comment #5:
@Carlo: The memory problem already exists. After one of the operations involving NaN, every single element will become NaN and require storage. In fact, the situation will be worse than a full matrix because there will be the extra overhead of the sparse matrix implementation.
In general, even without sparse_auto_mutate set to true, Octave will convert to full for operations that are likely to result in a full matrix. From the documentation,
For addition and subtraction, the sparse matrices are already converted to full and the NaN is added/subtracted and the operation follows IEEE guidelines. For Sparse Matrix OPERATION Scalar NaN, the code would be easy to modify to check for NaN and then return
For Matrix OPERATION Matrix operations it becomes a bit annoying because one would have to check for isnan() on every element. This may be what Matlab does. Can you test the following?
|
Mon 21 Nov 2016 10:48:04 AM UTC, comment #4:
Rik :
so your solution does not seem to be compatible.
Anyway, I wouldn't like that solution even if it were compatible
as any error in filling the elements of a large sparse matrix would result in out-of-memory.
|
Sun 20 Nov 2016 03:25:31 PM UTC, comment #3:
Any obvious solution would be for NaN to force all matrices into a full implementation.
What does Matlab do for
|
Sat 19 Nov 2016 09:45:39 PM UTC, comment #2:
This issue still exists with Octave 4.2.0.
|
Thu 31 May 2012 08:43:26 PM UTC, comment #1:
Confirmed on a recent (5/31/12) development tip.
The issue is more general than just divide so I have changed the bug Summary.
At present, I can verify that multiply and divide are affected while addition and subtraction behaves correctly.
The issue appears to be a side effect of the way that sparse matrices improve calculation performance. In general, math operations like multiply and divide only need to be performed on the non-zero elements of a sparse matrix. However, a NaN is different and should affect all elements of the matrix.
Below is some simple code to illustrate the problem.
|
Wed 30 May 2012 03:12:51 PM UTC, original submission:
rdivide with NaN as first argument does not behave as expected with sparse array as second argument. NaN/0 = NaN, which implies NaN rdivided by sparse should give NaN's in the positions of the the zero pattern as well as NaN's in the non-zero pattern.
Example
I would expect the answer to be:
|