[SciPy-Dev] scipy.sparse spdiags/dia_matrix additional calling mode

Tony Stillfjord tony@maths.lth...
Thu Oct 6 03:59:07 CDT 2011


Dear all,


Given that Python is not MATLAB, would it be possible to add an additional,
in some

cases more intuitive, way of calling the spdiags function? This function
creates a sparse

matrix given its non-zero diagonals.


 Currently, the first input has to be an array 'data' where every row
corresponds to a

diagonal - which one is specified in the next input, 'diags'. However, as
the diagonals

have different length, the actual values have to be zero-padded on either
the left or

right end to fit the array. This is not a big problem if all the elements in
a diagonal are

the same, for example


 spdiags([ones(4), -2*ones(4), ones(4)], (-1,0,1), 4, 4)


works nicely as some values are just ignored.


But when that is not the case, and all the values are already stored in some
arrays, it

does not make sense that the user should have to pad them with a number of
zeros

(remembering on which end to put them!) and then also construct one more
temporary

array to hold them.


 I suggest that spdiags accepts a list/tuple as data input, where every list
element is

supposed to be an array holding a diagonal of the correct size. That is,
instead of doing

something like


 spdiags(row_stack(r_[zeros(2), a], b, r_[c, zeros(3)]), (-2, 0, 3), n, n )


one would write


spdiags([a,b,c], (-2, 0, 3), n, n)


Does that make sense? What it boils down to is that you should not have to
know

how the matrix type is implemented to use it - right? The diagonals could
just as well

be stored in different ways than they are currently.


When I had a look at the source code, it seems that all the work is done in
the

dia_matrix __init__ method, but the same argument applies there.


 Currently, you -can- send in a list [a,b,c] where a, b and c are arrays of
different

length, but the function atleast_2D() is applied to the list which turns it
into an array

of objects. This obviously causes problems.


Kind regards,

Tony Stillfjord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20111006/e53b544b/attachment.html 


More information about the SciPy-Dev mailing list