headers
Tim Leslie | 3 Jan 08:06
Picon

Re: new function regrid for fitpack2

Hi All, I've been working through a bunch of tickets and noticed this
one has stagnated. Can someone comment on the status of this.

http://projects.scipy.org/scipy/scipy/ticket/286

The second patch to this ticket has not been applied? Is there a
reason not to? I noticed the other thread on this topic suggested that
a complete solution might require moving delaunay out of the sandbox.
Is this still the case?

Cheers,

Tim

On 10/14/06, Stefan van der Walt <stefan <at> sun.ac.za> wrote:
> Hi John
>
> On Fri, Oct 13, 2006 at 03:42:13PM +0100, John Travers wrote:
> > Attached is a very simple script (will make it a test later) which
> > uses the test data from netlib->dierckx to check the use fo regrid and
> > surfit. The plot attached shows the results. There could be an error
> > in my dealing with meshgrid (I hate they way it swaps axes), but I
> > think it is right. The surfit part issues a warning on interpolation.
> > If you increase s to say 20 (0 is needed for interpolation) then the
> > warning goes, but then you are smoothing (as can be seen from the
> > corresponding output plot - which was down sampled for file size).
>
> I think matplotlib may be throwing a spanner in the wheels here by
> using its own interpolation.  If you use
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Travers | 3 Jan 10:00
Picon

Re: new function regrid for fitpack2

On 03/01/07, Tim Leslie <tim.leslie <at> gmail.com> wrote:
> Hi All, I've been working through a bunch of tickets and noticed this
> one has stagnated. Can someone comment on the status of this.
>
> http://projects.scipy.org/scipy/scipy/ticket/286
>
> The second patch to this ticket has not been applied? Is there a
> reason not to? I noticed the other thread on this topic suggested that
> a complete solution might require moving delaunay out of the sandbox.
> Is this still the case?
>
> Cheers,
>
> Tim

Hi Tim, everybody,

I am (slowly) trying to work on improving the interp2d function as
well as spline fitting in general. The first patch attached to the
ticket you mention is applied and provides the RectBivariateSpline
class for fitting a spline to rectangular gridded data. The second
patch changed interp2d to use this class rather than the firtpack
surfit function (which absolutely should not be used for
interpolation). This was not applied as it was decided that interp2d
really must support non-uniform grid data. The only solution to this
problem (surft still needs replacing) proposed to date is to use
Rokert Kern's delaunay package from the sandbox. In order to achieve
this I proposed that the spline *fitting* code be taken out of
scipy.interpolate and put into scipy.spline. And that
scipy.interpolate should import methods from both the spline and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Travis Oliphant | 3 Jan 23:09
Favicon

Re: sparsetools - new and (hopefully) improved!

Nathan Bell wrote:

>I've rewritten sparse/sparsetools to speed up some of the slower bits
>in current code.  The previous implementation of CSR/CSC matrix
>addition, multiplication, and conversions were all very slow, often
>orders of magnitude slower than MATLAB or PySparse.
>
>  
>
Very nice.  Thank your for your help on these algorithms. 

>In the new implementation:
>- CSR<->CSC conversion is cheap (linear time)
>- sparse addition is fast (linear time)
>- sparse multiplication is fast (noticeably faster than MATLAB in my testing)
>- CSR column indices do not need to be sorted (same for CSC row indices)
>- the results of all the above operations contain no explicit zeros
>- COO->CSR and COO->CSC is linear time and sums duplicate entries
>
>
>This last point is useful for constructing stiffness/mass matrices.
>Matrix multiplication is essentially optimal (modulo Strassen-like
>algorithms) and is based on the SMMP algorithm I mentioned a while
>ago.
>  
>
Excellent.  Thank you.

>I implemented the functions in C++ with SWIG bindings. 
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nathan Bell | 4 Jan 00:51
Picon
Gravatar

Re: sparsetools - new and (hopefully) improved!

On 1/3/07, Travis Oliphant <oliphant <at> ee.byu.edu> wrote:
> How are you coming on getting access to the SVN repository?  I might
> also be able to give you access.  I looked over the code and could not
> find where the multiplication was actually being done (I got lost in the
> interface).  Does the tar file really contain all of your code?

I now have access to SVN (thanks Jeff and Robert).

All of the algorithms are in sparse/sparsetools/sparsetools.h of the
archive.  csrmucsr() is the function that handles matrix
multiplication.

Also on the web here:
http://graphics.cs.uiuc.edu/~wnbell/sparse/sparse/sparsetools/sparsetools.h

Unless someone has an objection, I plan to commit the changes in a
week or so (once I've written a more comprehensive set of unittests).

--

-- 
Nathan Bell wnbell <at> gmail.com
Permalink | Reply | 1 comment |
headers
Robert Cimrman | 4 Jan 12:55
Picon

Re: sparsetools - new and (hopefully) improved!

Nathan Bell wrote:
> I've rewritten sparse/sparsetools to speed up some of the slower bits
> in current code.  The previous implementation of CSR/CSC matrix
> addition, multiplication, and conversions were all very slow, often
> orders of magnitude slower than MATLAB or PySparse.
> 
> In the new implementation:
> - CSR<->CSC conversion is cheap (linear time)
> - sparse addition is fast (linear time)
> - sparse multiplication is fast (noticeably faster than MATLAB in my testing)
> - CSR column indices do not need to be sorted (same for CSC row indices)
> - the results of all the above operations contain no explicit zeros
> - COO->CSR and COO->CSC is linear time and sums duplicate entries
> 
> 
> This last point is useful for constructing stiffness/mass matrices.
> Matrix multiplication is essentially optimal (modulo Strassen-like
> algorithms) and is based on the SMMP algorithm I mentioned a while
> ago.

Hi Nathan, I have not had time to look at your code yet (just returned 
from holidays) but the description looks great!

One umfpack-related note - the solver requires the CSC/CSR column/row 
indices sorted in ascending order. Does your implementation contain a 
function to ensure_sorted_indices()?

r.
Permalink | Reply | 20 comments |
headers
Nathan Bell | 5 Jan 01:05
Picon
Gravatar

Re: sparsetools - new and (hopefully) improved!

On 1/4/07, Robert Cimrman <cimrman3 <at> ntc.zcu.cz> wrote:
> Hi Nathan, I have not had time to look at your code yet (just returned
> from holidays) but the description looks great!
>
> One umfpack-related note - the solver requires the CSC/CSR column/row
> indices sorted in ascending order. Does your implementation contain a
> function to ensure_sorted_indices()?

Not currently, but it would be trivial to add.  Converting from
CSR<->CSC (a linear time operation) has the side effect of sorting the
column/row indices.  Two conversions (CSR->CSC->CSR) would produce the
desired result in the original format.

I will add ensure_sorted_indices() to csr_matrix and csc_matrix.

--

-- 
Nathan Bell wnbell <at> gmail.com
Permalink | Reply | 19 comments |
headers
Nils Wagner | 5 Jan 09:51
Picon
Favicon

undefined symbol: atl_f77wrap_izamax__

Hi,

My recent findings concerning the installation problems
on openSUSE 10.2 are listed below.

I have added two symbolic links (Thanks to Andreas Hanke)

ln -s /lib64/libgcc_s.so.1 /usr/lib64/libgcc_s.so
ln -s /lib/libgcc_s.so.1 /usr/lib/libgcc_s.so

I was able to install numpy.
But if I import numpy I get

>>> import numpy
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/__init__.py", 
line 40, in <module>
     import linalg
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/linalg/__init__.py", 
line 4, in <module>
     from linalg import *
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/linalg/linalg.py", 
line 25, in <module>
     from numpy.linalg import lapack_lite
ImportError: 
/usr/local/lib64/python2.5/site-packages/numpy/linalg/lapack_lite.so:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nils Wagner | 5 Jan 10:41
Picon
Favicon

*** glibc detected *** /usr/bin/python: double free or corruption (!prev): 0x0000000002263320 ***

Hi,

Oops, I forgot to remove the build directory in numpy.
Sorry for the noise !
Finally I was able to install numpy and scipy !

Now

scipy.test() freezes with

Resizing... 20 7 35
Resizing... 23 7 47
Resizing... 24 25 58
Resizing... 28 7 68
Resizing... 28 27 73
.....Use minimum degree ordering on A'+A.
.................Resizing... 16 17 24
Resizing... 20 7 35
Resizing... 23 7 47
Resizing... 24 25 58
Resizing... 28 7 68
Resizing... 28 27 73
.....Use minimum degree ordering on
A'+A.
....................................../usr/local/lib64/python2.5/site-packages/scipy/interpolate/fitpack2.py:457: 
UserWarning:
The coefficients of the spline returned have been computed 
as the
minimal norm least-squares solution of a (numerically) 
rank deficient
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Kern | 5 Jan 10:48
Picon
Gravatar

Re: *** glibc detected *** /usr/bin/python: double free or corruption (!prev): 0x0000000002263320 ***

Nils Wagner wrote:

> Can someone reproduce this ?

Not on my MacBook, no.

> Should I file a bug report ?

Yes, when you locate the function that is giving that error. Use scipy.test(1,10) .

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
Permalink | Reply | 0 comments |
headers
Robert Cimrman | 5 Jan 11:44
Picon

Re: sparsetools - new and (hopefully) improved!

Nathan Bell wrote:
> On 1/4/07, Robert Cimrman <cimrman3 <at> ntc.zcu.cz> wrote:
>> Hi Nathan, I have not had time to look at your code yet (just returned
>> from holidays) but the description looks great!
>>
>> One umfpack-related note - the solver requires the CSC/CSR column/row
>> indices sorted in ascending order. Does your implementation contain a
>> function to ensure_sorted_indices()?
> 
> Not currently, but it would be trivial to add.  Converting from
> CSR<->CSC (a linear time operation) has the side effect of sorting the
> column/row indices.  Two conversions (CSR->CSC->CSR) would produce the
> desired result in the original format.
> 
> I will add ensure_sorted_indices() to csr_matrix and csc_matrix.

Good! Going CSR->CSC->CSR would be too inefficient, IMHO. Maybe we could 
add a flag to the CSR/CSC matrix class saying that it has sorted indices 
to make the check trivial. It should be added as keyword argument to the 
matrix constructor, too.

r.
Permalink | Reply | 18 comments |

Gmane