On 11/12/2013 11:22 PM, Ralf Gommers wrote:
On Tue, Nov 12, 2013 at 10:20 AM, Robert Cimrman <cimrman3@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...) So in case others are not interested in having the scikit, 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. Cheers, r.
Cheers, Ralf
Cheers, r.
http://pysparse.sourceforge.net) and PyUBlasExt ( https://pypi.python.org/pypi/PyUblasExt). Scikits.sparse is dead(-ish) and doesn't wrap umfpack it looks like. PyUBlasExt has something that looks like a wrapper but for C++ (?). So can we refer people to pysparse?
Other question: do we call Pysparse instead of scikits.umfpack when available? And if so, by default or not? Or do we rip out everything that sits under useUmfpack=True?
Cheers, Ralf
On Tue, Nov 12, 2013 at 11:57 PM, Robert Cimrman <cimrman3@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@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
On 11/14/2013 09:59 PM, Ralf Gommers wrote:
On Tue, Nov 12, 2013 at 11:57 PM, Robert Cimrman <cimrman3@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@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.
Ok, so I will try to migrate it to the new scikits site.
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 think most people still use it transparently via the wrappers in scipy, without installing the (old) scikit, just like me. When the wrappers disappear they would seek a replacement.
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.
Yes, that was just an idea for the case nobody else uses umfpack with scipy. I do not think that is true, although the users has remained silent here. There might be more feedback on scipy-user. Anyway, I will migrate the scikit so that there is a place to go after the removal. The maintenance should not be that demanding as the umfpack library API has been quite stable. r.
On Thu, Nov 14, 2013 at 11:09 PM, Robert Cimrman <cimrman3@ntc.zcu.cz>wrote:
On Tue, Nov 12, 2013 at 11:57 PM, Robert Cimrman <cimrman3@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@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
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
the pysparse interface requires the input matrix to be in the LL (linked
format, which is unfortunate for us, as we use CSR. The scipy (and
On 11/14/2013 09:59 PM, Ralf Gommers wrote: maintained that list) 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.
Ok, so I will try to migrate it to the new scikits site.
Great. I'm not sure that that will live forever (who maintains it?). Just putting the repo on Github and enabling issue tracking there, plus uploading a release to pip, would be the essential steps. Ralf
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 think most people still use it transparently via the wrappers in scipy, without installing the (old) scikit, just like me. When the wrappers disappear they would seek a replacement.
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.
Yes, that was just an idea for the case nobody else uses umfpack with scipy. I do not think that is true, although the users has remained silent here. There might be more feedback on scipy-user.
Anyway, I will migrate the scikit so that there is a place to go after the removal. The maintenance should not be that demanding as the umfpack library API has been quite stable.
r.
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On 11/14/2013 11:09 PM, Robert Cimrman wrote:
On 11/14/2013 09:59 PM, Ralf Gommers wrote:
On Tue, Nov 12, 2013 at 11:57 PM, Robert Cimrman <cimrman3@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@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.
Ok, so I will try to migrate it to the new scikits site.
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 think most people still use it transparently via the wrappers in scipy, without installing the (old) scikit, just like me. When the wrappers disappear they would seek a replacement.
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.
Yes, that was just an idea for the case nobody else uses umfpack with scipy. I do not think that is true, although the users has remained silent here. There might be more feedback on scipy-user.
Anyway, I will migrate the scikit so that there is a place to go after the removal. The maintenance should not be that demanding as the umfpack library API has been quite stable.
FYI: https://github.com/rc/scikit-umfpack (sources taken from the last version that was in scipy) r.
On Fri, Oct 24, 2014 at 3:55 PM, Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
On 11/14/2013 11:09 PM, Robert Cimrman wrote:
Anyway, I will migrate the scikit so that there is a place to go after
removal. The maintenance should not be that demanding as the umfpack
the library
API has been quite stable.
FYI: https://github.com/rc/scikit-umfpack (sources taken from the last version that was in scipy)
Nice, thanks Robert! Ralf
participants (2)
-
Ralf Gommers -
Robert Cimrman