Created attachment 369 [details]
Code to reproduce problem
The Documentation states that mixing sparse and dense matrices
in addition and substraction is supported, but this does not compile.
Sorry for not having reacted to this report yet.
I can confirm your bug, also for any other combinations of dense sparse additions and subtractions.
A workaround is to use += or -= operators:
M1 = S1 - M2; // does not work at the moment
M1 = -M2; M1 += S1; // workaround
I'm marking this as blocking 3.3 and I increased the importance, since it contradicts the documentation:
Implementing this feature properly requires evaluators to proceed as the workaround, but transparently for the user.
I changed the documentation for 3.2 to note this (changeset 890ef3f93085). I did not change the docs for the dev branch because we will change it (so if we do not, we should transplant the changeset).
*** Bug 832 has been marked as a duplicate of this bug. ***
I changed the summary, to make this easier to find.
Most likely this won't be fixed before bug 99. Until then you must use the work-around.
btw, another workaround is:
M1 = S1 - M2.sparseView();
We should bench to see which approach really works best.
As expected, the "M1 = -M2; M1 += S1;" way is clearly faster but not that much, I observed a factor of about x1.5.
Done using the SparseView approach, which is much simpler to implement:
Summary: Bug 632: add support for "dense +/- sparse" operations. The current implementation is based on SparseView to make the dense subexpression compatible with the sparse one.
Next step is optimizing common use cases at the assignment level.
For the record, the implementation is not based on SparseView anymore:
Summary: Bug 632: implement general coefficient-wise "dense op sparse" operations through specialized evaluators instead of using SparseView.
This permits to deal with arbitrary storage order, and to by-pass the more complex iterator of the sparse-sparse case.
I've just implemented the respective rewriting rules for common cases: