On Saturday, Oct 27, 2018 at 12:10 AM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Sat, 27 Oct 2018 10:27:49 +1300, Ralf Gommers wrote:
Just to make sure we're talking about the same things here: Stefan, I think
with "sparray" you mean "an n-D sparse array implementation that lives in
SciPy", nothing more specific? In that case pydata/sparse is the one
implementation, and including it in scipy.sparse would make it "sparray".
I'm currently indeed leaning towards depending on pydata/sparse rather than
including it in scipy.

I want to double check: when we last spoke, it seemed as though certain
refactorings inside of SciPy (specifically, sparray was mentioned) would
simplify the life of pydata/sparse devs. That no longer seems to be the
case? 

Hi! I can’t recall having said this, perhaps you inferred it from the docs (it’s on the front page, so that isn’t unreasonable). We should update that sometime.

That said, we use very little of scipy.sparse in PyData/Sparse. When Matt Rocklin was maintaining the project, that was the case, but even in the later days he shifted much of his code to pure NumPy. I followed that path further, not out of unwillingness to depend on it, but out of desire for generality.

In its current state, the only things in PyData/Sparse that depend on scipy.sparse are:
Best Regards,
Hameer Abbasi


If our recommended route is to tell users to use pydata/sparse instead
of SciPy (for the sparse array object), we probably want to get rid of
our own internal implementation, and deprecate spmatrix (or, build
spmatrix on top of pydata/sparse)?

Once we can define a clear API for sparse arrays, we can include some
algorithms that ingest those objects in SciPy. But, I'm not sure we
have an API in place that will allow handover of such objects to the
existing C/FORTRAN-level code.

Stéfan
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion