[SciPy-dev] sparse matrix support status
schofield at ftw.at
Tue Nov 22 17:09:09 CST 2005
Thanks very much for the benchmarks and detailed comments. Your
conclusions also ring true for me, especially that matrix
construction is currently slow and that we need better documentation.
I have only one question for now. Could you please explain the comment
> dok_matrix.setdiag() appears to change the matrix shape if you're not
> careful, rendering it pretty useless for building the matrices for
in more detail? The code for setdiag() is:
def setdiag(self, values, k=0):
N = len(values)
for n in range(N):
self[n, n+k] = values[n]
which grows the matrix only if it's currently smaller than len
(values) x len(values). What's the problem this behaviour caused?
Would you prefer to fix the size of a dok_matrix in advance and have
a run-time check on the len(values)? Or was the problem with the
On 22/11/2005, at 8:05 PM, Jonathan Guyer wrote:
> On Oct 7, 2005, at 4:00 PM, I wrote:
>> regardless, pysparse is BSD
>> licensed, so it's perfectly legal to use his code to improve
>> scipy.sparse (assuming that rigorous benchmarking determines that
>> are, in fact, improvements to be made). We'll do some tests and, if a
>> merge is warranted, we'll run it by Roman out of courtesy.
> I've finally done some benchmarking of scipy.sparse and PySparse and
> posted my results and comments on plone[*]:
> Bottom line is that, with a couple of exceptions, PySparse is both
> faster and less memory intensive than SciPy. I don't know whether
> anything can be lifted from PySparse to improve SciPy's
> [*] Not that this comes as a surprise to anybody here, but the SciPy
> plone wiki is scary slow. I also couldn't get it to accept reST, even
> though I've seen other people using it there.
> Jonathan E. Guyer, PhD
> Metallurgy Division
> National Institute of Standards and Technology
> Scipy-dev mailing list
> Scipy-dev at scipy.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev