headers
Robert Cimrman | 2 Jan 11:03
Picon

Re: The future of the scipy.sandbox and a reminder of upcoming doc-day

Nathan Bell wrote:
> On Dec 27, 2007 9:11 PM, Jarrod Millman <millman <at> berkeley.edu> wrote:
>>> I'd like to see arpack in the sparse folder (?) very fast as some my code
>>> would need a sparse solver (I proposed that it could be moved in a scikit
>>> but it makes sense to keep it in scipy so that sparse solvers are available
>>> in scipy).
>> Yes, arpack should go into the sparse package.  If you have the time,
>> it would be great if you could help get it moved over.  Ideally, we
>> can get it moved into scipy.sparse before the 0.7 release around the
>> end of March.
> 
> How do you see sparse being structured?  Currently sparse contains
> only the sparse matrix classes and a handful of creation functions
> (e.g. spdiags) and the iterative solvers live in
> scipy.linalg.iterative.

IMHO iterative solvers (eigen- or linear) do not care about the format 
of matrices they work with - all they need is the matrix action on a 
vector. Due to this I think they do not belong under scipy.sparse - they 
should work without change for dense matrices, or even for matrix-like 
objects that have only the matrix action (A*x) implemented. lobpcg.py 
works like that already - a user can pass in a dense/sparse matrix or a 
function.

> It would be strange to put an eigensolver under sparse and iterative
> methods for linear systems under linalg.  Also, lobpcg should live
> along side arpack wherever they end up.  I could imagine a structure
> like:
> 
> scipy.iterative.linear (for cg/gmres etc.)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Nathan Bell | 2 Jan 21:37
Picon
Gravatar

Re: The future of the scipy.sandbox and a reminder of upcoming doc-day

On Jan 2, 2008 4:03 AM, Robert Cimrman <cimrman3 <at> ntc.zcu.cz> wrote:
> IMHO iterative solvers (eigen- or linear) do not care about the format
> of matrices they work with - all they need is the matrix action on a
> vector. Due to this I think they do not belong under scipy.sparse - they
> should work without change for dense matrices, or even for matrix-like
> objects that have only the matrix action (A*x) implemented. lobpcg.py
> works like that already - a user can pass in a dense/sparse matrix or a
> function.
>
> +1. Maybe instead of 'iterative' I would use something like
> 'isolve(r(s))' to indicate their purpose better.

Travis suggested creating scipy.splinalg to include the sparse solvers
and other functionality.  We could have:

splinalg.factor  --  direct factorization methods (e.g. SuperLU)
splinalg.eigen  -- sparse eigensolvers (e.g. ARPACK, lobpcg)
splinalg.solve  -- sparse solvers for linear systems (e.g. CG, GMRES)

In the process we'd eliminate scipy.linsolve and
scipy.linalg.iterative and move that code to splinalg.factor and
splinalg.solve respectively.  We could then draw a distinction between
scipy.linalg -- dense linear algebra and splinalg -- sparse linear
algebra.  We could then move sparse functions spkron and spdiags to
splinalg.construct or something like that.

I'm not married to any of the names above, so feel free to offer alternatives.

I agree with your statement that such solvers should not be
exclusively for sparse matrices.  However it's important to set them
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ondrej Certik | 2 Jan 21:50
Picon
Gravatar

Re: The future of the scipy.sandbox and a reminder of upcoming doc-day

On Jan 2, 2008 9:37 PM, Nathan Bell <wnbell <at> gmail.com> wrote:
> On Jan 2, 2008 4:03 AM, Robert Cimrman <cimrman3 <at> ntc.zcu.cz> wrote:
> > IMHO iterative solvers (eigen- or linear) do not care about the format
> > of matrices they work with - all they need is the matrix action on a
> > vector. Due to this I think they do not belong under scipy.sparse - they
> > should work without change for dense matrices, or even for matrix-like
> > objects that have only the matrix action (A*x) implemented. lobpcg.py
> > works like that already - a user can pass in a dense/sparse matrix or a
> > function.
> >
> > +1. Maybe instead of 'iterative' I would use something like
> > 'isolve(r(s))' to indicate their purpose better.
>
> Travis suggested creating scipy.splinalg to include the sparse solvers
> and other functionality.  We could have:
>
> splinalg.factor  --  direct factorization methods (e.g. SuperLU)
> splinalg.eigen  -- sparse eigensolvers (e.g. ARPACK, lobpcg)
> splinalg.solve  -- sparse solvers for linear systems (e.g. CG, GMRES)
>
> In the process we'd eliminate scipy.linsolve and
> scipy.linalg.iterative and move that code to splinalg.factor and
> splinalg.solve respectively.  We could then draw a distinction between
> scipy.linalg -- dense linear algebra and splinalg -- sparse linear
> algebra.  We could then move sparse functions spkron and spdiags to
> splinalg.construct or something like that.
>
> I'm not married to any of the names above, so feel free to offer alternatives.
>
> I agree with your statement that such solvers should not be
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ondrej Certik | 2 Jan 21:51
Picon
Gravatar

Re: The future of the scipy.sandbox and a reminder of upcoming doc-day

On Jan 2, 2008 9:50 PM, Ondrej Certik <ondrej <at> certik.cz> wrote:
>
> On Jan 2, 2008 9:37 PM, Nathan Bell <wnbell <at> gmail.com> wrote:
> > On Jan 2, 2008 4:03 AM, Robert Cimrman <cimrman3 <at> ntc.zcu.cz> wrote:
> > > IMHO iterative solvers (eigen- or linear) do not care about the format
> > > of matrices they work with - all they need is the matrix action on a
> > > vector. Due to this I think they do not belong under scipy.sparse - they
> > > should work without change for dense matrices, or even for matrix-like
> > > objects that have only the matrix action (A*x) implemented. lobpcg.py
> > > works like that already - a user can pass in a dense/sparse matrix or a
> > > function.
> > >
> > > +1. Maybe instead of 'iterative' I would use something like
> > > 'isolve(r(s))' to indicate their purpose better.
> >
> > Travis suggested creating scipy.splinalg to include the sparse solvers
> > and other functionality.  We could have:
> >
> > splinalg.factor  --  direct factorization methods (e.g. SuperLU)
> > splinalg.eigen  -- sparse eigensolvers (e.g. ARPACK, lobpcg)
> > splinalg.solve  -- sparse solvers for linear systems (e.g. CG, GMRES)
> >
> > In the process we'd eliminate scipy.linsolve and
> > scipy.linalg.iterative and move that code to splinalg.factor and
> > splinalg.solve respectively.  We could then draw a distinction between
> > scipy.linalg -- dense linear algebra and splinalg -- sparse linear
> > algebra.  We could then move sparse functions spkron and spdiags to
> > splinalg.construct or something like that.
> >
> > I'm not married to any of the names above, so feel free to offer alternatives.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nathan Bell | 2 Jan 22:15
Picon
Gravatar

Re: The future of the scipy.sandbox and a reminder of upcoming doc-day

On Jan 2, 2008 2:51 PM, Ondrej Certik <ondrej <at> certik.cz> wrote:
> > No comments, just agree with everything you said.
> >
> > Actually one comment - how could one plug more solvers to the above
> > architecture?
> > (pysparse comes to my mind)

I would think a JDSYM solver like the one in pysparse could live in
splinalg.eigen

> and blzpack - that one is BSD, so it could even go to scipy.

Likewise for blzpack

--

-- 
Nathan Bell wnbell <at> gmail.com
Permalink | Reply | 0 comments |
headers
Nathan Bell | 3 Jan 00:34
Picon
Gravatar

matlab5 sparse IO

First let me thank those who have contributed to MATLAB IO in scipy.

I noticed that the Matlab4 sparse writer was a little slow, so I sped
it up using the coo_matrix format.  Anyway, I was going to do the same
for the Matlab5 writer, but it seems to be broken.  It appears that
the V5 code was a copy/paste of the V4 method, which it shouldn't be.
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/io/matlab/mio5.py#L662

Looking at the V5 sparse reader:
 http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/io/matlab/mio5.py#L349
suggests that the CSC format should be used when writing, but the
present code - even if it worked properly - appears to be writing out
a triplet format (as is done in V4).

I don't fully understand all the magic in the matlab IO code, but I'd
be happy to help whomever maintains it in adding sparse V5 support.

Here's a simple test that currently fails:

from scipy import *
from scipy.sparse import *
from scipy.io import *
from numpy.testing import *

A = csr_matrix([[1.0,0.0,2.0],[0,-3.5,0]])
savemat('test4.mat', { 'A': A }, format='4')
A4 = loadmat('test4.mat')['A']
assert_equal(A.todense(),A4.todense())

savemat('test5.mat', { 'A': A }, format='5')
(Continue reading)

Permalink | Reply | 7 comments |
headers
Matthew Brett | 3 Jan 00:58
Picon
Gravatar

Re: matlab5 sparse IO

Hi Nathan,

> I noticed that the Matlab4 sparse writer was a little slow, so I sped
> it up using the coo_matrix format.  Anyway, I was going to do the same
> for the Matlab5 writer, but it seems to be broken.  It appears that
> the V5 code was a copy/paste of the V4 method, which it shouldn't be.
> http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/io/matlab/mio5.py#L662

I'm sorry - this was my fault - I did most of the initial rewrite of
the code, but haven't been paying it enough attention since then - so
thanks for your reminder.

> I don't fully understand all the magic in the matlab IO code, but I'd
> be happy to help whomever maintains it in adding sparse V5 support.

Thanks - I am sure that will be useful.  At the moment I'm trying to
recover from flu, and porting the scipy tests over to nose, an
intriguing combination.  But it would be good to get onto this soon.

Will anyone else have time to join in here?  Stefan?

Thanks again,

Matthew
Permalink | Reply | 3 comments |
headers
Nathan Bell | 3 Jan 01:11
Picon
Gravatar

Re: matlab5 sparse IO

On Jan 2, 2008 5:58 PM, Matthew Brett <matthew.brett <at> gmail.com> wrote:
>
> I'm sorry - this was my fault - I did most of the initial rewrite of
> the code, but haven't been paying it enough attention since then - so
> thanks for your reminder.
>
> Thanks - I am sure that will be useful.  At the moment I'm trying to
> recover from flu, and porting the scipy tests over to nose, an
> intriguing combination.  But it would be good to get onto this soon.
>
> Will anyone else have time to join in here?  Stefan?

Those are definitely higher priorities, so I'm willing to wait :)

The V5 write support is not especially urgent since V4 writing (the
default) seems to work.  The user would have to specify V5 in order to
produce the error.  V5 reading seems to work also.

--

-- 
Nathan Bell wnbell <at> gmail.com
Permalink | Reply | 0 comments |
headers
Stefan van der Walt | 3 Jan 01:33
Picon
Picon
Favicon

Re: matlab5 sparse IO

On Wed, Jan 02, 2008 at 03:58:58PM -0800, Matthew Brett wrote:
> Hi Nathan,
> 
> > I noticed that the Matlab4 sparse writer was a little slow, so I sped
> > it up using the coo_matrix format.  Anyway, I was going to do the same
> > for the Matlab5 writer, but it seems to be broken.  It appears that
> > the V5 code was a copy/paste of the V4 method, which it shouldn't be.
> > http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/io/matlab/mio5.py#L662
> 
> I'm sorry - this was my fault - I did most of the initial rewrite of
> the code, but haven't been paying it enough attention since then - so
> thanks for your reminder.
> 
> > I don't fully understand all the magic in the matlab IO code, but I'd
> > be happy to help whomever maintains it in adding sparse V5 support.
> 
> Thanks - I am sure that will be useful.  At the moment I'm trying to
> recover from flu, and porting the scipy tests over to nose, an
> intriguing combination.  But it would be good to get onto this soon.
> 
> Will anyone else have time to join in here?  Stefan?

Sure, I can take a look tomorrow morning.

To find the "more fundamental" issues Nathan referred to, I'll take a look at 

http://www.mathworks.com/access/helpdesk/help/pdf_doc/matlab/matfile_format.pdf

Please let me know if there are any other relevant docs.  I assume the
reader functions correctly, since the unit tests pass and I see
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew Brett | 3 Jan 01:54
Picon
Gravatar

Re: matlab5 sparse IO

Hi,

> Sure, I can take a look tomorrow morning.

Excellent - thanks very much.

> To find the "more fundamental" issues Nathan referred to, I'll take a look at
>http://www.mathworks.com/access/helpdesk/help/pdf_doc/matlab/matfile_format.pdf

That was my primary source.  I think the V5 writing was a patch kindly
provided - that I didn't check carefully enough.  I had only put in
the structure for it but didn't implement it myself.

> I assume the
> reader functions correctly, since the unit tests pass and I see

I believe it does - but it would be good hear from anyone who can't
read a matlab .mat file...

Thanks a lot,

Matthew
Permalink | Reply | 0 comments |

Gmane