[SciPy-Dev] GSoC Proposal draft -- Improvements to the sparse package of Scipy: support for bool dtype and better interaction with Numpy

[Blake Griffith]

Thank you Daniel, I should mention pv is the mentor for this proposal. We
have been discussing what improving numpy ndarray interaction would
involve. Maybe you can tell but the way I'm proposing to do this will be
done is not exactly well defined. The way it will probably work:

1. The numpy ufunc class will recognize it is operating on a sparse matrix,
so it will dispatch the operation and args to a 'magic function' in the
sparse package.
2. The magic function will look at the operation and type of args
(sparse/dense, sparse/sparse, sparse, etc.) then call the correct sparse
function/method. (Currently most of these are methods, but should probably
be functions, this would eliminate a lot of repeated code and help
consolidate the interface... I think.)
3. The function will do the operation and handle the guess work of whether
a sparse or dense matrix should be returned. (A lot of these functions do
not exist. e.g divide, add, etc.)

CSR/CSC matrices are the first priority. Since it is better to have them
%100 working than all sparse types be %80 working.

About ndarray/matrix incompatibilities, I should probably just change the
language of the proposal like "numpy arrays and matrices -> ndarray types".


On Tue, Apr 30, 2013 at 12:45 PM, Daniel Smith <smith.daniel.br at gmail.com>wrote:

> Daniel Smith <smith.daniel.br <at> gmail.com> writes:
>
> >
> >
> > For the ufuncs improvements, I would just recommend that you be
> > careful about potential ndarray/matrix incompatibilities. The SciPy
> > sparse class has a bunch of backends and an unpleasant amount of
> > repeated code to implement those interfaces. Consolidating interface
> > code while adding the ufunc functionality would be very helpful. Even
> > if you only consolidate some CSC/CSR repeated code, that could make
> > longer term upkeep a lot easier.
>
> >
> > Daniel
> >
>
> Looking over things again, repeated code between CSR/CSC is less of an
> issue than I thought. But the point stands for CSC/CSR and LIL.
>
> Daniel
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130430/ddd17ea5/attachment.html>