[SciPy-Dev] removing umfpack wrapper

Ralf Gommers ralf.gommers at gmail.com
Thu Nov 14 15:59:15 EST 2013


On Tue, Nov 12, 2013 at 11:57 PM, Robert Cimrman <cimrman3 at ntc.zcu.cz>wrote:

> On 11/12/2013 11:22 PM, Ralf Gommers wrote:
> > On Tue, Nov 12, 2013 at 10:20 AM, Robert Cimrman <cimrman3 at ntc.zcu.cz
> >wrote:
> >
> >> Hi Ralf,
> >>
> >> On 11/10/2013 04:36 PM, Ralf Gommers wrote:
> >>> Hi all,
> >>>
> >>> This is long overdue, but I think it's time to remove the UMFPACK
> wrapper
> >>> before the next release. I'd like some feedback on how to do that and
> to
> >>> what package (if any) to point existing users.
> >>>
> >>> As for why to remove the wrapper, see:
> >>> https://github.com/scipy/scipy/issues/3002
> >>> http://permalink.gmane.org/gmane.comp.python.scientific.user/20451
> >>> Short summary: UMFPACK changed from a BSD-compatible license to GPL at
> >> some
> >>> point.
> >>>
> >>> The deprecation warning in sparse.linalg has been referring people to
> >>> scikits.umfpack until now, however that package has disappeared
> >> completely
> >>> as far as I can tell. I suspect it was in the old scikits svn repo and
> >> was
> >>> never moved before that was killed. The alternatives seems to be
> >> Pysparse (
> >>
> >> I missed that the scikit was lost in transition...
> >>
> >> How much work would be to move it to the new site - move from SVN to
> git,
> >> and?
> >> I would be willing to do it, if there is interest.
> >>
> >
> > Hi Robert, I think the moving wouldn't be a lot of work (assuming svn
> > access can still be arranged). If you'd revive the scikit it's not a
> > one-time effort though - it's only useful if the code is being maintained
> > imho. That can still be low effort perhaps, but with reviewing some PRs,
> > maintenance releases, putting it on pypi, etc. I'd expect at least an
> hour
> > a week or so.
> >
> > Are there scikits.umfpack users now? Would it make sense to salvage
> > whatever is useful from the scikit and contribute it to pysparse instead?
>
> We are using it in sfepy as the default direct solver. It seems to me that
> the
> pysparse interface requires the input matrix to be in the LL (linked list)
> format, which is unfortunate for us, as we use CSR. The scipy (and former
> scikit) umfpack wrappers have used CSR, so no copies were necessary. (After
> all, I have created the original scipy wrappers to be used from sfepy in
> the
> first place...)
>

CSR is much better supported by scipy.sparse, so that's a good reason for
the scikits.umfpack interface to exist I'd think.


> So in case others are not interested in having the scikit,


I'm not sure that's the case. Would be great to have some more feedback
here - I don't have a strong opinion either way.


> I can see two possible solutions from my perspective: either enhance
> pysparse interface to
> allow CSR as well, or move the wrappers to sfepy (which I maintain anyway,
> but
> swig -> cython conversion would be needed). Not sure yet which solution I
> prefer.
>

Moving them into SfePy would work for SfePy but as an optional dependency
for scipy that would be weird imho, given the rather heavy list of
dependencies of SfePy.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131114/8e0e07d2/attachment.html>


More information about the SciPy-Dev mailing list