headers
Nathan Bell | 1 Feb 05:16
Picon
Gravatar

Re: sparse revisited

On 1/30/07, Nils Wagner <nwagner <at> iam.uni-stuttgart.de> wrote:
> I have applied the patch by mauger for ticket #311.
> It works fine. I mean our tests passed. Please can you
> apply the patch to svn.

The patch resolved my problems as well.  I've committed the changes to
svn and closed the ticket:
http://projects.scipy.org/scipy/scipy/ticket/311

--

-- 
Nathan Bell wnbell <at> gmail.com
Permalink | Reply | 0 comments |
headers
Jeff Strunk | 2 Feb 17:59

Site problems this morning

Good morning,

The problems this morning were from a DoS attack on Moin. The attacker crawled 
the site for long loading pages and then repeatedly accessed them.

I blocked the IP and disabled the pages that the attacker was using 
most(KlasseKlasse and PageHits).

I think a long term solution would be caching. The next version of Moin has 
more caching support.

Thanks,
Jeff
Permalink | Reply | 0 comments |
headers
Zachary Pincus | 6 Feb 04:20
Picon
Favicon

scipy.interpolate.fitpack patch

Hello folks,

I found a minor bug in some of the routines in  
scipy.interpolate.fitpack that deal with parametric splines.

In the case of a parametric spline, the spline coefficients c (in the  
'tck' tuple) are not simply a 1D array of coefficients as they are  
for nonparametric splines. Instead, 'c' is a list of n different 1D  
arrays, where n is the dimension of the space in which the spline  
lives. To evaluate a parametric spline (or integrate it, or insert  
points into it, or whatnot), one simply performs the operation n  
times on the n different arrays that comprise c.

The general method for dealing with this in fitpack.py is:
try:
   c[0][0]
   <recurse on each element of c, collate the results, and return them>
except: pass
<process the 1D c parameter, returning something or raising a helpful  
exception>

 From this it should be clear what the problem is: if the spline is  
parametric, and if one of the elements of the 'c' list causes an  
exception to be raised, it will be silently swallowed by the 'except:  
pass', and then the function will try to process c as a 1D array  
(which it is not!), causing a very uninformative exception to be raised.

Attached is a patch that makes the functions look like this instead:
try:
   c[0][0]
(Continue reading)

Permalink | Reply | 14 comments |
headers
John Travers | 6 Feb 12:14
Picon

Re: scipy.interpolate.fitpack patch

On 06/02/07, Zachary Pincus <zpincus <at> stanford.edu> wrote:
> Hello folks,
>
> I found a minor bug in some of the routines in
> scipy.interpolate.fitpack that deal with parametric splines.
> ...
> Thanks,
>
> Zach Pincus

Hi Zach,

The bug you mentioned has already been fixed in a new development
version of fitpack which is currently in the sandbox under the spline
package.
I'm currently trying to move fitpack.py to depend purely on f2py
generated interfaces. I have also added a number of unit tests to find
other bugs. In addition a number of other enhancements have been made.
Check the README file in the package directory for details.

My plan is for this to eventually be moved into scipy as a package
separate from interpolate (as interpolation is only one part of its
functionality), possibly as a top level spline package, or as a
sub-package under an approximation package. (Note that this plan
hasn't been fully agreed upon on this list yet).

I would very much appreciate if your enhancements (which are really
welcome!), would be made against this new package, rather than the old
one currently in interpolate.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Stefan van der Walt | 6 Feb 12:35
Picon
Picon
Favicon

Re: scipy.interpolate.fitpack patch

On Tue, Feb 06, 2007 at 11:14:22AM +0000, John Travers wrote:
> On 06/02/07, Zachary Pincus <zpincus <at> stanford.edu> wrote:
> > Hello folks,
> >
> > I found a minor bug in some of the routines in
> > scipy.interpolate.fitpack that deal with parametric splines.
> > ...
> > Thanks,
> >
> > Zach Pincus
> 
> Hi Zach,
> 
> The bug you mentioned has already been fixed in a new development
> version of fitpack which is currently in the sandbox under the spline
> package.
> I'm currently trying to move fitpack.py to depend purely on f2py
> generated interfaces. I have also added a number of unit tests to find
> other bugs. In addition a number of other enhancements have been made.
> Check the README file in the package directory for details.

We should at least maintain the version in main scipy until it can be
replaced with the one in sandbox.  Alternatively, since it seems the
version in scipy-main is broken anyway (?), replace it and just make
sure the code remains in a usable condition.

Cheers
Stéfan
Permalink | Reply | 12 comments |
headers
John Travers | 6 Feb 13:00
Picon

Re: scipy.interpolate.fitpack patch

On 06/02/07, Stefan van der Walt <stefan <at> sun.ac.za> wrote:
> On Tue, Feb 06, 2007 at 11:14:22AM +0000, John Travers wrote:
> > On 06/02/07, Zachary Pincus <zpincus <at> stanford.edu> wrote:
> > > Hello folks,
> > >
> > > I found a minor bug in some of the routines in
> > > scipy.interpolate.fitpack that deal with parametric splines.
> > > ...
> > > Thanks,
> > >
> > > Zach Pincus
> >
> > Hi Zach,
> >
> > The bug you mentioned has already been fixed in a new development
> > version of fitpack which is currently in the sandbox under the spline
> > package.
> > I'm currently trying to move fitpack.py to depend purely on f2py
> > generated interfaces. I have also added a number of unit tests to find
> > other bugs. In addition a number of other enhancements have been made.
> > Check the README file in the package directory for details.
>
> We should at least maintain the version in main scipy until it can be
> replaced with the one in sandbox.

Agreed - but this should be happening within the next week

> Alternatively, since it seems the
> version in scipy-main is broken anyway (?), replace it and just make
> sure the code remains in a usable condition.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Stefan van der Walt | 6 Feb 13:15
Picon
Picon
Favicon

Re: scipy.interpolate.fitpack patch

On Tue, Feb 06, 2007 at 12:00:23PM +0000, John Travers wrote:
> > We should at least maintain the version in main scipy until it can be
> > replaced with the one in sandbox.
> 
> Agreed - but this should be happening within the next week

That's good news!

> > Alternatively, since it seems the
> > version in scipy-main is broken anyway (?), replace it and just make
> > sure the code remains in a usable condition.
> 
> The version in main scipy is not really broken - I simply decided to
> clean it up as I was in the process of separating spline functions
> from interpolating functions. This ended up taking more time than I
> anticipated (or I had too little time) - but it is mostly done now and
> I think the new version is cleaner and easier to maintain.

Looking forward to it -- just let me know if you need a hand.  Thanks
again for all your effort.

Cheers
Stéfan
Permalink | Reply | 10 comments |
headers
Zachary Pincus | 6 Feb 17:12
Picon
Favicon

Re: scipy.interpolate.fitpack patch

I didn't realize the changeover to the new fitpack interface would be  
happening so soon! Thanks for the work, and I'll definitely start  
looking at the new version.

Zach

On Feb 6, 2007, at 4:15 AM, Stefan van der Walt wrote:

> On Tue, Feb 06, 2007 at 12:00:23PM +0000, John Travers wrote:
>>> We should at least maintain the version in main scipy until it  
>>> can be
>>> replaced with the one in sandbox.
>>
>> Agreed - but this should be happening within the next week
>
> That's good news!
>
>>> Alternatively, since it seems the
>>> version in scipy-main is broken anyway (?), replace it and just make
>>> sure the code remains in a usable condition.
>>
>> The version in main scipy is not really broken - I simply decided to
>> clean it up as I was in the process of separating spline functions
>> from interpolating functions. This ended up taking more time than I
>> anticipated (or I had too little time) - but it is mostly done now  
>> and
>> I think the new version is cleaner and easier to maintain.
>
> Looking forward to it -- just let me know if you need a hand.  Thanks
> again for all your effort.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Zachary Pincus | 7 Feb 03:33
Picon
Favicon

Fitpack, insert, and spline -> bezier conversion

Hello all,

I've been working with scipy.interpolate a lot lately (hence some of  
the noise on this list; sorry) to write some code to convert cubic  
parametric b-splines into bezier curves (for easy output to things  
like postscript or SVG).

With the FITPACK 'insert' routine wrapped, this is relatively easy  
once you figure out how, although there are a few gotchas. (Would  
such a bit of code be useful in the scipy fitpack library?)

In the course of writing these conversion functions, I came upon some  
subtle bugs in the original implementation of insert.f from netlib.  
(They have to do with how the range into which the knot will be  
inserted is chosen in corner cases that occur when converting  
periodic splines to bezier curves.) I've tried contacting Dr.  
Dierckx, but so far without luck.

What would be the best approach to making sure that at least scipy  
gets correct versions? Should I contact the netlib people? Should I  
send you guys my patch and further fork the codebase?

Thanks,

Zach
Permalink | Reply | 2 comments |
headers
Robert Kern | 7 Feb 04:06
Picon
Gravatar

Re: Fitpack, insert, and spline -> bezier conversion

Zachary Pincus wrote:
> Hello all,
> 
> I've been working with scipy.interpolate a lot lately (hence some of  
> the noise on this list; sorry) to write some code to convert cubic  
> parametric b-splines into bezier curves (for easy output to things  
> like postscript or SVG).
> 
> With the FITPACK 'insert' routine wrapped, this is relatively easy  
> once you figure out how, although there are a few gotchas. (Would  
> such a bit of code be useful in the scipy fitpack library?)

Yes, please!

> In the course of writing these conversion functions, I came upon some  
> subtle bugs in the original implementation of insert.f from netlib.  
> (They have to do with how the range into which the knot will be  
> inserted is chosen in corner cases that occur when converting  
> periodic splines to bezier curves.) I've tried contacting Dr.  
> Dierckx, but so far without luck.
> 
> What would be the best approach to making sure that at least scipy  
> gets correct versions? Should I contact the netlib people?

They're probably not in a position to accept updates from anyone but the authors
themselves, but you can try.

> Should I  
> send you guys my patch and further fork the codebase?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane