<html xmlns="http://www.w3.org/1999/xhtml"><head> <title></title> <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no"> </head> <body style="font-family:Helvetica;color:#000000;font-size:13px;"> <div id="CanaryDropbox"> </div> <blockquote id="CanaryBlockquote"> <div> <div>On Saturday, Oct 27, 2018 at 12:10 AM, Stefan van der Walt <<a href="mailto:stefanv@berkeley.edu">stefanv@berkeley.edu</a>> wrote:<br></div> <div>On Sat, 27 Oct 2018 10:27:49 +1300, Ralf Gommers wrote: <br><blockquote type="cite">Just to make sure we're talking about the same things here: Stefan, I think <br>with "sparray" you mean "an n-D sparse array implementation that lives in <br>SciPy", nothing more specific? In that case pydata/sparse is the one <br>implementation, and including it in scipy.sparse would make it "sparray". <br>I'm currently indeed leaning towards depending on pydata/sparse rather than <br>including it in scipy. <br></blockquote> <br>I want to double check: when we last spoke, it seemed as though certain <br>refactorings inside of SciPy (specifically, sparray was mentioned) would <br>simplify the life of pydata/sparse devs. That no longer seems to be the <br>case? </div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>In its current state, the only things in PyData/Sparse that depend on scipy.sparse are:</div><div><ul><li>Conversion to/from scipy.sparse spmatrix classes</li><li>A bit of linear algebra i.e. dot, tensordot, matmul.</li></ul></div>Best Regards,<div>Hameer Abbasi</div><div><br></div><blockquote><div><div> <br>If our recommended route is to tell users to use pydata/sparse instead <br>of SciPy (for the sparse array object), we probably want to get rid of <br>our own internal implementation, and deprecate spmatrix (or, build <br>spmatrix on top of pydata/sparse)? <br> <br>Once we can define a clear API for sparse arrays, we can include some <br>algorithms that ingest those objects in SciPy. But, I'm not sure we <br>have an API in place that will allow handover of such objects to the <br>existing C/FORTRAN-level code. <br> <br>Stéfan <br>_______________________________________________ <br>NumPy-Discussion mailing list <br>NumPy-Discussion@python.org <br>https://mail.python.org/mailman/listinfo/numpy-discussion <br></div> </div> </blockquote> <img id="A74E9E57616D1BB29F207B02EC7146E3" width="1px" src="http://pixels.canarymail.io:8100/track/977C99C0645380AF45E168B4CDA443F5_A74E9E57616D1BB29F207B02EC7146E3.png" height="1px"></body></html>