[SciPy-dev] Refactoring of csc/csr sparse matrices

Tim Leslie tim.leslie at gmail.com
Thu Jan 11 00:06:14 CST 2007


On 1/11/07, Nathan Bell <wnbell at gmail.com> wrote:
> On 1/10/07, Tim Leslie <tim.leslie at gmail.com> wrote:
> > The problem is that changing these names would break the current
> > interface. This could be un-broken by using __getattr__/__setattr__ to
> > trap all calls to rowind/colind and pass them on to 'indices'.
> >
> > So, the question is should we a) make no change, b) make the change
> > and change the interface or c) make the change but keep the old
> > interface. I'm personally in favour or c), but I'd like to hear what
> > other people have to say.
>
> Option C is fine with me.  Should deprecation warning be printed if
> rowind/colind is used?
>

That's definitely a possible option. What do other people think?

>
>
> Also, in your current code you have things like:
> 487         def __add__(self, other, self_ind, other_ind, fn, cls):
> <snip>
> 493             elif isspmatrix(other):
> 494                 other = other.tocsc()
> 495                 if (other.shape != self.shape):
> 496                     raise ValueError, "inconsistent shapes"
> 497                 if other_ind:
> 498                     other = other.tocsc()
> 499                     other_ind = other.rowind
> 500                 else:
> 501                     other = other.tocsr()
> 502                     other_ind = other.colind
>
>
> With the change to .indices, a somewhat better/more efficient approach would be:
>
> 487         def __add__(self, other, self_ind, other_ind, fn, cls):
> <snip>
> 493             elif isspmatrix(other):
> 494                 other = cls(other)
> 495                 if (other.shape != self.shape):
> 496                     raise ValueError, "inconsistent shapes"
>
> The constructor of cls should do the proper conversion (if necessary)
> for you.  With this, I believe self_ind and other_ind become
> unnecessary.
>

Yep, those and many other changes are sitting here in my patch waiting
to be applied.

> Thanks for refactoring those classes, maintaining them separately was
> a bit tedious :)
>

No worries :-)

Tim

> --
> Nathan Bell wnbell at gmail.com
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


More information about the Scipy-dev mailing list