Matmul/generic2 #18
Matmul/generic2 #18
Conversation
…al code, not NumPy's
|
I think this can be solved much more generally by using The downside is that this would not allow people to define other kinds of sparse objects that would work with COO matrices... we could solve that by specifying an |
|
But |
|
Note also that __numpy_ufunc__ may be changing to __array_ufunc__
numpy/numpy#8247
…On Wed, May 3, 2017 at 6:43 PM, Jake Vanderplas ***@***.***> wrote:
But __array_priority__ may be superseded by __numpy_ufunc__, though I'm
not sure...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/mrocklin/sparse/pull/18#issuecomment-299056068>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AASszAjuJ9bWqgMEdksYcLU4ak-yHtmHks5r2QL3gaJpZM4NQAaT>
.
|
|
OK to close this? |
|
I still think it would be good to coerce lists/tuples as NumPy and scipy.sparse do. Closing the keyword opt-in in #17 seems reasonable since neither of you liked it. It's up to you, of course. If you want this, let me rebase this against the accepted PR and remove the unnecessary change history. The diff should just be a few lines that way. |
This is an alternative to the approach of https://github.com/mrocklin/sparse/pull/17/files. No more than one of them should be accepted.
The gist of this is that—in keeping with NumPy and scipy.sparse behavior—subclasses of
listortuplewill be automatically converted to NumPy (dense) arrays if they are passed as an argument tosparse.dot(). Any other type of object lacking an.ndimwill simply cause an exception to be raised.In contrast to PR 17, this allows no opt-out or opt-in from the coercion behavior. However, since the initial thing coerced is always a (dense) list/tuple, it cannot be too big to represent in memory (and the
np.arrayversion will only be smaller, albeit an additional object in memory).