Add sparse.kron #194
Add sparse.kron #194
Conversation
Add sparse kron implementation.
| @@ -212,6 +212,65 @@ def _dot(a, b): | |||
| return aa.dot(b) | |||
|
|
|||
|
|
|||
| def kron(a, b): | |||
There was a problem hiding this comment.
What is the approach in sparse when coercing inputs? If neither input is a sparse array, do you return a dense result, or coerce to sparse?
There was a problem hiding this comment.
We generally raise a ValueError if the result is guaranteed to be dense.
There was a problem hiding this comment.
I can understand that if the inputs are sparse, but the output will be dense. In this case though the inputs are already dense. Should I forbid non-SparseArray inputs? sparse.concatenate does this, sparse.dot says it accepts non-sparse inputs, but the code errors out internally non expecting them (raises an AttributeError).
There was a problem hiding this comment.
The dot behaviour is weird, it should work on mixed or sparse only, but not on dense-dense. To answer your question: In general, we only accept dense inputs if mixed sparse-dense operations are more efficient than a dense-only one. If the dense-only operation is the best one available, we err.
For dot, there is an efficient implementation of sparse-dense and dense-sparse multiplication, as in this case. For element-wise operations, this is sometimes the case (think operator.mul), but not always (think operator.add).
This case is similar: A mixed operation could benefit from the sparse structure, but not a dense-only one.
Codecov Report
@@ Coverage Diff @@
## master #194 +/- ##
==========================================
+ Coverage 97.52% 97.57% +0.04%
==========================================
Files 11 11
Lines 1417 1444 +27
==========================================
+ Hits 1382 1409 +27
Misses 35 35
Continue to review full report at Codecov.
|
sparse/coo/common.py
Outdated
| [0, 0, 0, 1, 2, 3, 0, 0, 0], | ||
| [0, 0, 0, 0, 0, 0, 1, 2, 3]], dtype=int64) | ||
| """ | ||
| from .core import COO |
There was a problem hiding this comment.
You might want to add a fill-value is zero check here along with an additional note in the documentation. See, for example, dot.
sparse/coo/common.py
Outdated
| if a_ndim == 0 or b_ndim == 0: | ||
| return a * b | ||
| elif a_ndim > 2 or b_ndim > 2: | ||
| raise NotImplementedError("kron with ndim > 2 for either argument") |
There was a problem hiding this comment.
An additional “is not supported” will be nice here.
| @@ -212,6 +212,65 @@ def _dot(a, b): | |||
| return aa.dot(b) | |||
|
|
|||
|
|
|||
| def kron(a, b): | |||
There was a problem hiding this comment.
The dot behaviour is weird, it should work on mixed or sparse only, but not on dense-dense. To answer your question: In general, we only accept dense inputs if mixed sparse-dense operations are more efficient than a dense-only one. If the dense-only operation is the best one available, we err.
For dot, there is an efficient implementation of sparse-dense and dense-sparse multiplication, as in this case. For element-wise operations, this is sometimes the case (think operator.mul), but not always (think operator.add).
This case is similar: A mixed operation could benefit from the sparse structure, but not a dense-only one.
Glad to hear it! I figured there'd be a more efficient/elegant way to express this in ndimensions, but my immediate need was for a 2 dimensions only and using the scipy sparse implementation was easy. I look forward to seeing your implementation. I believe all concerns have been addressed. Thanks for the review, merging. |
Added
sparse.kronimplementation.