From jstrunk at enthought.com  Fri Feb  2 11:59:13 2007
From: jstrunk at enthought.com (Jeff Strunk)
Date: Fri, 2 Feb 2007 10:59:13 -0600
Subject: [SciPy-dev] Site problems this morning
Message-ID: <200702021059.13218.jstrunk@enthought.com>

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


From zpincus at stanford.edu  Mon Feb  5 22:20:16 2007
From: zpincus at stanford.edu (Zachary Pincus)
Date: Mon, 5 Feb 2007 19:20:16 -0800
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
Message-ID: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>

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]
   parametric = True
except:
   parametric = False
if parametric:
   <recurse on each element of c, collate the results, and return them>
else:
   <process the 1D c parameter, returning something or raising a  
helpful exception>


Thanks,

Zach Pincus

Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fitpack.patch
Type: application/octet-stream
Size: 4976 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070205/2a684700/attachment.obj>

From jtravs at gmail.com  Tue Feb  6 06:14:22 2007
From: jtravs at gmail.com (John Travers)
Date: Tue, 6 Feb 2007 11:14:22 +0000
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
Message-ID: <3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>

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.

(BTW, parametric curve fitting isn't currently working fully yet in
the new package).

Best regards,
John


From stefan at sun.ac.za  Tue Feb  6 06:35:35 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Tue, 6 Feb 2007 13:35:35 +0200
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
Message-ID: <20070206113535.GJ6274@mentat.za.net>

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


From jtravs at gmail.com  Tue Feb  6 07:00:23 2007
From: jtravs at gmail.com (John Travers)
Date: Tue, 6 Feb 2007 12:00:23 +0000
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <20070206113535.GJ6274@mentat.za.net>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
	<20070206113535.GJ6274@mentat.za.net>
Message-ID: <3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>

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.

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.

It will be ready for inclusion in main as soon as I've found the bug
in the parametric spline. All tests for the previous fitpack pass
correctly for the new version, in addition to several new tests. But
there are currently no tests for parametric curves. I'm currently
using the cookbook example: (bottom of page on interpolation) - which
doesn't work yet. It shouldn't be hard to fix, but my time is still
limited - I plan to do it later this week.

Best regards,
John


From stefan at sun.ac.za  Tue Feb  6 07:15:57 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Tue, 6 Feb 2007 14:15:57 +0200
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
	<20070206113535.GJ6274@mentat.za.net>
	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>
Message-ID: <20070206121557.GK6274@mentat.za.net>

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


From zpincus at stanford.edu  Tue Feb  6 11:12:09 2007
From: zpincus at stanford.edu (Zachary Pincus)
Date: Tue, 6 Feb 2007 08:12:09 -0800
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <20070206121557.GK6274@mentat.za.net>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
	<20070206113535.GJ6274@mentat.za.net>
	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>
	<20070206121557.GK6274@mentat.za.net>
Message-ID: <87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>

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.
>
> Cheers
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev



From zpincus at stanford.edu  Tue Feb  6 21:33:46 2007
From: zpincus at stanford.edu (Zachary Pincus)
Date: Tue, 6 Feb 2007 18:33:46 -0800
Subject: [SciPy-dev] Fitpack, insert, and spline -> bezier conversion
Message-ID: <77599931-AF69-42E3-9182-98BFAAF7899F@stanford.edu>

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


From robert.kern at gmail.com  Tue Feb  6 22:06:46 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 06 Feb 2007 21:06:46 -0600
Subject: [SciPy-dev] Fitpack, insert, and spline -> bezier conversion
In-Reply-To: <77599931-AF69-42E3-9182-98BFAAF7899F@stanford.edu>
References: <77599931-AF69-42E3-9182-98BFAAF7899F@stanford.edu>
Message-ID: <45C94246.3090500@gmail.com>

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?

That seems like the best thing to do.

-- 
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


From zpincus at stanford.edu  Wed Feb  7 04:22:41 2007
From: zpincus at stanford.edu (Zachary Pincus)
Date: Wed, 7 Feb 2007 01:22:41 -0800
Subject: [SciPy-dev] Fitpack, insert, and spline -> bezier conversion
In-Reply-To: <45C94246.3090500@gmail.com>
References: <77599931-AF69-42E3-9182-98BFAAF7899F@stanford.edu>
	<45C94246.3090500@gmail.com>
Message-ID: <47DDB944-DC2C-4CE2-8A74-6427F4488BE7@stanford.edu>

Hello all,

My b-spline to bezier function and patch to insert.f are both attached.

Here's an example (using Gnuplot.py):

import numpy
from scipy.interpolate import splprep,splev

u = numpy.linspace(0, 2*numpy.pi, 100, True)
x = numpy.cos(u)
y = numpy.sin(u)
circle, uout = splprep([x,y],u=u,s=0.001,per=True)
circle_plot = Gnuplot.Data(numpy.transpose(splev 
(uout,circle)),with='lines')
circle_control = Gnuplot.Data(numpy.transpose(circle[1]),with='points')
bezier_control = [Gnuplot.Data(b,with='points') for b in
   b_spline_to_bezier_series(circle,per=True)]
g = Gnuplot.Gnuplot()
g.plot(circle_plot, circle_control)
g.plot(circle_plot, *bezier_control)

sin, uout = splprep([u,y],u=u,s=0.001,per=False)
sin_plot = Gnuplot.Data(numpy.transpose(splev(uout,sin)),with='lines')
sin_control = Gnuplot.Data(numpy.transpose(sin[1]),with='points')
bezier_control = [Gnuplot.Data(b,with='points') for b in
   b_spline_to_bezier_series(sin,per=False)]
g = Gnuplot.Gnuplot()
g.plot(sin_plot, sin_control)
g.plot(sin_plot, *bezier_control)


Thanks,

Zach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: b_spline_to_bezier_series.py
Type: text/x-python-script
Size: 2321 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070207/8256ee58/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: insert.patch
Type: application/octet-stream
Size: 1408 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070207/8256ee58/attachment.obj>
-------------- next part --------------



On Feb 6, 2007, at 7:06 PM, Robert Kern wrote:

> 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?
>
> That seems like the best thing to do.
>
> -- 
> 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
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev


From jtravs at gmail.com  Wed Feb  7 09:38:34 2007
From: jtravs at gmail.com (John Travers)
Date: Wed, 7 Feb 2007 14:38:34 +0000
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
	<20070206113535.GJ6274@mentat.za.net>
	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>
	<20070206121557.GK6274@mentat.za.net>
	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>
Message-ID: <3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>

Hi all,

I have just committed a fix for the problem with the parametric spline fitting.
So as far as I can tell the new spline module is ready for prime time.
So I would be very grateful if people can test it!!

All you need to do is enable the spline module in the sandbox and
replace any imports from scipy.interpolate with scipy.sandbox.spline.

Bugs are very welcome!

Note this module is missing the insert method added recently (thanks
to Zach) - should be fixed soon.

Now I can finally pay attention to the interpolation methods. I have a
new module ready based on radial basis functions that allows n-d
interpolation of scattered data. I'll be committing it this week once
I've ironed out a few bugs.

John


From nwagner at iam.uni-stuttgart.de  Wed Feb  7 10:34:55 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 07 Feb 2007 16:34:55 +0100
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>	<20070206113535.GJ6274@mentat.za.net>	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>	<20070206121557.GK6274@mentat.za.net>	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>
	<3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>
Message-ID: <45C9F19F.2090602@iam.uni-stuttgart.de>

John Travers wrote:
> Hi all,
>
> I have just committed a fix for the problem with the parametric spline fitting.
> So as far as I can tell the new spline module is ready for prime time.
> So I would be very grateful if people can test it!!
>
> All you need to do is enable the spline module in the sandbox and
> replace any imports from scipy.interpolate with scipy.sandbox.spline.
>
> Bugs are very welcome!
>
> Note this module is missing the insert method added recently (thanks
> to Zach) - should be fixed soon.
>
> Now I can finally pay attention to the interpolation methods. I have a
> new module ready based on radial basis functions that allows n-d
> interpolation of scattered data. I'll be committing it this week once
> I've ironed out a few bugs.
>
> John
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   

Hi John,

I enabled the spline module.
Here is the output of

python -i
/usr/lib64/python2.4/site-packages/scipy/sandbox/spline/tests/test_spline.py

  Found 10 tests for __main__
/usr/lib64/python2.4/site-packages/scipy/sandbox/spline/spline.py:456:
UserWarning:
The coefficients of the spline returned have been computed as the
minimal norm least-squares solution of a (numerically) rank deficient
system (deficiency=7). If deficiency is large, the results may be
inaccurate. Deficiency may strongly depend on the value of eps.
  warnings.warn(message)
.........F
======================================================================
FAIL: check_sproot (__main__.test_UnivariateSpline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib64/python2.4/site-packages/scipy/sandbox/spline/tests/test_spline.py",
line 104, in check_sproot
    assert_array_almost_equal(uspl.roots(),ex, decimal=3)
  File "/usr/lib64/python2.4/site-packages/numpy/testing/utils.py", line
230, in assert_array_almost_equal
    header='Arrays are not almost equal')
  File "/usr/lib64/python2.4/site-packages/numpy/testing/utils.py", line
199, in assert_array_compare
    assert cond, msg
AssertionError:
Arrays are not almost equal

(shapes (4,), (5,) mismatch)
 x: array([  3.14181593,   6.28332425,   9.42469672,  12.56632768])
 y: array([  0.        ,   3.14159265,   6.28318531,   9.42477796, 
12.56637061])

----------------------------------------------------------------------
Ran 10 tests in 0.028s

FAILED (failures=1)

Nils



From nwagner at iam.uni-stuttgart.de  Wed Feb  7 11:02:39 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 07 Feb 2007 17:02:39 +0100
Subject: [SciPy-dev] ARPACK
Message-ID: <45C9F81F.2000303@iam.uni-stuttgart.de>

Hi,

Is there a chance that ARPACK can be moved into main scipy ?
 
Nils



From ggellner at uoguelph.ca  Wed Feb  7 11:27:42 2007
From: ggellner at uoguelph.ca (Gabriel Gellner)
Date: Wed, 7 Feb 2007 11:27:42 -0500
Subject: [SciPy-dev] Random Normal with zero sdev?
In-Reply-To: <45C9F81F.2000303@iam.uni-stuttgart.de>
References: <45C9F81F.2000303@iam.uni-stuttgart.de>
Message-ID: <20070207162742.GA21903@angus>

Is there any reason that numpy.random.normal raises an exception for
stdev=0?

In R it simply returns the mean, which seems a useful 'degenerate' case
to me. (also if you use the mean + sqrt(stdev)*randn() idiom for
matlab, it also has the nice degenerate case . . .)

Just wanted to see if this was a bug, or a feature . . . (if a
feature, I will simply make a wrapper for myself).

Gabriel


From zpincus at stanford.edu  Wed Feb  7 16:22:49 2007
From: zpincus at stanford.edu (Zachary Pincus)
Date: Wed, 7 Feb 2007 13:22:49 -0800
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
	<20070206113535.GJ6274@mentat.za.net>
	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>
	<20070206121557.GK6274@mentat.za.net>
	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>
	<3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>
Message-ID: <585893A4-128D-493A-968A-1EAF92C71535@stanford.edu>

Hello,

The fitpack.py module in the sandbox/spline directory still contains  
some bugs relating to the patch that I submitted recently. I know  
that the 'spline' classes are the future, but I think that for some  
uses the fitpack functions will remain the best interface, so we  
should keep them up as best as possible.

Anyhow, the bug I mentioned (silently swallowing errors while trying  
to determine whether the c parameter in tck is a list-of-numbers or a  
list-of-arrays) remains in the new version of fitpack.py in a  
slightly different form. The problematic stanzas now look like:

try:
   c[0][0]
   <recurse on each element of c, collate the results, and return them>
except TypeError: pass
<process the 1D c parameter, returning something or raising a TypeError>

which as you can see still remains a bug, because if TypeError is  
raised in the recursive call, it will be silently swallowed, and c  
will be assumed to be 1D.

The patch that I sent out earlier (though targeted at interpolate/ 
fitpack.py instead of sandbox/spline/fitpack.py) contains a less- 
brittle fix that changes these stanzas to:

try:
   c[0][0]
   parametric = True
except:
   parametric = False
if parametric:
   <recurse on each element of c, collate the results, and return them>
else:
   <process the 1D c parameter, returning something or raising a  
helpful exception>

Should I re-send a similar patch for sandbox/spline/fitpack.py?

Thanks,

Zach




On Feb 7, 2007, at 6:38 AM, John Travers wrote:

> Hi all,
>
> I have just committed a fix for the problem with the parametric  
> spline fitting.
> So as far as I can tell the new spline module is ready for prime time.
> So I would be very grateful if people can test it!!
>
> All you need to do is enable the spline module in the sandbox and
> replace any imports from scipy.interpolate with scipy.sandbox.spline.
>
> Bugs are very welcome!
>
> Note this module is missing the insert method added recently (thanks
> to Zach) - should be fixed soon.
>
> Now I can finally pay attention to the interpolation methods. I have a
> new module ready based on radial basis functions that allows n-d
> interpolation of scattered data. I'll be committing it this week once
> I've ironed out a few bugs.
>
> John
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev



From jtravs at gmail.com  Thu Feb  8 05:24:17 2007
From: jtravs at gmail.com (John Travers)
Date: Thu, 8 Feb 2007 10:24:17 +0000
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <585893A4-128D-493A-968A-1EAF92C71535@stanford.edu>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
	<20070206113535.GJ6274@mentat.za.net>
	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>
	<20070206121557.GK6274@mentat.za.net>
	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>
	<3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>
	<585893A4-128D-493A-968A-1EAF92C71535@stanford.edu>
Message-ID: <3a1077e70702080224h69589d6eoed3e29fd07614626@mail.gmail.com>

On 07/02/07, Zachary Pincus <zpincus at stanford.edu> wrote:
> Hello,
>
> The fitpack.py module in the sandbox/spline directory still contains
> some bugs relating to the patch that I submitted recently. I know
> that the 'spline' classes are the future, but I think that for some
> uses the fitpack functions will remain the best interface, so we
> should keep them up as best as possible.
>
> Anyhow, the bug I mentioned (silently swallowing errors while trying
> to determine whether the c parameter in tck is a list-of-numbers or a
> list-of-arrays) remains in the new version of fitpack.py in a
> slightly different form. The problematic stanzas now look like:
>
> try:
>    c[0][0]
>    <recurse on each element of c, collate the results, and return them>
> except TypeError: pass
> <process the 1D c parameter, returning something or raising a TypeError>
>
> which as you can see still remains a bug, because if TypeError is
> raised in the recursive call, it will be silently swallowed, and c
> will be assumed to be 1D.
>
> The patch that I sent out earlier (though targeted at interpolate/
> fitpack.py instead of sandbox/spline/fitpack.py) contains a less-
> brittle fix that changes these stanzas to:
>
> try:
>    c[0][0]
>    parametric = True
> except:
>    parametric = False
> if parametric:
>    <recurse on each element of c, collate the results, and return them>
> else:
>    <process the 1D c parameter, returning something or raising a
> helpful exception>
>
> Should I re-send a similar patch for sandbox/spline/fitpack.py?
>
> Thanks,
>
> Zach

Yes you are right. I will add your patch to the new fitpack - there
are only minor differences.
John


From jtravs at gmail.com  Thu Feb  8 05:41:45 2007
From: jtravs at gmail.com (John Travers)
Date: Thu, 8 Feb 2007 10:41:45 +0000
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <45C9F19F.2090602@iam.uni-stuttgart.de>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
	<20070206113535.GJ6274@mentat.za.net>
	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>
	<20070206121557.GK6274@mentat.za.net>
	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>
	<3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>
	<45C9F19F.2090602@iam.uni-stuttgart.de>
Message-ID: <3a1077e70702080241w4ff32acx89f1402cb8952396@mail.gmail.com>

On 07/02/07, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> John Travers wrote:
> > Hi all,
> >
> > Bugs are very welcome!
> >
...
> Arrays are not almost equal
>
> (shapes (4,), (5,) mismatch)
>  x: array([  3.14181593,   6.28332425,   9.42469672,  12.56632768])
>  y: array([  0.        ,   3.14159265,   6.28318531,   9.42477796,
> 12.56637061])

Hi Nils,
This seems strange to me. It is not finding the first root.Can you run

/usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py 3

and

/usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py 3

and post the output please.

Thanks!
John


From nwagner at iam.uni-stuttgart.de  Thu Feb  8 06:44:18 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 08 Feb 2007 12:44:18 +0100
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <3a1077e70702080241w4ff32acx89f1402cb8952396@mail.gmail.com>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>	<20070206113535.GJ6274@mentat.za.net>	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>	<20070206121557.GK6274@mentat.za.net>	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>	<3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>	<45C9F19F.2090602@iam.uni-stuttgart.de>
	<3a1077e70702080241w4ff32acx89f1402cb8952396@mail.gmail.com>
Message-ID: <45CB0D12.4000308@iam.uni-stuttgart.de>

John Travers wrote:
> On 07/02/07, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
>   
>> John Travers wrote:
>>     
>>> Hi all,
>>>
>>> Bugs are very welcome!
>>>
>>>       
> ...
>   
>> Arrays are not almost equal
>>
>> (shapes (4,), (5,) mismatch)
>>  x: array([  3.14181593,   6.28332425,   9.42469672,  12.56632768])
>>  y: array([  0.        ,   3.14159265,   6.28318531,   9.42477796,
>> 12.56637061])
>>     
>
> Hi Nils,
> This seems strange to me. It is not finding the first root.Can you run
>
> /usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py 3
>
> and
>
> /usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py 3
>
> and post the output please.
>
> Thanks!
> John
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   
Sure.
python -i /usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py
******************************************
        Tests of splrep and splev
******************************************

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=9.9999999999999995e-07 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  8.1e-04 7.3e-02
 2 :  2.3e-05 3.3e-04 2.3e-01
 3 :  7.1e-07 4.4e-05 2.4e-03 2.9e-01
 4 :  9.2e-07 1.1e-04 6.3e-03 1.3e-01 1.4e+00
 5 :  8.8e-07 6.9e-05 3.5e-03 7.0e-02 6.0e-01 2.4e+00

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  7.8e-04 7.3e-02
 2 :  1.5e-07 9.3e-04 1.6e-01
 3 :  2.3e-09 3.7e-06 4.3e-04 7.5e-02
 4 :  4.7e-11 1.4e-06 2.8e-04 1.5e-02 4.4e-01
 5 :  7.5e-13 2.8e-08 6.1e-06 3.9e-04 1.0e-02 1.7e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 Evaluation at knots
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  0.0e+00 2.5e-01
 2 :  1.9e-07 1.9e-03 3.6e-01
 3 :  2.0e-31 5.6e-06 1.4e-03 2.6e-01
 4 :  6.9e-11 2.7e-06 5.4e-04 3.0e-02 7.1e-01
 5 :  5.0e-31 5.4e-08 1.2e-05 7.7e-04 1.8e-02 3.5e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=1 s=0 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  7.8e-04 7.3e-02
 2 :  1.5e-07 9.3e-04 1.6e-01
 3 :  2.3e-09 3.7e-06 4.3e-04 7.5e-02
 4 :  4.7e-11 1.4e-06 2.8e-04 1.5e-02 4.4e-01
 5 :  7.5e-13 2.8e-08 6.1e-06 3.9e-04 1.0e-02 1.7e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=1 s=0 Evaluation at knots
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  0.0e+00 2.5e-01
 2 :  1.9e-07 1.9e-03 3.6e-01
 3 :  2.0e-31 5.6e-06 1.4e-03 2.6e-01
 4 :  6.9e-11 2.7e-06 5.4e-04 3.0e-02 7.1e-01
 5 :  5.0e-31 5.4e-08 1.2e-05 7.7e-04 1.8e-02 3.5e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 4.7119999999999997] > [0.0,
4.7119999999999997]
 per=0 s=0 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  2.4e-04 5.1e-02
 2 :  5.9e-08 5.8e-05 4.6e-02
 3 :  3.2e-10 5.6e-06 1.5e-03 1.2e-01
 4 :  1.8e-12 2.3e-08 6.2e-06 4.7e-04 8.3e-02
 5 :  3.7e-14 4.6e-09 1.9e-06 2.4e-04 1.3e-02 3.3e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
4.7119999999999997]
 per=1 s=0.10000000000000001 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  8.0e-02 1.4e+00
 2 :  9.4e-02 1.1e+00 4.8e+00
 3 :  6.4e-02 5.7e-01 3.8e+00 9.2e+00
 4 :  4.7e-03 1.2e-01 1.6e+00 7.4e+00 1.2e+01
 5 :  1.9e-04 4.3e-03 1.0e-01 1.1e+00 4.9e+00 9.9e+00
******************************************
        Tests of splint and spalde
******************************************

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 N=20 [a, b] = [0.0, 6.2830000000000004]  dx=0.628
 k :  int(s,[a,b]) Int.Error   Rel. error of s^(d)(dx) d = 0, .., k
 1    0.00000000   7.3e-17  0.0e+00  1.3e-01
 2    0.00000000   3.1e-17  2.2e-16  3.1e-03  1.7e-02
 3   -0.00000000   3.8e-18  2.2e-16  9.8e-05  1.1e-02  1.3e-01
 4    0.00000000   6.7e-16  2.2e-16  1.2e-04  8.9e-04  1.1e-02  1.3e-01
 5    0.00000000   1.1e-16  0.0e+00  1.4e-05  9.5e-05  1.1e-03  1.5e-02 
4.6e-02

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=1 s=0 N=20 [a, b] = [0.0, 6.2830000000000004]  dx=0.628
 k :  int(s,[a,b]) Int.Error   Rel. error of s^(d)(dx) d = 0, .., k
 1    0.00000000   7.3e-17  0.0e+00  1.3e-01
 2    0.00000000   3.1e-17  2.2e-16  3.1e-03  1.7e-02
 3   -0.00000000   3.8e-18  2.2e-16  9.8e-05  1.1e-02  1.3e-01
 4    0.00000000   6.7e-16  2.2e-16  1.2e-04  8.9e-04  1.1e-02  1.3e-01
 5    0.00000000   1.1e-16  0.0e+00  1.4e-05  9.5e-05  1.1e-03  1.5e-02 
4.6e-02

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 N=20 [a, b] = [0.628, 3.1419999999999999]  dx=0.628
 k :  int(s,[a,b]) Int.Error   Rel. error of s^(d)(dx) d = 0, .., k
 1    1.79411389   1.5e-02  0.0e+00  1.3e-01
 2    1.80893734   8.0e-05  2.2e-16  3.1e-03  1.7e-02
 3    1.80899266   2.4e-05  2.2e-16  9.8e-05  1.1e-02  1.3e-01
 4    1.80901586   1.1e-06  2.2e-16  1.2e-04  8.9e-04  1.1e-02  1.3e-01
 5    1.80901683   1.6e-07  0.0e+00  1.4e-05  9.5e-05  1.1e-03  1.5e-02 
4.6e-02

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 N=50 [a, b] = [0.628, 3.1419999999999999]  dx=0.628
 k :  int(s,[a,b]) Int.Error   Rel. error of s^(d)(dx) d = 0, .., k
 1    1.80663580   2.4e-03  0.0e+00  4.8e-02
 2    1.80901480   2.2e-06  2.2e-16  6.6e-04  6.3e-04
 3    1.80901636   6.3e-07  0.0e+00  1.5e-06  1.3e-03  4.7e-02
 4    1.80901699   1.2e-09  0.0e+00  1.6e-07  4.0e-06  6.0e-04  3.4e-03
 5    1.80901699   2.3e-10  0.0e+00  3.9e-09  4.4e-07  1.3e-06  1.4e-03 
4.8e-02
******************************************
        Tests of sproot
******************************************
  k  :     Roots of s(x) approx sin(x)  x in [0.0,15.0]:
  3  : [3.1418159268145143, 6.283324249558861, 9.4246967197029239,
12.566327676063914]
Note that if k is not 3, some roots are missed or incorrect
******************************************
        Tests of splprep, splrep, and splev
******************************************
 u = 0.628   N = 20
  k  :  [x(u), sin(x(u))]  Error of splprep  Error of splrep
  1  :  [3.867, -0.65600000000000003]    7.3e-03           7.3e-03
  2  :  [3.863, -0.66100000000000003]    2.4e-04           2.2e-04
  3  :  [3.863, -0.66100000000000003]    5.4e-05           1.4e-05
  4  :  [3.863, -0.66100000000000003]    7.9e-06           5.8e-07
  5  :  [3.863, -0.66100000000000003]    2.1e-05           2.8e-08
Derivatives of parametric cubic spline at u (first function):
 6.10627991049  11.9027895435  116.204926832
 u = 0.628   N = 50
  k  :  [x(u), sin(x(u))]  Error of splprep  Error of splrep
  1  :  [3.8650000000000002, -0.66100000000000003]    9.5e-04          
9.5e-04
  2  :  [3.8639999999999999, -0.66100000000000003]    2.3e-05          
1.1e-05
  3  :  [3.8639999999999999, -0.66100000000000003]    8.2e-07          
2.2e-07
  4  :  [3.8639999999999999, -0.66100000000000003]    1.5e-08          
4.4e-09
  5  :  [3.8639999999999999, -0.66100000000000003]    1.8e-09          
7.7e-11
Derivatives of parametric cubic spline at u (first function):
 6.11128630809  11.8744428128  111.000018594
******************************************
        Tests of bisplrep, bisplev
******************************************
5.77570681504e-06

----------------------------------------------------------------------------------------------------------------------------



python -i /usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py
******************************************
        Tests of splrep and splev
******************************************

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=9.9999999999999995e-07 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  8.1e-04 7.3e-02
 2 :  2.3e-05 3.3e-04 2.3e-01
 3 :  7.1e-07 4.4e-05 2.4e-03 2.9e-01
 4 :  9.2e-07 1.1e-04 6.3e-03 1.3e-01 1.4e+00
 5 :  8.8e-07 6.9e-05 3.5e-03 7.0e-02 6.0e-01 2.4e+00

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  7.8e-04 7.3e-02
 2 :  1.5e-07 9.3e-04 1.6e-01
 3 :  2.3e-09 3.7e-06 4.3e-04 7.5e-02
 4 :  4.7e-11 1.4e-06 2.8e-04 1.5e-02 4.4e-01
 5 :  7.5e-13 2.8e-08 6.1e-06 3.9e-04 1.0e-02 1.7e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 Evaluation at knots
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  0.0e+00 2.5e-01
 2 :  1.9e-07 1.9e-03 3.6e-01
 3 :  2.0e-31 5.6e-06 1.4e-03 2.6e-01
 4 :  6.9e-11 2.7e-06 5.4e-04 3.0e-02 7.1e-01
 5 :  5.0e-31 5.4e-08 1.2e-05 7.7e-04 1.8e-02 3.5e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=1 s=0 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  7.8e-04 7.3e-02
 2 :  1.5e-07 9.3e-04 1.6e-01
 3 :  2.2e-09 5.2e-07 4.4e-05 7.0e-02
 4 :  4.1e-12 2.4e-08 6.3e-07 7.6e-04 1.6e-01
 5 :  1.2e-14 3.7e-12 2.5e-10 5.1e-07 4.3e-05 7.0e-02

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=1 s=0 Evaluation at knots
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  6.3e-32 2.5e-01
 2 :  2.0e-06 1.9e-03 3.7e-01
 3 :  8.1e-31 3.3e-08 6.8e-04 2.5e-01
 4 :  1.4e-10 3.1e-08 1.3e-06 1.7e-03 3.6e-01
 5 :  5.9e-31 4.2e-13 1.9e-09 1.8e-08 6.8e-04 2.5e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 4.7119999999999997] > [0.0,
4.7119999999999997]
 per=0 s=0 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  2.4e-04 5.1e-02
 2 :  5.9e-08 5.8e-05 4.6e-02
 3 :  3.2e-10 5.6e-06 1.5e-03 1.2e-01
 4 :  1.8e-12 2.3e-08 6.2e-06 4.7e-04 8.3e-02
 5 :  3.7e-14 4.6e-09 1.9e-06 2.4e-04 1.3e-02 3.3e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
4.7119999999999997]
 per=1 s=0.10000000000000001 Evaluation at the middle of nodes
 k :  |f-s|^2  |f'-s'| |f''-.. |f'''-. |f''''- |f'''''
 1 :  9.8e-01 1.0e+01
 2 :  7.2e-01 1.3e+01 2.5e+02
 3 :  7.2e-01 9.3e+00 1.5e+02 5.9e+03
 4 :  7.1e-01 1.2e+01 1.1e+02 8.9e+03 1.5e+05
 5 :  6.8e-01 1.0e+01 1.0e+02 2.5e+03 2.8e+05 1.5e+07
******************************************
        Tests of splint and spalde
******************************************

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 N=20 [a, b] = [0.0, 6.2830000000000004]  dx=0.628
 k :  int(s,[a,b]) Int.Error   Rel. error of s^(d)(dx) d = 0, .., k
 1    0.00000000   7.3e-17  0.0e+00  1.3e-01
 2    0.00000000   3.1e-17  2.2e-16  3.1e-03  1.7e-02
 3   -0.00000000   3.8e-18  2.2e-16  9.8e-05  1.1e-02  1.3e-01
 4    0.00000000   6.7e-16  2.2e-16  1.2e-04  8.9e-04  1.1e-02  1.3e-01
 5    0.00000000   1.1e-16  0.0e+00  1.4e-05  9.5e-05  1.1e-03  1.5e-02 
4.6e-02

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=1 s=0 N=20 [a, b] = [0.0, 6.2830000000000004]  dx=0.628
 k :  int(s,[a,b]) Int.Error   Rel. error of s^(d)(dx) d = 0, .., k
 1    0.00000000   1.1e-16  0.0e+00  1.3e-01
 2   -0.00000000   4.3e-16  2.2e-16  3.1e-03  1.7e-02
 3   -0.00000000   2.9e-16  4.4e-16  5.5e-05  8.3e-03  1.2e-01
 4   -0.00000000   4.5e-16  4.4e-16  1.6e-05  2.7e-04  2.3e-03  3.9e-02
 5   -0.00000000   1.1e-16  0.0e+00  2.0e-07  1.4e-05  4.1e-05  8.3e-03 
1.2e-01

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 N=20 [a, b] = [0.628, 3.1419999999999999]  dx=0.628
 k :  int(s,[a,b]) Int.Error   Rel. error of s^(d)(dx) d = 0, .., k
 1    1.79411389   1.5e-02  0.0e+00  1.3e-01
 2    1.80893734   8.0e-05  2.2e-16  3.1e-03  1.7e-02
 3    1.80899266   2.4e-05  2.2e-16  9.8e-05  1.1e-02  1.3e-01
 4    1.80901586   1.1e-06  2.2e-16  1.2e-04  8.9e-04  1.1e-02  1.3e-01
 5    1.80901683   1.6e-07  0.0e+00  1.4e-05  9.5e-05  1.1e-03  1.5e-02 
4.6e-02

f = sin(x)  s=S_k(x;t,c)  x in [0.0, 6.2830000000000004] > [0.0,
6.2830000000000004]
 per=0 s=0 N=50 [a, b] = [0.628, 3.1419999999999999]  dx=0.628
 k :  int(s,[a,b]) Int.Error   Rel. error of s^(d)(dx) d = 0, .., k
 1    1.80663580   2.4e-03  0.0e+00  4.8e-02
 2    1.80901480   2.2e-06  2.2e-16  6.6e-04  6.3e-04
 3    1.80901636   6.3e-07  0.0e+00  1.5e-06  1.3e-03  4.7e-02
 4    1.80901699   1.2e-09  0.0e+00  1.6e-07  4.0e-06  6.0e-04  3.4e-03
 5    1.80901699   2.3e-10  0.0e+00  3.9e-09  4.4e-07  1.3e-06  1.4e-03 
4.8e-02
******************************************
        Tests of sproot
******************************************
  k  :     Roots of s(x) approx sin(x)  x in [0.0,15.0]:
  1  : [3.8917895437452752, 7.0333244206998957, 10.174697656280109,
13.316162856466082]
  2  : [3.5167921082175266, 6.6583244127250936, 9.7996976309412744,
12.948449169566704]
  3  : [3.1418159268145143, 6.283324249558861, 9.4246967197029239,
12.566327676063914]
  4  : [3.5377683941038813, 6.6583251439401883, 9.7996965906036593,
12.991740973097126]
  5  : [6.1161081418555904e-18, 4.0693671011759172, 7.0333276059930698,
10.174703377002832, 13.532636947291909]
Note that if k is not 3, some roots are missed or incorrect
******************************************
        Tests of splprep, splrep, and splev
******************************************
 u = 0.628   N = 20
  k  :  [x(u), sin(x(u))]  Error of splprep  Error of splrep
  1  :  [3.867, -0.65600000000000003]    7.3e-03           7.3e-03
  2  :  [3.863, -0.66100000000000003]    2.4e-04           2.2e-04
  3  :  [3.863, -0.66100000000000003]    5.4e-05           1.4e-05
  4  :  [3.863, -0.66100000000000003]    7.9e-06           5.8e-07
  5  :  [3.863, -0.66100000000000003]    2.1e-05           2.8e-08
Derivatives of parametric cubic spline at u (first function):
 6.10627991049  11.9027895435  116.204926832
 u = 0.628   N = 50
  k  :  [x(u), sin(x(u))]  Error of splprep  Error of splrep
  1  :  [3.8650000000000002, -0.66100000000000003]    9.5e-04          
9.5e-04
  2  :  [3.8639999999999999, -0.66100000000000003]    2.3e-05          
1.1e-05
  3  :  [3.8639999999999999, -0.66100000000000003]    8.2e-07          
2.2e-07
  4  :  [3.8639999999999999, -0.66100000000000003]    1.5e-08          
4.4e-09
  5  :  [3.8639999999999999, -0.66100000000000003]    1.8e-09          
7.7e-11
Derivatives of parametric cubic spline at u (first function):
 6.11128630809  11.8744428128  111.000018594
******************************************
        Tests of bisplrep, bisplev
******************************************
5.77570681504e-06


Nils



From jtravs at gmail.com  Thu Feb  8 07:16:56 2007
From: jtravs at gmail.com (John Travers)
Date: Thu, 8 Feb 2007 12:16:56 +0000
Subject: [SciPy-dev] New scattered data interpolation module
Message-ID: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>

Hi all,
I have just uploaded a new module to the sandbox called rbf.
It has a single class Rbf for scattered data interpolation in n-dimensions.
It uses radial basis functions for the interpolation. To be completely
honest I do
not fully understand how it works (though it looks straightforward).
The code is very closely based on some Matlab contributed code by Alex
Chirokov which can be found at:

http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=10056&objectType=FILE

No license was specified so I assumed public domain. Maybe this is
bad?! If so I'll
delete the module immediately.

It does, however, work very well. Some simple examples are shown at:

http://www.scipy.org/RadialBasisFunctions

I cannot attest to the accuracy or robustness of this code, I only
know that it has worked in a few cases. I would appreciate any
feedback about the code or the license issues.

Cheers,
John


From jtravs at gmail.com  Thu Feb  8 07:22:59 2007
From: jtravs at gmail.com (John Travers)
Date: Thu, 8 Feb 2007 12:22:59 +0000
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <45CB0D12.4000308@iam.uni-stuttgart.de>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>
	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>
	<20070206113535.GJ6274@mentat.za.net>
	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>
	<20070206121557.GK6274@mentat.za.net>
	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>
	<3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>
	<45C9F19F.2090602@iam.uni-stuttgart.de>
	<3a1077e70702080241w4ff32acx89f1402cb8952396@mail.gmail.com>
	<45CB0D12.4000308@iam.uni-stuttgart.de>
Message-ID: <3a1077e70702080422v186dc1dfs87dfcca0ab5c4f18@mail.gmail.com>

On 08/02/07, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> John Travers wrote:
> > Hi Nils,
> > This seems strange to me. It is not finding the first root.Can you run
> >
> > /usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py 3
> >
> > and
> >
> > /usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py 3
> >
> > and post the output please.
> >
...
> Sure.
> python -i /usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py

> ******************************************
>         Tests of sproot
> ******************************************
>   k  :     Roots of s(x) approx sin(x)  x in [0.0,15.0]:
>   3  : [3.1418159268145143, 6.283324249558861, 9.4246967197029239,
> 12.566327676063914]

> python -i /usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py

>   3  : [3.1418159268145143, 6.283324249558861, 9.4246967197029239,
> 12.566327676063914]

So the original fitpack doesn't find the first root either - strange
that this works on my machine, but not yours. Given that the other
roots look good I don't think there is a major problem. I think I'll
just modify the test to not complain if the first root is not found
for now.

Cheers,
John


From nwagner at iam.uni-stuttgart.de  Thu Feb  8 07:26:15 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 08 Feb 2007 13:26:15 +0100
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <3a1077e70702080422v186dc1dfs87dfcca0ab5c4f18@mail.gmail.com>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>	<20070206113535.GJ6274@mentat.za.net>	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>	<20070206121557.GK6274@mentat.za.net>	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>	<3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>	<45C9F19F.2090602@iam.uni-stuttgart.de>	<3a1077e70702080241w4ff32acx89f1402cb8952396@mail.gmail.com>	<45CB0D12.4000308@iam.uni-stuttgart.de>
	<3a1077e70702080422v186dc1dfs87dfcca0ab5c4f18@mail.gmail.com>
Message-ID: <45CB16E7.5070702@iam.uni-stuttgart.de>

John Travers wrote:
> On 08/02/07, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
>   
>> John Travers wrote:
>>     
>>> Hi Nils,
>>> This seems strange to me. It is not finding the first root.Can you run
>>>
>>> /usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py 3
>>>
>>> and
>>>
>>> /usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py 3
>>>
>>> and post the output please.
>>>
>>>       
> ...
>   
>> Sure.
>> python -i /usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py
>>     
>
>   
>> ******************************************
>>         Tests of sproot
>> ******************************************
>>   k  :     Roots of s(x) approx sin(x)  x in [0.0,15.0]:
>>   3  : [3.1418159268145143, 6.283324249558861, 9.4246967197029239,
>> 12.566327676063914]
>>     
>
>   
>> python -i /usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py
>>     
>
>   
>>   3  : [3.1418159268145143, 6.283324249558861, 9.4246967197029239,
>> 12.566327676063914]
>>     
>
> So the original fitpack doesn't find the first root either - strange
> that this works on my machine, but not yours. Given that the other
> roots look good I don't think there is a major problem. I think I'll
> just modify the test to not complain if the first root is not found
> for now.
>
> Cheers,
> John
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   
Maybe a 64-bit issue ???
uname -a
Linux lisa 2.6.13-15.13-default #1 Tue Nov 28 13:43:50 UTC 2006 x86_64
x86_64 x86_64 GNU/Linux

Nils

I can run the test on a 32-bit machine if needed.

Nils

 



From nwagner at iam.uni-stuttgart.de  Thu Feb  8 07:55:37 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 08 Feb 2007 13:55:37 +0100
Subject: [SciPy-dev] scipy.interpolate.fitpack patch
In-Reply-To: <45CB16E7.5070702@iam.uni-stuttgart.de>
References: <E817D0CA-BE5F-45AB-AAD7-E7F33114E09C@stanford.edu>	<3a1077e70702060314r8078b5di2f1e1a1da9bc7b4e@mail.gmail.com>	<20070206113535.GJ6274@mentat.za.net>	<3a1077e70702060400h278b3691wc4fd898a96f0067c@mail.gmail.com>	<20070206121557.GK6274@mentat.za.net>	<87C402A6-1616-41AA-90B9-EE9FF91C8AEF@stanford.edu>	<3a1077e70702070638i49c7f387rd65eeeffa5267197@mail.gmail.com>	<45C9F19F.2090602@iam.uni-stuttgart.de>	<3a1077e70702080241w4ff32acx89f1402cb8952396@mail.gmail.com>	<45CB0D12.4000308@iam.uni-stuttgart.de>	<3a1077e70702080422v186dc1dfs87dfcca0ab5c4f18@mail.gmail.com>
	<45CB16E7.5070702@iam.uni-stuttgart.de>
Message-ID: <45CB1DC9.6080408@iam.uni-stuttgart.de>

Nils Wagner wrote:
> John Travers wrote:
>   
>> On 08/02/07, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
>>   
>>     
>>> John Travers wrote:
>>>     
>>>       
>>>> Hi Nils,
>>>> This seems strange to me. It is not finding the first root.Can you run
>>>>
>>>> /usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py 3
>>>>
>>>> and
>>>>
>>>> /usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py 3
>>>>
>>>> and post the output please.
>>>>
>>>>       
>>>>         
>> ...
>>   
>>     
>>> Sure.
>>> python -i /usr/lib64/python2.4/site-packages/scipy/sandbox/spline/fitpack.py
>>>     
>>>       
>>   
>>     
>>> ******************************************
>>>         Tests of sproot
>>> ******************************************
>>>   k  :     Roots of s(x) approx sin(x)  x in [0.0,15.0]:
>>>   3  : [3.1418159268145143, 6.283324249558861, 9.4246967197029239,
>>> 12.566327676063914]
>>>     
>>>       
>>   
>>     
>>> python -i /usr/lib64/python2.4/site-packages/scipy/interpolate/fitpack.py
>>>     
>>>       
>>   
>>     
>>>   3  : [3.1418159268145143, 6.283324249558861, 9.4246967197029239,
>>> 12.566327676063914]
>>>     
>>>       
>> So the original fitpack doesn't find the first root either - strange
>> that this works on my machine, but not yours. Given that the other
>> roots look good I don't think there is a major problem. I think I'll
>> just modify the test to not complain if the first root is not found
>> for now.
>>
>> Cheers,
>> John
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>   
>>     
> Maybe a 64-bit issue ???
> uname -a
> Linux lisa 2.6.13-15.13-default #1 Tue Nov 28 13:43:50 UTC 2006 x86_64
> x86_64 x86_64 GNU/Linux
>
> Nils
>
> I can run the test on a 32-bit machine if needed.
>
> Nils
>
>  
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   
Hi John,

Here is the output of a 32-bit machine. Now the first root is detected !
Linux amanda 2.6.11.4-21.15-default #1 Tue Nov 28 13:39:58 UTC 2006 i686
athlon i386 GNU/Linux


python -i /usr/lib/python2.4/site-packages/scipy/interpolate/fitpack.py 3
******************************************
        Tests of sproot
******************************************
  k  :     Roots of s(x) approx sin(x)  x in [0.0,15.0]:
  1  : [3.8917895437452756, 7.0333244206998957, 10.174697656280109,
13.316162856466084]
  2  : [3.5167921082175266, 6.6583244127250936, 9.7996976309412744,
12.948449169566706]
  3  : [6.2076311686417224e-18, 3.1418159268145143, 6.283324249558861,
9.4246967197029239, 12.566327676063914]
  4  : [3.5377683941038813, 6.6583251439401883, 9.7996965906036593,
12.991740973097126]
  5  : [4.0693671011759172, 7.0333276059930698, 10.174703377002832,
13.532636947291909]
Note that if k is not 3, some roots are missed or incorrect
>>>
/home/nwagner> python -i
/usr/lib/python2.4/site-packages/scipy/sandbox/spline/fitpack.py 3
******************************************
        Tests of sproot
******************************************
  k  :     Roots of s(x) approx sin(x)  x in [0.0,15.0]:
  3  : [6.2076311686417224e-18, 3.1418159268145143, 6.283324249558861,
9.4246967197029239, 12.566327676063914]
Note that if k is not 3, some roots are missed or incorrect

Nils



From aisaac at american.edu  Thu Feb  8 09:28:24 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Thu, 8 Feb 2007 09:28:24 -0500
Subject: [SciPy-dev] New scattered data interpolation module
In-Reply-To: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
References: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
Message-ID: <Mahogany-0.67.0-984-20070208-092824.00@american.edu>

On Thu, 8 Feb 2007, John Travers apparently wrote:
> No license was specified so I assumed public domain. 

The author can be contacted at: Alex.Chirokov at gmail.com 

I suggest asking him whether the code is in the public 
domain and, if not, whether he is willing to release it 
under a liberal license such as BSD or MIT.  Make it clear 
you are not a business but wish to share the algorithm with 
others.

Cheers,
Alan Isaac






From jtravs at gmail.com  Thu Feb  8 10:28:49 2007
From: jtravs at gmail.com (John Travers)
Date: Thu, 8 Feb 2007 15:28:49 +0000
Subject: [SciPy-dev] New scattered data interpolation module
In-Reply-To: <Mahogany-0.67.0-984-20070208-092824.00@american.edu>
References: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
	<Mahogany-0.67.0-984-20070208-092824.00@american.edu>
Message-ID: <3a1077e70702080728w22cb4973ued2c3686d518429b@mail.gmail.com>

On 08/02/07, Alan G Isaac <aisaac at american.edu> wrote:
> On Thu, 8 Feb 2007, John Travers apparently wrote:
> > No license was specified so I assumed public domain.
>
> The author can be contacted at: Alex.Chirokov at gmail.com
>
> I suggest asking him whether the code is in the public
> domain and, if not, whether he is willing to release it
> under a liberal license such as BSD or MIT.  Make it clear
> you are not a business but wish to share the algorithm with
> others.
>

Yes, I should have done this sooner! All is well however, below is his response.
Cheers,
John

---------- Forwarded message ----------
From: Alexandre Chirokov <alex.chirokov at gmail.com>
Date: 08-Feb-2007 15:16
Subject: Re: radial basis function interpolation code
To: John Travers <jtravs at gmail.com>

> [snipped]
> SciPy is an open source project with a BSD style license which is free
> for both commercial and non-commercial use as long as they keep the
> copyright acknowledgement of the original author.
> [snipped]
> I just wish to clarify if the inclusion of this code, under these
> licence terms is OK with you. I would greatly appreciate your
> clarification on this issue.

Hi John,

Thank you very much for sending me this information. Releasing radial
base interpolation for  SciPy based on my matlab code is perfectly
fine with me.

Sincerely,
Alex Chirokov-


From robert.kern at gmail.com  Thu Feb  8 10:44:57 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 08 Feb 2007 09:44:57 -0600
Subject: [SciPy-dev] New scattered data interpolation module
In-Reply-To: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
References: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
Message-ID: <45CB4579.4040507@gmail.com>

John Travers wrote:

> No license was specified so I assumed public domain. Maybe this is
> bad?! 

Just for the record, the lack of a license does *not* mean that it is in the
public domain. It simply means that you have no license to redistribute it at
all. If you are unsure about whether a piece of code is legal for us to
redistribute, please do not check it in. It is extremely difficult to remove a
revision from the SVN history.

-- 
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


From jtravs at gmail.com  Thu Feb  8 10:57:28 2007
From: jtravs at gmail.com (John Travers)
Date: Thu, 8 Feb 2007 15:57:28 +0000
Subject: [SciPy-dev] New scattered data interpolation module
In-Reply-To: <45CB4579.4040507@gmail.com>
References: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
	<45CB4579.4040507@gmail.com>
Message-ID: <3a1077e70702080757t3868a9adubbbb874cf60160c0@mail.gmail.com>

On 08/02/07, Robert Kern <robert.kern at gmail.com> wrote:
> John Travers wrote:
>
> > No license was specified so I assumed public domain. Maybe this is
> > bad?!
>
> Just for the record, the lack of a license does *not* mean that it is in the
> public domain. It simply means that you have no license to redistribute it at
> all. If you are unsure about whether a piece of code is legal for us to
> redistribute, please do not check it in. It is extremely difficult to remove a
> revision from the SVN history.
>

Yes, point taken.
John


From zpincus at stanford.edu  Thu Feb  8 16:02:35 2007
From: zpincus at stanford.edu (Zachary Pincus)
Date: Thu, 8 Feb 2007 13:02:35 -0800
Subject: [SciPy-dev] New scattered data interpolation module
In-Reply-To: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
References: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
Message-ID: <37ECC25E-21CE-4156-83CB-54116D54EEFB@stanford.edu>

What's the relationship between the new RBF code and the Gaussian KDE  
classes in scipy.stats.kde? I think that they might be pretty similar  
-- perhaps similar enough to try to wrap up together.

Zach Pincus

Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine



On Feb 8, 2007, at 4:16 AM, John Travers wrote:

> Hi all,
> I have just uploaded a new module to the sandbox called rbf.
> It has a single class Rbf for scattered data interpolation in n- 
> dimensions.
> It uses radial basis functions for the interpolation. To be completely
> honest I do
> not fully understand how it works (though it looks straightforward).
> The code is very closely based on some Matlab contributed code by Alex
> Chirokov which can be found at:
>
> http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do? 
> objectId=10056&objectType=FILE
>
> No license was specified so I assumed public domain. Maybe this is
> bad?! If so I'll
> delete the module immediately.
>
> It does, however, work very well. Some simple examples are shown at:
>
> http://www.scipy.org/RadialBasisFunctions
>
> I cannot attest to the accuracy or robustness of this code, I only
> know that it has worked in a few cases. I would appreciate any
> feedback about the code or the license issues.
>
> Cheers,
> John
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev



From robert.kern at gmail.com  Thu Feb  8 17:30:44 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 08 Feb 2007 14:30:44 -0800
Subject: [SciPy-dev] New scattered data interpolation module
In-Reply-To: <37ECC25E-21CE-4156-83CB-54116D54EEFB@stanford.edu>
References: <3a1077e70702080416h5b7f7ab3r2e6bae27cdd98eac@mail.gmail.com>
	<37ECC25E-21CE-4156-83CB-54116D54EEFB@stanford.edu>
Message-ID: <45CBA494.6070501@gmail.com>

Zachary Pincus wrote:
> What's the relationship between the new RBF code and the Gaussian KDE  
> classes in scipy.stats.kde? I think that they might be pretty similar  
> -- perhaps similar enough to try to wrap up together.

They have some similar computations (evaluating N kernels each at the N points),
but they solve completely different problems.

-- 
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


From answer at tnoo.net  Sun Feb 11 16:12:20 2007
From: answer at tnoo.net (Martin =?iso-8859-1?Q?L=FCthi?=)
Date: Sun, 11 Feb 2007 22:12:20 +0100
Subject: [SciPy-dev] odeint changes argument y0
Message-ID: <87ejow4cwb.fsf@tnoo.net>

Hi

This bites me on Python 2.5 (never noticed it before)

scipy.integrate.odeint changes the argument y0. The fix would be to make a
copy in line 118, as is also done with the t argument.

I opened ticket #370 for this bug.

Best, tnoo

-- 
tnoo                 answer at tnoo.net



From cclarke at chrisdev.com  Mon Feb 12 14:28:41 2007
From: cclarke at chrisdev.com (Christopher Clarke)
Date: Mon, 12 Feb 2007 15:28:41 -0400
Subject: [SciPy-dev] timeseries tdates.py
Message-ID: <C8E965DE-6F78-44FC-9DD5-C8534D7DC246@chrisdev.com>

Hi
I noted that you guys want to remove the dependency on  mx.DateTime
Any idea of where this is heading???
I was thinking dateutil, rrule and relativedate my self
As i am actually working on something similar
Regards
Chris


From pgmdevlist at gmail.com  Mon Feb 12 14:41:57 2007
From: pgmdevlist at gmail.com (Pierre GM)
Date: Mon, 12 Feb 2007 14:41:57 -0500
Subject: [SciPy-dev] timeseries tdates.py
In-Reply-To: <C8E965DE-6F78-44FC-9DD5-C8534D7DC246@chrisdev.com>
References: <C8E965DE-6F78-44FC-9DD5-C8534D7DC246@chrisdev.com>
Message-ID: <200702121441.57108.pgmdevlist@gmail.com>

On Monday 12 February 2007 14:28:41 Christopher Clarke wrote:
> Hi
> I noted that you guys want to remove the dependency on  mx.DateTime
> Any idea of where this is heading???
> I was thinking dateutil, rrule and relativedate my self

Part of the code of the timeseries package that  deals with date manipulation 
is in C to speed things up. Dateutil is nothing but a reimplementation of 
mxDateTime in pure python (if I understand correctly), which is not what we 
want. For now, it's easier for Matt and I to use mxDateTime C objects 
directly, and getting rid of the Python layer.

There are some attempts to port tdates to C via Pyrex (at least the Dates 
part, not the DateArray yet), using datetime object as the base, but that's 
gonna have to wait for a couple of weeks. We need to make sure we're not 
crashing performances by too many calls to Python at the C level. (and I need 
to polish a couple of things w/ maskedarray & tseries).

> As i am actually working on something similar
You can use datetime objects w/ the SVN timeseries package anyway. Note that 
you don't need dateutil (except for its parsing capacities). The rrules are 
completely bypassed, as we're using a quite different approach.



From cclarke at chrisdev.com  Mon Feb 12 15:51:51 2007
From: cclarke at chrisdev.com (Christopher Clarke)
Date: Mon, 12 Feb 2007 16:51:51 -0400
Subject: [SciPy-dev] timeseries tdates.py
In-Reply-To: <200702121441.57108.pgmdevlist@gmail.com>
References: <C8E965DE-6F78-44FC-9DD5-C8534D7DC246@chrisdev.com>
	<200702121441.57108.pgmdevlist@gmail.com>
Message-ID: <CF8BC079-235C-456D-A310-86F6ED9A236D@chrisdev.com>

Hi  Pierre
I am pretty excited about this package as i see it replacing FAME  
TimeIQ and my own hodgepodge stuff
> You can use datetime objects w/ the SVN timeseries package anyway.
Cool.  Could you give me an example??
I am interested in the datetime as i want to store the "raw" data in  
a generic RDBMS (OK PostgreSQL/MS SQlServer  for now)
and i am using SQLAlchemy to access it. The the default is for dates  
is datetime
(i know i can configure psycopg to spit out mxDateTime but i want to  
move away from this)
I've already prototyped some stuff with rrule and relativedate. Hence  
my question!!
I  have used sets, argsort and take to match the "raw dates" from the  
relational table with the dates in the daterange as specified by a rrule
Its actually not as slow as it sounds. Even for 10 year business day  
time series.
Of course it depends on the number of missing observations
I've recently started to do some work with some intraday data so i  
probably need something faster


> Note that
> you don't need dateutil (except for its parsing capacities). The  
> rrules are
> completely bypassed, as we're using a quite different approach.
I am new to your timeseries library so i may be completely off base  
here.
But rrule allows you to configure new/strange  "frequencies" (at  
least the dates that should be in the calendar)
For example many of the emerging stock markets trading only on  
tuesday, wednesday and friday
How do i go about defining new frequencies? do i need to do so in C?

Anyway, keep up the good work
Regards
Chris
PS. Have you seen the scipy 02  paper by Reggie Duggard  ???







From pgmdevlist at gmail.com  Mon Feb 12 19:29:50 2007
From: pgmdevlist at gmail.com (Pierre GM)
Date: Mon, 12 Feb 2007 19:29:50 -0500
Subject: [SciPy-dev] timeseries tdates.py
In-Reply-To: <CF8BC079-235C-456D-A310-86F6ED9A236D@chrisdev.com>
References: <C8E965DE-6F78-44FC-9DD5-C8534D7DC246@chrisdev.com>
	<200702121441.57108.pgmdevlist@gmail.com>
	<CF8BC079-235C-456D-A310-86F6ED9A236D@chrisdev.com>
Message-ID: <200702121929.50562.pgmdevlist@gmail.com>


> I am pretty excited about this package as i see it replacing FAME
> TimeIQ and my own hodgepodge stuff

That's the objective. Of course, we may very well be overly optimistic, but at 
least that's what we're aiming at.

> > You can use datetime objects w/ the SVN timeseries package anyway.
>
> Cool.  Could you give me an example??

Please check the TimeSeriesPackage page on the wiki. That should give you 
plenty of examples. We haven't advertised the package yet as it's still 
experimental. We were initially shooting for earlier this month, but keep 
postponing, taking our sweet time and polishing things.

Anyway, for a more specific answer, if you have a list of dates as datetime 
objects, you can transform them into our own DateArray, the class we're 
handling data with, and use that as the date component of our TimeSeries 
object.

> Of course it depends on the number of missing observations
> I've recently started to do some work with some intraday data so i
> probably need something faster

That sounds great ! We will definitely need your feedback.

> I am new to your timeseries library so i may be completely off base
> here.
> But rrule allows you to configure new/strange  "frequencies" (at
> least the dates that should be in the calendar)
> For example many of the emerging stock markets trading only on
> tuesday, wednesday and friday
> How do i go about defining new frequencies? do i need to do so in C?

Well, yeah, that's definitely a problem at this point. We only 
support 'regular' frequencies, such as daily, business daily, quarterly, 
weekly... That's for conversion from one frequency to another. Note that gaps 
in the data are accepted, so your time steps don't have to be regular. It's 
of course better if they are, and we provide some functions to fill the gaps 
with masked data, but that's not mandatory in most cases.

However, we focused on the easy access of the data. For your particular 
example, you would need data on a business daily basis. Then, you could 
easily retrieve the data corresponding to tuesday, wednesday and friday 
through a condition such as:
dates = series._dates
condition = (dates.day_of_week==1) | (dates.day_of_week==2) | 
(dates.day_of_week == 4)
newseries = series[condition]


> Anyway, keep up the good work
Thanks a lot

> PS. Have you seen the scipy 02  paper by Reggie Duggard  ???
Nope, unfortunately, but I've been chatting a lot with him recently... Reggie 
has been quite helpful i suggesting some ideas for a simplification of 
maskedarray.



From mattknox_ca at hotmail.com  Tue Feb 13 15:12:33 2007
From: mattknox_ca at hotmail.com (Matt Knox)
Date: Tue, 13 Feb 2007 20:12:33 +0000 (UTC)
Subject: [SciPy-dev] timeseries tdates.py
References: <C8E965DE-6F78-44FC-9DD5-C8534D7DC246@chrisdev.com>
	<200702121441.57108.pgmdevlist@gmail.com>
	<CF8BC079-235C-456D-A310-86F6ED9A236D@chrisdev.com>
Message-ID: <loom.20070213T204757-702@post.gmane.org>

> I am pretty excited about this package as i see it replacing FAME  
> TimeIQ and my own hodgepodge stuff

I am in the same situation here. I rely on FAME extensively for financial data,
and would like to decrease that reliance. There are two hurdles to overcome for
that... I need something I can manipulate time series with (and the work for
that is well under way in the timeseries module Pierre and I have been working
on), and I need something to store the TimeSeries objects in.

I have actually developed a python wrapper to a bunch of the FAME c-api stuff
which reads/writes to/from FAME databases using the TimeSeries objects in the
module we are writing. I'm still polishing some things up with that currently,
but I plan to release it at some point (perhaps as part of an IO submodule in
the timeseries module).

> I am interested in the datetime as i want to store the "raw" data in  
> a generic RDBMS (OK PostgreSQL/MS SQlServer  for now)

I'm not a fan of the idea of storing time series data in a relational db.
Performance is gonna suck unless you are storing TimeSeries as binary objects...
but that has a whole host of problems too. I think FAME is still the best
storage solution (that I am aware of) for this kind of data currently.

That being said... I think it would be feasible (although not entirely trivial)
to write a module specifically for storing TimeSeries in pytables. If that was
done, this could potentially trump FAME both in performance, and flexibility. As
a first step, something would have to be written to work with masked arrays in
pytables. It's probably worth waiting for pytables 2.0 (with numpy at its core)
before any work is done on this though. I think a good python timeseries module,
in combination with pytables support, would be a very compelling piece of
software capable of going toe-to-toe with some expensive commericial offerings
out there (ie. FAME) (feature-wise, if not reliability and support-wise).

> I am new to your timeseries library so i may be completely off base  
> here.
> But rrule allows you to configure new/strange  "frequencies" (at  
> least the dates that should be in the calendar)
> For example many of the emerging stock markets trading only on  
> tuesday, wednesday and friday
> How do i go about defining new frequencies? do i need to do so in C?

The tricky part with new frequencies is supporting converting series at one
frequency to another frequency. If you never need to convert from one frequency
to another, it would be very easy to add different frequencies. I don't *think*
rrule would be of any help in this regard, although I am a relative simpleton
and I often miss obvious things :). Pierre and I had talked about adding some
flexibility for defining custom frequencies, but nothing concrete has been
hammered out yet.

> PS. Have you seen the scipy 02  paper by Reggie Duggard  ???

I have not seen it, but would be interested in taking a look if you have a copy
available.

Also, as Pierre mentioned, we are planning to make an announcement regarding
availability of an alpha stage version of the timeseries module in the near
future. The items pushing that back right now are updating tseries.py to reflect
the major overhaul of maskedarray that Pierre did the other day (it actually
won't work right now if you try to use the latest version of maskedarray from
the sandbox in svn), and reviewing some axis labelling behaviour with the
plotlib sub-module and adding some plotting examples to the wiki. There are
other things to do beyond that obviously, but those are the main things holding
up the alpha release (correct me if you disagree here Pierre).

- Matt




From pgmdevlist at gmail.com  Tue Feb 13 15:32:45 2007
From: pgmdevlist at gmail.com (Pierre GM)
Date: Tue, 13 Feb 2007 15:32:45 -0500
Subject: [SciPy-dev] timeseries tdates.py
In-Reply-To: <loom.20070213T204757-702@post.gmane.org>
References: <C8E965DE-6F78-44FC-9DD5-C8534D7DC246@chrisdev.com>
	<CF8BC079-235C-456D-A310-86F6ED9A236D@chrisdev.com>
	<loom.20070213T204757-702@post.gmane.org>
Message-ID: <200702131532.46982.pgmdevlist@gmail.com>


> > PS. Have you seen the scipy 02  paper by Reggie Duggard  ???
>
> I have not seen it, but would be interested in taking a look if you have a
> copy available.

Same here

> ...The items pushing that back right now are updating
> tseries.py to reflect the major overhaul of maskedarray that Pierre did the
> other day (it actually won't work right now if you try to use the latest
> version of maskedarray from the sandbox in svn), and reviewing some axis
> labelling behaviour with the plotlib sub-module and adding some plotting
> examples to the wiki. There are other things to do beyond that obviously,
> but those are the main things holding up the alpha release (correct me if
> you disagree here Pierre).

Funny, reading this sentence I realize these are all things that I'm in charge 
of. Mmh, how strange. 
Unfortunately, this week's gonna be a bit tough for me (some other 
professional commitments), but hopefully the timseries/maskedarray updates 
should be available this week-end.


From huw_lynch at yahoo.com  Wed Feb 14 02:17:38 2007
From: huw_lynch at yahoo.com (Huw Lynch)
Date: Tue, 13 Feb 2007 23:17:38 -0800 (PST)
Subject: [SciPy-dev] AttributeError link_shared_object missing when
	compiling with intel compilers
Message-ID: <219368.49012.qm@web51415.mail.yahoo.com>


Hi

I have been trying to compile scipy using intel compilers on linux. The build keeps failing with the following error;

AttributeError: 'NoneType' object has no attribute 'link_shared_object'


I have tried building using a 0.5.2 release of scipy and the current svn version - both hit the same problem. 

Is there any solution to this? I see several other postings from people reporting similar problems but none that have a working solution.

full traceback...

Traceback (most recent call last):
  File "setup.py", line 55, in ?
    setup_package()
  File "setup.py", line 47, in setup_package
    configuration=configuration )
  File "/opt/numpy/1.0.1//lib/python2.4/site-packages/numpy/distutils/core.py", line 174, in setup
    return old_setup(**new_attr)
  File "/opt/python-2.4.2/lib/python2.4/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/opt/python-2.4.2/lib/python2.4/distutils/dist.py", line 946, in run_commands
    self.run_command(cmd)
  File "/opt/python-2.4.2/lib/python2.4/distutils/dist.py", line 966, in run_command
    cmd_obj.run()
  File "/opt/numpy/1.0.1//lib/python2.4/site-packages/numpy/distutils/command/install.py", line 16, in run
    r = old_install.run(self)
  File "/opt/python-2.4.2/lib/python2.4/distutils/command/install.py", line 506, in run
    self.run_command('build')
  File "/opt/python-2.4.2/lib/python2.4/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/opt/python-2.4.2/lib/python2.4/distutils/dist.py", line 966, in run_command
    cmd_obj.run()
  File "/opt/python-2.4.2/lib/python2.4/distutils/command/build.py", line 112, in run
    self.run_command(cmd_name)
  File "/opt/python-2.4.2/lib/python2.4/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/opt/python-2.4.2/lib/python2.4/distutils/dist.py", line 966, in run_command
    cmd_obj.run()
  File "/opt/numpy/1.0.1//lib/python2.4/site-packages/numpy/distutils/command/build_ext.py", line 121, in run
    self.build_extensions()
  File "/opt/python-2.4.2/lib/python2.4/distutils/command/build_ext.py", line 405, in build_extensions
    self.build_extension(ext)
  File "/opt/numpy/1.0.1//lib/python2.4/site-packages/numpy/distutils/command/build_ext.py", line 312, in build_extension
    link = self.fcompiler.link_shared_object
AttributeError: 'NoneType' object has no attribute 'link_shared_object'

Setup is being invoked as follows;

python setup.py -v config --compiler=intel config_fc --fcompiler=intel install --prefix=/usr/local/scipy

The compilers I am using are

$ ifort -V 
Intel(R) Fortran Itanium(R) Compiler for Itanium(R)-based applications
Version 9.1    Build 20060818 Package ID: l_fc_c_9.1.037
Copyright (C) 1985-2006 Intel Corporation.  All rights reserved.

$ icc -V
Intel(R) C Itanium(R) Compiler for Itanium(R)-based applications
Version 9.1    Build 20060818 Package ID: l_cc_c_9.1.043
Copyright (C) 1985-2006 Intel Corporation.  All rights reserved.

$ uname -a
Linux xnac 2.6.5-7.283-sn2 #1 SMP Wed Nov 29 16:55:53 UTC 2006 ia64 ia64 ia64 GNU/Linux

python is v2.4.2 and numpy v1.0.1

Thanks

H

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070213/ec693670/attachment.html>

From mierle at gmail.com  Thu Feb 15 03:09:04 2007
From: mierle at gmail.com (Keir Mierle)
Date: Thu, 15 Feb 2007 03:09:04 -0500
Subject: [SciPy-dev] Unifying numpy, scipy, and matplotlib docstring formats
Message-ID: <ef5675f30702150009i1ac9c809yd0fbbb9655b4b8b3@mail.gmail.com>

I'd like to help the docstring formats of numpy, scipy. and matplotlib converge
on a high-quality standard (hence the cross-posting). However, before that can
happen all maintainers from all three packages need to agree on a format. In
the interest of speeding things along, I've taken the liberty of extending [1]
the docstring format proposed by Travis on January 10th on the scipy-dev
mailing list [2]. I also volunteer to convert a non-trivial portion of the
numpy, scipy, and matplotlib docstrings. If all goes well on the consensus
front, I'll try to coordinate an IRC docstring sprint or two.

The notable differences from the format Travis posted is that I have
capitalized headers for readability; the other changes are mostly modest, or
additions to handle the more demanding requirements of matplotlib docstrings.

On the DocstringStandard page I have also put a completely re-done docstring
for the 'contour' function from matplotlib. I think it is far more readable
than the original [3]. JDH and other matplotlibheads, what do you think?
Travis, do you find my additions reasonable? Scipy maintainers, would you
consider adopting this format (especially if someone helps with the gruntwork)?

Thanks in advance,
Keir

[1] http://scipy.org/DocstringStandard
[2] http://article.gmane.org/gmane.comp.python.scientific.devel/5572
[3] http://matplotlib.sourceforge.net/matplotlib.pylab.html#-contour

p.s. This is part of my plan to kick off http://scipy.org/PyLab


From mierle at gmail.com  Thu Feb 15 13:42:51 2007
From: mierle at gmail.com (Keir Mierle)
Date: Thu, 15 Feb 2007 13:42:51 -0500
Subject: [SciPy-dev] [Numpy-discussion] Unifying numpy, scipy,
	and matplotlib docstring formats
In-Reply-To: <3d375d730702150902k31a1356ek4743a182902c90aa@mail.gmail.com>
References: <ef5675f30702150009i1ac9c809yd0fbbb9655b4b8b3@mail.gmail.com>
	<3d375d730702150902k31a1356ek4743a182902c90aa@mail.gmail.com>
Message-ID: <ef5675f30702151042u543f508aucd1b0656895b273d@mail.gmail.com>

On 2/15/07, Robert Kern <robert.kern at gmail.com> wrote:
> On 2/15/07, Keir Mierle <mierle at gmail.com> wrote:
> > On the DocstringStandard page I have also put a completely re-done docstring
> > for the 'contour' function from matplotlib. I think it is far more readable
> > than the original [3]. JDH and other matplotlibheads, what do you think?
> > Travis, do you find my additions reasonable? Scipy maintainers, would you
> > consider adopting this format (especially if someone helps with the gruntwork)?
>
> It looks like you took the initial proposal rather than the result of
> that discussion. Please see the document that we came up with:
>
> http://svn.scipy.org/svn/numpy/trunk/numpy/doc/HOWTO_DOCUMENT.txt

Ah, I apologize for not checking the dates; I thought the HOWTO_DOCUMENT.txt
was the older proposal.

Nevertheless, I think the issues raised in my proposed version are significant
enough to warrent further discussion; especially for the more demanding needs
of matplotlib.

I would like to re-open this discussion to be sure there is consensus among the
numpy, scipy, and matplotlib folk before I invest signifcant time into
massaging the docstrings into the right form.

I am clearly biased as I invested time and thought into the proposed docstring
format I posted [1], but nevertheless I do not like the style listed in the
HOWTO_DOCUMENT.txt. The different sections have different styles of headings,
i.e. the difference style for :Pamaraters: and Examples, which is not good for
readability.  Furthermore, it does not specify enough formatting, for e.g.
keyword arguments with defaults.

For specifics, here are my issues with the current HOWTO:

 * Non-capitalized headers
   Capitalized headers are far more visually obvious when viewed on a text
   terminal (i.e. via function? in IPython)

 * Two different header styles
   The distinction between
   :Parameters:
   and
   Examples
   --------
   seems unnecessary; if this is necessary for reST, could a preprocessing step
   not fix this? The inconsistency appears unprofessional when viewed in a
   terminal.

 * No suggestions on how to handle functions which have multiple invocations,
   i.e. multiple function signatures. I have a proposal for this in [1].

 * Parameters / Returns instead of INPUTS / OUTPUTS. This is no doubt a
   preference, but nevertheless I vastly prefer having INPUTS / OUTPUTS instead
   of Parameters / Returns. I understand that the parameter/return form is more
   common for Python, so I realize this is contentious. Nevertheless, inputs /
   outputs has the clear advantage of being informative to someone who is just
   starting programming and may not realize the meanings of parameters /
   returns; but input/output is absolutely clear even to the non-programmer.

If it comes down to me writing a parser for my proposed format, I will do that.

Keir

[1] http://scipy.org/DocstringStandard


From jdh2358 at gmail.com  Thu Feb 15 14:28:59 2007
From: jdh2358 at gmail.com (John Hunter)
Date: Thu, 15 Feb 2007 13:28:59 -0600
Subject: [SciPy-dev] [Numpy-discussion] Unifying numpy, scipy,
	and matplotlib docstring formats
In-Reply-To: <ef5675f30702151042u543f508aucd1b0656895b273d@mail.gmail.com>
References: <ef5675f30702150009i1ac9c809yd0fbbb9655b4b8b3@mail.gmail.com>
	<3d375d730702150902k31a1356ek4743a182902c90aa@mail.gmail.com>
	<ef5675f30702151042u543f508aucd1b0656895b273d@mail.gmail.com>
Message-ID: <88e473830702151128p5687213ds396cb2e013452d90@mail.gmail.com>

On 2/15/07, Keir Mierle <mierle at gmail.com> wrote:

I think most of the developers are on scipy dev, so I'm cutting the
cross-posting

> I would like to re-open this discussion to be sure there is consensus among the
> numpy, scipy, and matplotlib folk before I invest signifcant time into
> massaging the docstrings into the right form.

I don't have a lot to add here because I did not follow the previous
docstring discussions closely.  I generally accept that if Robert says
something should be done a certain way, it's probably right and I
don't want to step in front of a freight train.  That said, I think
from a plain text perspective, your format and example look better
than the markup for ReST ( I really liked the contour example).  Since
I'll usually be reading docs through ipython or in the source code
directly, I prefer documentation with as little explicit markup as
possible, but respect that a significant chunk of users will be
reading docs in html or PDF and the markup certainly helps there.  I
find

:Parameter

and friends ugly though I'm sure they look splendid after pushing them
through ReST.   But I'm a softie and don't care enough about the
intricacies of docstring formatting to make a nuanced argument which
weighs all the details.  I'm probably happy to defer to whatever the
numpy/scipy folks decide on along with you and the other developers
who are pushing this.  Ie, I won't get in your way.

My guess is that you'll have to bear the brunt of the work, because we
have a lot of priorities in terms of development of matplotlib to work
on and a revamp of the docstrings is not at the top of the list.
There are two things I'd like to draw your attention to to see how
they fit into the proposed scheme(s).

  1) mpl uses a docstring formatting convention "ACCEPTS:' in all
set_* matplotlib artist methods.  This supports object introspection,
eg when you do

  >>> line, = plot(...)
  >>> setp(line)

  We could do it another way, and I'm open to it, but right now we are
using docstrings

  2) we use string interpolation to auto-generate repetitive parts of
docstrings, eg the optional keywords that customize lines appear in
many parts of the code.  See the kwdocd stuff in matplotlib.artist and
matplotlib.lines and matplotlib.axes.Axes.plot for an example.  On
first glance, this seems compatible with what you all are proposing,
with some reformatting of course, but I could be missing something so
please take a look at this.

I also concur that the signature section needs to be more general than
a single line, since we have lots of overloaded call signatures.

As for your enhanced  pylab proposals, this is something that I think
is very helpful and I would be happy to return the pylab
name/functionality to the ipython/numpy/scipy/mpl/enthought community.
 Travis originally owned this but at some point it wasn't doing
anything more than  serving as a web page for a collection of his
modules and I asked him if we could use it for the matlab-like
environment incorporating matplotlib and Numeric.  At the time,
matplotlib was pure python and trivial to insstall, and scipy was a
bear to install, so I did not want a dependency on scipy.  Now things
are very different.  matplotlib can be a bear to install, and the
scipy install has gotten much better, and so a single unified package
that brings in all three, rationalizes and factors out their common
functionality etc, publicizes and maintains it, supports installs
across platforms, etc.... would be a wonderful and major achievement.
It is certainly doable, but plan to spend a significant part of next
year working on it if you want to take this on.  We all have good
intentions, but none of the core developers of any of the packages
seems to have the time right now that such an integration effort
entails.  We've talked about it many times at the last scipy meetings.

Supporting easy installs of a comprehensive set of tools across
platforms is a big job.  Not insurmountable, but make sure you
understand what you are signing up for.  If you want to cut your teeth
at cross platform installation and support, you are welcome to take on
the limited task of supporting the matplotlib wx backend across
platforms; this has been a thorn in our side for some time.

So your proposals look really nice, but the devil will be in the
implementation.  Getting the core developers to agree on standards and
a unified environment is a good and useful first step, but the harder
part is getting the work done.

JDH


From aisaac at american.edu  Thu Feb 15 14:40:18 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Thu, 15 Feb 2007 14:40:18 -0500
Subject: [SciPy-dev] [Numpy-discussion] Unifying numpy, scipy,
	and matplotlib docstring formats
In-Reply-To: <ef5675f30702151042u543f508aucd1b0656895b273d@mail.gmail.com>
References: <ef5675f30702150009i1ac9c809yd0fbbb9655b4b8b3@mail.gmail.com><3d375d730702150902k31a1356ek4743a182902c90aa@mail.gmail.com><ef5675f30702151042u543f508aucd1b0656895b273d@mail.gmail.com>
Message-ID: <Mahogany-0.67.0-1448-20070215-144018.00@american.edu>

On Thu, 15 Feb 2007, Keir Mierle apparently wrote:
>  * Two different header styles
>    The distinction between
>    :Parameters:
>    and
>    Examples
>    --------

These are not two items of the same type.
``:Parameters:`` designates a consolidated field (for 
describing the documented object).  This is not a "section".

Cheers,
Alan Isaac






From mierle at gmail.com  Thu Feb 15 18:18:27 2007
From: mierle at gmail.com (Keir Mierle)
Date: Thu, 15 Feb 2007 18:18:27 -0500
Subject: [SciPy-dev] [Numpy-discussion] Unifying numpy, scipy,
	and matplotlib docstring formats
In-Reply-To: <88e473830702151128p5687213ds396cb2e013452d90@mail.gmail.com>
References: <ef5675f30702150009i1ac9c809yd0fbbb9655b4b8b3@mail.gmail.com>
	<3d375d730702150902k31a1356ek4743a182902c90aa@mail.gmail.com>
	<ef5675f30702151042u543f508aucd1b0656895b273d@mail.gmail.com>
	<88e473830702151128p5687213ds396cb2e013452d90@mail.gmail.com>
Message-ID: <ef5675f30702151518w490ecfb5ua1c9eae7cbf751c9@mail.gmail.com>

On 2/15/07, John Hunter <jdh2358 at gmail.com> wrote:
> On 2/15/07, Keir Mierle <mierle at gmail.com> wrote:
> > I would like to re-open this discussion to be sure there is consensus among the
> > numpy, scipy, and matplotlib folk before I invest signifcant time into
> > massaging the docstrings into the right form.
>
> I don't have a lot to add here because I did not follow the previous
> docstring discussions closely.  I generally accept that if Robert says
> something should be done a certain way, it's probably right and I
> don't want to step in front of a freight train.  That said, I think
> from a plain text perspective, your format and example look better
> than the markup for ReST ( I really liked the contour example).  Since
> I'll usually be reading docs through ipython or in the source code
> directly, I prefer documentation with as little explicit markup as
> possible, but respect that a significant chunk of users will be
> reading docs in html or PDF and the markup certainly helps there.
>
> I find
>
> :Parameter
>
> and friends ugly though I'm sure they look splendid after pushing them
> through ReST.   But I'm a softie and don't care enough about the
> intricacies of docstring formatting to make a nuanced argument which
> weighs all the details.  I'm probably happy to defer to whatever the
> numpy/scipy folks decide on along with you and the other developers
> who are pushing this.  Ie, I won't get in your way.

I will put my keyboard where my mouth is, i.e. write an epydoc parser.

> My guess is that you'll have to bear the brunt of the work, because we
> have a lot of priorities in terms of development of matplotlib to work
> on and a revamp of the docstrings is not at the top of the list.

If the entire documentation revamp must be done by me, then it will take some
time (I should be finishing my thesis!) Hopefully I can get some non-core
developers to particpate in a sprint, but maybe I am being too optimistic.

> There are two things I'd like to draw your attention to to see how
> they fit into the proposed scheme(s).
>
>   1) mpl uses a docstring formatting convention "ACCEPTS:' in all
> set_* matplotlib artist methods.  This supports object introspection,
> eg when you do
>
>   >>> line, = plot(...)
>   >>> setp(line)
>
>   We could do it another way, and I'm open to it, but right now we are
> using docstrings

I will have to think about this and read the code more before I can comment,
though I think this should be fine.

>   2) we use string interpolation to auto-generate repetitive parts of
> docstrings, eg the optional keywords that customize lines appear in
> many parts of the code.  See the kwdocd stuff in matplotlib.artist and
> matplotlib.lines and matplotlib.axes.Axes.plot for an example.  On
> first glance, this seems compatible with what you all are proposing,
> with some reformatting of course, but I could be missing something so
> please take a look at this.

This should be entirely compatible with the current scheme.

> As for your enhanced  pylab proposals, this is something that I think
> is very helpful and I would be happy to return the pylab
> name/functionality to the ipython/numpy/scipy/mpl/enthought community.

I have the pylab.net domain too.

> Travis originally owned this but at some point it wasn't doing
> anything more than  serving as a web page for a collection of his
> modules and I asked him if we could use it for the matlab-like
> environment incorporating matplotlib and Numeric.  At the time,
> matplotlib was pure python and trivial to insstall, and scipy was a
> bear to install, so I did not want a dependency on scipy.  Now things
> are very different.  matplotlib can be a bear to install, and the
> scipy install has gotten much better, and so a single unified package
> that brings in all three, rationalizes and factors out their common
> functionality etc, publicizes and maintains it, supports installs
> across platforms, etc.... would be a wonderful and major achievement.
> It is certainly doable, but plan to spend a significant part of next
> year working on it if you want to take this on.  We all have good
> intentions, but none of the core developers of any of the packages
> seems to have the time right now that such an integration effort
> entails.  We've talked about it many times at the last scipy meetings.

Unfortunatley the only platform I can do this on is Linux, because I don't have
access to windows or mac machines. I hear there is now a native GTK port for
mac which doesn't depend on X11, though it is not ready yet. GTK has worked
well on windows for some time.  What about switching to GTK as the prefered
multiplatform backend?

Ideally I would like to take all the work required to, for example, rationalize
and factor common functionality out, and push it all upstream. Ideall PyLab
would just be a single script which pulls down python/numpy/scipy/matplotlib,
and compiles into the final product, because the packages are inherently
designed to work together. This is probably impossible, but I can dream.

> Supporting easy installs of a comprehensive set of tools across
> platforms is a big job.  Not insurmountable, but make sure you
> understand what you are signing up for.  If you want to cut your teeth
> at cross platform installation and support, you are welcome to take on
> the limited task of supporting the matplotlib wx backend across
> platforms; this has been a thorn in our side for some time.

Personally I do not like wx at all. I am not (yet) volunteering to take this
on, because I certainly do not have the experience. The reason I set up the
pylab page is so that the community (or at the moment, myself) can identify not
just the sore points, but very specific next-physical-action type lists for how
to fix the issues.

For new contributors, it's hard to do something useful when the list of things
in need of improvement is, as someone once put it, an amorphous blob of
undoability.

> So your proposals look really nice, but the devil will be in the
> implementation.  Getting the core developers to agree on standards and
> a unified environment is a good and useful first step, but the harder
> part is getting the work done.

Certainly! This is why I am starting with the small initial step of deciding on
an excellent docstring standard (which I feel is extremely important), and will
forget about the future until that is at least mostly underway.

I hope the PyLab vision is possible, but it is a huge amount of work, and I
definitely will not be able to do it myself.

Keir


From david.huard at gmail.com  Thu Feb 15 23:57:06 2007
From: david.huard at gmail.com (David Huard)
Date: Thu, 15 Feb 2007 23:57:06 -0500
Subject: [SciPy-dev] [Matplotlib-users] [matplotlib-devel] Unifying
	numpy, scipy, and matplotlib docstring formats
In-Reply-To: <45D50245.1080102@noaa.gov>
References: <ef5675f30702150009i1ac9c809yd0fbbb9655b4b8b3@mail.gmail.com>
	<45D4ED02.1050908@noaa.gov>
	<ef5675f30702151607h187c69d4t6360d490a88292ce@mail.gmail.com>
	<45D50245.1080102@noaa.gov>
Message-ID: <91cf711d0702152057y563e4526o554577ac955dbca7@mail.gmail.com>

In the previous docstring thread, there has been a lot of lively discussion
about whether or not we should follow reST syntax for the docstrings.
Briefly put, the arguments were that some of the markup is ugly, but then
using the markup gives you access to packages processing reST to generate
nice looking output for api documentation. At the time, the concensus was
that we should follow the reST syntax, with an additional role (:math:) and
directive (.. math::)  to process latex formulas. However, I get the feeling
that there are many people who feel that this tradeoff between console
readability and ease of post-processing is disapointing (I am one of those),
and that there should be a way to get the best of both worlds. I submitted
my concern for the lack of a clear documentation standard to the reST dev
ML, but didn't get much feedback.

Jens ( a docutils dev) and Alan suggested that plugin support for docutils
was in the air, but a lack of man power delayed its implementation. I don't
how far we could go with this idea, but maybe it would be possible to write
a plugin for docutils to specifically parse docstrings. The plugin would be
loaded by other apps making use of docutils, so we wouldn't have to hack the
epydoc parser or any third party application using reST. By restricting the
application of the plugins to docstrings (and not all the other stuff reST
is used for), we could probably remove some of the terseness of the markup,
and get a result that looks good on console and in print, without having to
manage patches for docutils, epydoc and all the others tools that are out
there.

For example, the plugin could enable directives to be written as

DIRECTIVE:
    blablabla
(capitalized word + : + indented block) as in Keir's proposal,

instead of
.. directive::
    blablabla

which would allow us to get rid of :Parameters: and friends.

Cheers,

David

2007/2/15, Christopher Barker <Chris.Barker at noaa.gov>:
>
> Keir Mierle wrote:
> > I do not want to descend into a huge, time wasting discussion of this
> > which is not productive.
>
> Well, it's been said before, and this isn't really the place for it, but
> it's quite critical to your project. Don't let any of this get in the
> way of improving docs strings, however!
> > Note that I am not suggesting a recursive import of submodules.
>
> What you appeared to support was that all of the matplotlib, numpy and
> scipy base namespaces be merged, and they should all be merged into the
> main namespace.
>
> >> import matplotlib as plot
> >> import numpy as N
> >> import Scipy.whatever as whatever.
> >
> > UGH. See, this is my issue. When I read someone else's code, they always
> > chose a different convention.
>
> Good point, that is a bit of a pain. It would certainly be a good idea
> to standardize at least these three, and have them be imported by
> default in your environment (though I'm not sure about scipy -- numpy
> and matplotlib would be good)
>
> > If we define the official way to use pylab as 'from pylab import *',
> > then these problems vanish.
>
> and others arise. One is that you then have to make sure you don't' get
> any name clashes you don't want, so you end up with arange, so it won't
> clash with range. etc.
>
> > Note that we must be *very* careful to export only
> > exactly the names which should be exported;
>
> Then how do you get the others? "import *" and "import pylab"?
>
> > Because it is always the case
> > that I use numpy and pylab together.
>
> I use numpy every day without pylab. And I use pylab occasionally
> without numpy, it accepts regular old lists for quick hacking.
>
> This is a key point -- if all anyone does is use your mega-pylab, then
> you may be right, but let's not cripple people. Let them start using
> PyLab for matlab-like quickie coding, then decide to write a real app,
> and be able to start using wxPython without learning a bunch of new
> stuff, and having namespaces clash.
>
> > Other non-core modules should be
> > treated as usual, where it is at the author's discretion for how to
> import them.
>
> Everyone's idea of non-core is different
>
> Even if you insist on joining numpy and plotting namespaces (they are
> both too big at the moment, if you ask me), please tell people to import
> it as:
>
> import pylab
>
> I think a consensus is building in the python community that you should
> NEVER use import *!
>
> some history:
>
> wxPython used to be commonly used as:
>
> from wxpython import *
>
> And the names were all: wxSomeName.
>
> A few years back, the names were all changed to remove the wx, and we
> now all do:
>
> import wx
> this = wx.SomeName(...)
>
> Numeric was designed to be used with "import *". Now many of the old
> Numeric functions are available as numpy methods, and more and more
> people are using some variation of:
>
> import numpy as N
>
> and fewer are using "import *"
>
> Does anyone else have any other examples?
>
> One more reason: more IDEs are providing auto-completion and module
> browsers. Smaller, more hierarchical namespaces are much better for
> this. I know if I'm looking for a number crunching or a plotting
> function -- make it easier to find them.
>
> > I think Scott Meyer, a C++ luminary, said it best [1] when this heinous
> > fragment of his code was posted in comp.lang.c++.moderated
>
> namespaces are a new add-on to C++ -- it will be a good while before
> they are used right there!
>
> > This is only for the core functionality. The scipy/numpy/matplotlib core
> > API becomes similar in importance to Python's __builtins__ for the PyLab
> > environment.
>
> >>> len(dir(__builtins__))
> 129
> >>> len(dir(pylab))
> 432
>
> and __builtins__ is too big as it is. -- 31 of those are Exceptions,
> they should have their own namespace, if you ask me. Would it be that
> much harder to type
>
> except Errors.Type:
>
> than
>
> except TypeError:
>
> > I argue that Python's __builtins__ should be equivalent to PyLab's from
> > pylab
> > import *, and that e.g. import sys corresponds to import linalg.
>
> But then you have __builtins__ and pylab in the same namespace!
>
> > Perhaps non-interactively; when using the system interactively the
> MATLAB
> > interface is by far the best way to go. If someone proposes an oo
> interface
> > which is as fast to type and as easy to understand as the MATLAB
> interface
> > (i.e. to demo to my friends who came over to see what I'm talking about
> > when I
> > say that PyLab is great) then I'm all ears.
>
> Look for my (and other) posts about this for more detail, but a few
> points:
>
> 1) Don't break long-term productivity/useability so that the quicky
> demos are more impressive. Python's real strength over tools like Matlab
> shows up when projects get bigger.
>
> 2) There is nothing about an OO interface that is inherently harder to
> use, or even more typing, except perhaps a few extra dots.
>
> 3) There is some work to be done to bring the matplotlib OO interface up
> to its potential for interactive use, particularly the docs!
>
> > Note that this discussion is early! I am waaaay not here yet; first step
> > is to fix the docstrings.
>
> Yes, enough said for now -- and I really appreciate your efforts to
> clean up the docstrings.
>
> -Chris
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070215/1cc2f963/attachment.html>

From david at ar.media.kyoto-u.ac.jp  Sat Feb 17 23:10:16 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sun, 18 Feb 2007 13:10:16 +0900
Subject: [SciPy-dev] Google summer of code 2007
Message-ID: <45D7D1A8.7060207@ar.media.kyoto-u.ac.jp>

Hi there,

    The summer of code 2007 is on:

    http://code.google.com/soc/

    I was wondering if the "institutions" linked to numpy/scipy intended 
to jump in like last year ? I myself would be quite interested in 
joining as a student (mostly to improve the statistical 
estimation/learning and signal processing parts of scipy).

    cheers,

    David


From yves.frederix at gmail.com  Sun Feb 18 04:41:07 2007
From: yves.frederix at gmail.com (Yves Frederix)
Date: Sun, 18 Feb 2007 10:41:07 +0100
Subject: [SciPy-dev] Testfailures on AMD 64 bit, pathscale and ACML
Message-ID: <20070218094107.GA4911@kotnet.org>

Hi,

I have compiled numpy/scipy on a 64bit AMD Opteron system using
pathscale and the ACML library. The numpy tests runs fine, but the scipy
test suite returns 20 failures. In attachment you can find the error
messages for scipy.test(1,10).

	0 u0050015 at lo-03-01 .../package $ python -c "import numpy; print 'numpy:',numpy.__version__; import scipy; print 'scipy:', scipy.__version__"
	numpy: 1.0.2.dev3546
	scipy: 0.5.3.dev2708


Cheers,
YVES
-------------- next part --------------
<snip>
check_definition (scipy.fftpack.tests.test_helper.test_fftshift) ... ok
check_inverse (scipy.fftpack.tests.test_helper.test_fftshift) ... ok
check_definition (scipy.fftpack.tests.test_helper.test_rfftfreq) ... ok
test_init (scipy.io.tests.test_npfile.test_npfile) ... ok
test_parse_endian (scipy.io.tests.test_npfile.test_npfile) ... ok
test_read_write_array (scipy.io.tests.test_npfile.test_npfile) ... ok
test_read_write_raw (scipy.io.tests.test_npfile.test_npfile) ... ok
test_remaining_bytes (scipy.io.tests.test_npfile.test_npfile) ... ok

======================================================================
FAIL: check_h1vp (scipy.special.tests.test_basic.test_h1vp)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1125, in check_h1vp
    assert_almost_equal(h1,h1real,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: (nan+nanj)
 DESIRED: (0.498126301704+63.0552722957j)

======================================================================
FAIL: check_h2vp (scipy.special.tests.test_basic.test_h2vp)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1132, in check_h2vp
    assert_almost_equal(h2,h2real,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: (nan+nanj)
 DESIRED: (0.498126301704-63.0552722957j)

======================================================================
FAIL: check_hankel1 (scipy.special.tests.test_basic.test_hankel1)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1026, in check_hankel1
    assert_almost_equal(hank1,hankrl,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: (7.60802597223e-317+2.31778632931e-310j)
 DESIRED: (0.0499375260362-6.4589510947j)

======================================================================
FAIL: check_hankel2 (scipy.special.tests.test_basic.test_hankel2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1044, in check_hankel2
    assert_almost_equal(hank2,hankrl2,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: (7.60802597223e-317+2.31778632931e-310j)
 DESIRED: (0.0499375260362+6.4589510947j)

======================================================================
FAIL: check_i0e (scipy.special.tests.test_basic.test_i0e)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1217, in check_i0e
    assert_almost_equal(oize,oizer,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 0.907100925782
 DESIRED: 0.0

======================================================================
FAIL: check_i1e (scipy.special.tests.test_basic.test_i1e)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1239, in check_i1e
    assert_almost_equal(oi1e,oi1er,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 0.0452984468088
 DESIRED: 1.20947270102e-320

======================================================================
FAIL: check_ive (scipy.special.tests.test_basic.test_ive)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1280, in check_ive
    assert_almost_equal(ive1,iv1,10)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 0.0
 DESIRED: 0.907100925782

======================================================================
FAIL: check_jve (scipy.special.tests.test_basic.test_jve)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1353, in check_jve
    assert_almost_equal(jvexp,0.099500832639235995,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 1.20947270102e-320
 DESIRED: 0.099500832639235995

======================================================================
FAIL: check_k0 (scipy.special.tests.test_basic.test_k0)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1431, in check_k0
    assert_almost_equal(ozk,ozkr,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 2.4270690247
 DESIRED: nan

======================================================================
FAIL: check_k0e (scipy.special.tests.test_basic.test_k0e)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1438, in check_k0e
    assert_almost_equal(ozke,ozker,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 2.68232610226
 DESIRED: nan

======================================================================
FAIL: check_k1 (scipy.special.tests.test_basic.test_k1)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1445, in check_k1
    assert_almost_equal(o1k,o1kr,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 9.85384478087
 DESIRED: 1.20947270102e-320

======================================================================
FAIL: check_k1e (scipy.special.tests.test_basic.test_k1e)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1452, in check_k1e
    assert_almost_equal(o1ke,o1ker,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 10.890182683
 DESIRED: 1.20947270102e-320

======================================================================
FAIL: check_kv0 (scipy.special.tests.test_basic.test_kv)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1590, in check_kv0
    assert_almost_equal(kv0, 1.7527038555281462, 10)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: nan
 DESIRED: 1.7527038555281462

======================================================================
FAIL: check_kv1 (scipy.special.tests.test_basic.test_kv)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1593, in check_kv1
    assert_almost_equal(kv1, 4.775972543220472, 10)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 1.20947270102e-320
 DESIRED: 4.7759725432204716

======================================================================
FAIL: check_kv2 (scipy.special.tests.test_basic.test_kv)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1596, in check_kv2
    assert_almost_equal(kv2, 49.51242928773287, 10)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 1.20947270102e-320
 DESIRED: 49.512429287732871

======================================================================
FAIL: check_kve (scipy.special.tests.test_basic.test_kve)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1606, in check_kve
    assert_almost_equal(kve1,kv1,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: nan
 DESIRED: nan

======================================================================
FAIL: check_y0_zeros (scipy.special.tests.test_basic.test_y0_zeros)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 2139, in check_y0_zeros
    assert_array_almost_equal(abs(yv(1,all)-allval),0.0,11)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 230, in assert_array_almost_equal
    header='Arrays are not almost equal')
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 215, in assert_array_compare
    assert cond, msg
AssertionError: 
Arrays are not almost equal

(mismatch 100.0%)
 x: array([ 0.8794208 ,  0.40254267,  0.88770329,  0.58789742])
 y: array(0.0)

======================================================================
FAIL: check_yve (scipy.special.tests.test_basic.test_yve)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 2186, in check_yve
    assert_almost_equal(yve2,-3.3238249881118471,8)
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError: 
Items are not equal:
 ACTUAL: 1.20947270102e-320
 DESIRED: -3.3238249881118471

======================================================================
FAIL: test_explicit (scipy.tests.test_odr.test_odr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/odr/tests/test_odr.py", line 49, in test_explicit
    np.array([  1.2646548050648876e+03,  -5.4018409956678255e+01,
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 230, in assert_array_almost_equal
    header='Arrays are not almost equal')
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 215, in assert_array_compare
    assert cond, msg
AssertionError: 
Arrays are not almost equal

(mismatch 100.0%)
 x: array([  1.26462971e+03,  -5.42545890e+01,  -8.64250389e-02])
 y: array([  1.26465481e+03,  -5.40184100e+01,  -8.78497122e-02])

======================================================================
FAIL: test_multi (scipy.tests.test_odr.test_odr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/scipy/odr/tests/test_odr.py", line 190, in test_multi
    np.array([ 4.3799880305938963,  2.4333057577497703,  8.0028845899503978,
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 230, in assert_array_almost_equal
    header='Arrays are not almost equal')
  File "/apps/prod/python/modules/svn/lib/python2.4/site-packages/numpy/testing/utils.py", line 215, in assert_array_compare
    assert cond, msg
AssertionError: 
Arrays are not almost equal

(mismatch 100.0%)
 x: array([ 4.31272063,  2.44289312,  7.76215871,  0.55995622,  0.46423343])
 y: array([ 4.37998803,  2.43330576,  8.00288459,  0.51011472,  0.51739023])

----------------------------------------------------------------------
Ran 1616 tests in 3.658s

FAILED (failures=20)

From nwagner at iam.uni-stuttgart.de  Mon Feb 19 03:52:22 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 19 Feb 2007 09:52:22 +0100
Subject: [SciPy-dev] stringency of the tests
Message-ID: <45D96546.8040609@iam.uni-stuttgart.de>

Hi all,

I have filed a test failure. The comment by Stefan was

#375: FAIL: check_syevr (scipy.lib.tests.test_lapack.test_flapack_float)
-----------------------+----------------------------------------------------
 Reporter:  nils       |        Owner:  somebody
     Type:  defect     |       Status:  new     
 Priority:  normal     |    Milestone:          
Component:  scipy.lib  |      Version:          
 Severity:  normal     |   Resolution:          
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by stefan):

 We should just relax the stringency of the test -- those results look
 good.


I guess this is also true for

======================================================================
FAIL: Solve: single precision complex
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib64/python2.5/site-packages/scipy/linsolve/umfpack/tests/test_umfpack.py",
line 32, in check_solve_complex_without_umfpack
    assert_array_almost_equal(a*x, b)
  File
"/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line
230, in assert_array_almost_equal
    header='Arrays are not almost equal')
  File
"/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line
215, in assert_array_compare
    assert cond, msg
AssertionError:
Arrays are not almost equal

(mismatch 20.0%)
 x: array([ 1.        +0.j,  1.99999809+0.j,  3.        +0.j, 
4.00000048+0.j,
        5.        +0.j], dtype=complex64)
 y: array([1, 2, 3, 4, 5])



Can someone reproduce the errors wrt odr ?

======================================================================
ERROR: test_explicit (scipy.tests.test_odr.test_odr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib64/python2.5/site-packages/scipy/odr/tests/test_odr.py",
line 46, in test_explicit
    out = explicit_odr.run()
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 1049, in run
    self.output = Output(apply(odr, args, kwds))
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 576, in __init__
    self.stopreason = report_error(self.info)
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 143, in report_error
    'Iteration limit reached')[info % 10]
IndexError: tuple index out of range

======================================================================
ERROR: test_lorentz (scipy.tests.test_odr.test_odr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib64/python2.5/site-packages/scipy/odr/tests/test_odr.py",
line 291, in test_lorentz
    out = l_odr.run()
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 1049, in run
    self.output = Output(apply(odr, args, kwds))
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 576, in __init__
    self.stopreason = report_error(self.info)
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 143, in report_error
    'Iteration limit reached')[info % 10]
IndexError: tuple index out of range

======================================================================
ERROR: test_multi (scipy.tests.test_odr.test_odr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib64/python2.5/site-packages/scipy/odr/tests/test_odr.py",
line 187, in test_multi
    out = multi_odr.run()
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 1049, in run
    self.output = Output(apply(odr, args, kwds))
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 576, in __init__
    self.stopreason = report_error(self.info)
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 143, in report_error
    'Iteration limit reached')[info % 10]
IndexError: tuple index out of range

======================================================================
ERROR: test_pearson (scipy.tests.test_odr.test_odr)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib64/python2.5/site-packages/scipy/odr/tests/test_odr.py",
line 235, in test_pearson
    out = p_odr.run()
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 1049, in run
    self.output = Output(apply(odr, args, kwds))
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 576, in __init__
    self.stopreason = report_error(self.info)
  File "/usr/local/lib64/python2.5/site-packages/scipy/odr/odrpack.py",
line 143, in report_error
    'Iteration limit reached')[info % 10]
IndexError: tuple index out of range



From zufus at zufus.org  Wed Feb 21 20:57:14 2007
From: zufus at zufus.org (Marco Presi)
Date: Thu, 22 Feb 2007 01:57:14 +0000
Subject: [SciPy-dev] Patches for sandbox/montecarlo and pilutil.py
Message-ID: <1172109434.10474.17.camel@mafia.sssup.it>

Hi,

I am attaching here a couple of patches I applied to scipy distributed
with Debian.

The first one fixes a syntax error in
sandbox/motecarlo/test_dictsampler.py

The second one replaces the hard-coded image-viewer "xv" with the
command "see" (provided by mime-support); it ensures that a valid image
viewer is always called, even if xv is not installed [1].

Regards,

Marco

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395198


Patches:
--------

--- Lib/sandbox/montecarlo/tests/test_dictsampler.py.orig    2007-02-22
01:29:56.000000000 +0000
+++ Lib/sandbox/montecarlo/tests/test_dictsampler.py    2007-02-22
01:30:59.000000000 +0000
@@ -37,7 +37,7 @@
         #import pdb
         #pdb.set_trace()
         s = sampler.sample(n)
-        assert sum(s[i]=='b' for i in range(n),axis=0)*1./n > 0.75
+        assert sum((s[i]=='b' for i in range(n)),axis=0)*1./n > 0.75

         #lam = 10.0
         #n = 35


--- Lib/misc/pilutil.py.orig    2006-08-29 08:56:12.000000000 +0100
+++ Lib/misc/pilutil.py 2007-02-18 20:36:39.000000000 +0000
@@ -230,7 +230,10 @@
         try:
             import os
             im.save('/tmp/scipy_imshow.png')
-            if os.system("(xv /tmp/scipy_imshow.png; rm
-f /tmp/scipy_imshow.png)&"):
+            cmd = "see"
+            if os.environ.has_key ("SCIPY_PIL_IMAGE_VIEWER"):
+                cmd = os.environ.get ("SCIPY_PIL_IMAGE_VIEWER")
+            if os.system("(" + cmd + " /tmp/scipy_imshow.png; rm
-f /tmp/scipy_imshow.png)&"):
                 raise RuntimeError
             return
         except:





From stefan at sun.ac.za  Thu Feb 22 04:47:27 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 22 Feb 2007 11:47:27 +0200
Subject: [SciPy-dev] Patches for sandbox/montecarlo and pilutil.py
In-Reply-To: <1172109434.10474.17.camel@mafia.sssup.it>
References: <1172109434.10474.17.camel@mafia.sssup.it>
Message-ID: <20070222094727.GT5912@mentat.za.net>

On Thu, Feb 22, 2007 at 01:57:14AM +0000, Marco Presi wrote:
> I am attaching here a couple of patches I applied to scipy distributed
> with Debian.

Thanks for the patches, Marco.  Please see

http://projects.scipy.org/scipy/scipy/changeset/2745

and

http://projects.scipy.org/scipy/scipy/changeset/2744

Cheers
St?fan


From nwagner at iam.uni-stuttgart.de  Thu Feb 22 04:52:54 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 22 Feb 2007 10:52:54 +0100
Subject: [SciPy-dev] sandbox.image
Message-ID: <45DD67F6.5030506@iam.uni-stuttgart.de>

Hi Robert K.,

I cannot build sanbox.image due to

  File "Lib/sandbox/setup.py", line 22, in configuration
    config.add_subpackage(p)
  File
"/usr/lib64/python2.4/site-packages/numpy/distutils/misc_util.py", line
765, in add_subpackage
    caller_level = 2)
  File
"/usr/lib64/python2.4/site-packages/numpy/distutils/misc_util.py", line
748, in get_subpackage
    caller_level = caller_level + 1)
  File
"/usr/lib64/python2.4/site-packages/numpy/distutils/misc_util.py", line
695, in _get_configuration_from_setup_py
    config = setup_module.configuration(*args)
  File "Lib/sandbox/image/setup.py", line 6, in configuration
    config.add_data_files("""ciexyz31_1.txt ciexyz64_1.txt ciexyzjv.txt
  File
"/usr/lib64/python2.4/site-packages/numpy/distutils/misc_util.py", line
903, in add_data_files
    d,files = files[0]
ValueError: too many values to unpack
 
Cheers,
                     Nils



From stefan at sun.ac.za  Thu Feb 22 05:10:37 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 22 Feb 2007 12:10:37 +0200
Subject: [SciPy-dev] sandbox.image
In-Reply-To: <45DD67F6.5030506@iam.uni-stuttgart.de>
References: <45DD67F6.5030506@iam.uni-stuttgart.de>
Message-ID: <20070222101037.GU5912@mentat.za.net>

On Thu, Feb 22, 2007 at 10:52:54AM +0100, Nils Wagner wrote:
> Hi Robert K.,
> 
> I cannot build sanbox.image due to
> 
>   File "Lib/sandbox/setup.py", line 22, in configuration
>     config.add_subpackage(p)

[...]

Just a small typo -- fixed in SVN.

Cheers
St?fan


From nwagner at iam.uni-stuttgart.de  Thu Feb 22 05:15:58 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 22 Feb 2007 11:15:58 +0100
Subject: [SciPy-dev] sandbox.image
In-Reply-To: <20070222101037.GU5912@mentat.za.net>
References: <45DD67F6.5030506@iam.uni-stuttgart.de>
	<20070222101037.GU5912@mentat.za.net>
Message-ID: <45DD6D5E.3080103@iam.uni-stuttgart.de>

Stefan van der Walt wrote:
> On Thu, Feb 22, 2007 at 10:52:54AM +0100, Nils Wagner wrote:
>   
>> Hi Robert K.,
>>
>> I cannot build sanbox.image due to
>>
>>   File "Lib/sandbox/setup.py", line 22, in configuration
>>     config.add_subpackage(p)
>>     
>
> [...]
>
> Just a small typo -- fixed in SVN.
>
> Cheers
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   
 Many thanks !

Nils



From zufus at zufus.org  Thu Feb 22 05:41:36 2007
From: zufus at zufus.org (Marco Presi)
Date: Thu, 22 Feb 2007 10:41:36 +0000
Subject: [SciPy-dev] Patches for sandbox/montecarlo and pilutil.py
In-Reply-To: <20070222094727.GT5912@mentat.za.net>
References: <1172109434.10474.17.camel@mafia.sssup.it>
	<20070222094727.GT5912@mentat.za.net>
Message-ID: <1172140896.3897.1.camel@mafia.sssup.it>

Il giorno gio, 22/02/2007 alle 11.47 +0200, Stefan van der Walt ha
scritto:
[..]

> Thanks for the patches, Marco.  Please see
                                         ^^^
:)


> http://projects.scipy.org/scipy/scipy/changeset/2744

I will look for other place in the code where a similar fix could be
applied.

Ciao Ciao

Marco




From stefan at sun.ac.za  Thu Feb 22 06:08:44 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 22 Feb 2007 13:08:44 +0200
Subject: [SciPy-dev] Patches for sandbox/montecarlo and pilutil.py
In-Reply-To: <1172140896.3897.1.camel@mafia.sssup.it>
References: <1172109434.10474.17.camel@mafia.sssup.it>
	<20070222094727.GT5912@mentat.za.net>
	<1172140896.3897.1.camel@mafia.sssup.it>
Message-ID: <20070222110844.GW5912@mentat.za.net>

On Thu, Feb 22, 2007 at 10:41:36AM +0000, Marco Presi wrote:
> Il giorno gio, 22/02/2007 alle 11.47 +0200, Stefan van der Walt ha
> scritto:
> [..]
> 
> > Thanks for the patches, Marco.  Please see
>                                          ^^^
> :)

Sorry, did I miss something?

Cheers
St?fan


From mattknox_ca at hotmail.com  Thu Feb 22 11:46:26 2007
From: mattknox_ca at hotmail.com (Matt Knox)
Date: Thu, 22 Feb 2007 11:46:26 -0500
Subject: [SciPy-dev] scipy license compatibility
Message-ID: <BAY119-W11F61A21E15519B1DB3B698C8F0@phx.gbl>


Wondering if either of the following licenses are compatible with scipy:
 
Academic Free License ("AFL") v. 3.0: http://opensource.org/licenses/afl-3.0.php
EGENIX public license: http://www.egenix.com/files/python/mxLicense.html#Public
 
I'm pretty sure the GNU GPL is not compatible, is that correct?
 
Might be a good idea to have a list of compatible and incompatible open source licences somewhere on the web-site (I can start that myself actually if nobody objects)
 
- Matt Knox
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070222/de5ea979/attachment.html>

From wnbell at gmail.com  Thu Feb 22 11:54:20 2007
From: wnbell at gmail.com (Nathan Bell)
Date: Thu, 22 Feb 2007 10:54:20 -0600
Subject: [SciPy-dev] scipy license compatibility
In-Reply-To: <BAY119-W11F61A21E15519B1DB3B698C8F0@phx.gbl>
References: <BAY119-W11F61A21E15519B1DB3B698C8F0@phx.gbl>
Message-ID: <d05265cb0702220854i349300fdkb8ade391cda1cf94@mail.gmail.com>

On 2/22/07, Matt Knox <mattknox_ca at hotmail.com> wrote:
>  I'm pretty sure the GNU GPL is not compatible, is that correct?

That's my understanding.  I don't know about the LGPL though.

>  Might be a good idea to have a list of compatible and incompatible open
> source licences somewhere on the web-site (I can start that myself actually
> if nobody objects)

I agree, that would be very helpful.

-- 
Nathan Bell wnbell at gmail.com


From robert.kern at gmail.com  Thu Feb 22 12:14:00 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 22 Feb 2007 11:14:00 -0600
Subject: [SciPy-dev] sandbox.image
In-Reply-To: <20070222101037.GU5912@mentat.za.net>
References: <45DD67F6.5030506@iam.uni-stuttgart.de>
	<20070222101037.GU5912@mentat.za.net>
Message-ID: <45DDCF58.3010109@gmail.com>

Stefan van der Walt wrote:
> On Thu, Feb 22, 2007 at 10:52:54AM +0100, Nils Wagner wrote:
>> Hi Robert K.,
>>
>> I cannot build sanbox.image due to
>>
>>   File "Lib/sandbox/setup.py", line 22, in configuration
>>     config.add_subpackage(p)
> 
> [...]
> 
> Just a small typo -- fixed in SVN.

Sorry! I meant to commit that fix before I went to bed. And then I didn't.  :-(

-- 
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


From robert.kern at gmail.com  Thu Feb 22 12:17:13 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 22 Feb 2007 11:17:13 -0600
Subject: [SciPy-dev] scipy license compatibility
In-Reply-To: <d05265cb0702220854i349300fdkb8ade391cda1cf94@mail.gmail.com>
References: <BAY119-W11F61A21E15519B1DB3B698C8F0@phx.gbl>
	<d05265cb0702220854i349300fdkb8ade391cda1cf94@mail.gmail.com>
Message-ID: <45DDD019.1000004@gmail.com>

Nathan Bell wrote:
> On 2/22/07, Matt Knox <mattknox_ca at hotmail.com> wrote:
>>  I'm pretty sure the GNU GPL is not compatible, is that correct?
> 
> That's my understanding.  I don't know about the LGPL though.

We are still trying to stick with BSD-like licenses for scipy itself. The LGPL
is not one of them.

-- 
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


From robert.kern at gmail.com  Thu Feb 22 12:49:53 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 22 Feb 2007 11:49:53 -0600
Subject: [SciPy-dev] scipy license compatibility
In-Reply-To: <BAY119-W11F61A21E15519B1DB3B698C8F0@phx.gbl>
References: <BAY119-W11F61A21E15519B1DB3B698C8F0@phx.gbl>
Message-ID: <45DDD7C1.8010601@gmail.com>

Matt Knox wrote:
> Wondering if either of the following licenses are compatible with scipy:
>  
> Academic Free License ("AFL") v.
> 3.0: http://opensource.org/licenses/afl-3.0.php
> EGENIX public license:
> http://www.egenix.com/files/python/mxLicense.html#Public
>  
> I'm pretty sure the GNU GPL is not compatible, is that correct?
>  
> Might be a good idea to have a list of compatible and incompatible open
> source licences somewhere on the web-site (I can start that myself
> actually if nobody objects)

It depends on what you mean by "compatible". If you mean to ask whether or not
scipy's code can be combined with code with other licenses, then the answer is
almost always "yes". scipy's license is about as least-restrictive as you can get.

However, that means that our policy of only incorporating code with similar
licenses is fairly strict. That means that we cannot accept GPL and LGPL code
into scipy.

I would like to be able to incorporate AFL code. It is substantially a BSD-like
license, only it is clearer and on better legal ground. However, the FSF
believes it to be incompatible with the GPL, and I don't want that submarine
lying in wait for someone who wants to combine scipy with GPLed code.

The EGENIX public license looks fine to me.

-- 
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


From mattknox_ca at hotmail.com  Thu Feb 22 13:43:29 2007
From: mattknox_ca at hotmail.com (Matt Knox)
Date: Thu, 22 Feb 2007 18:43:29 +0000 (UTC)
Subject: [SciPy-dev] scipy license compatibility
References: <BAY119-W11F61A21E15519B1DB3B698C8F0@phx.gbl>
Message-ID: <loom.20070222T193820-168@post.gmane.org>

I have added a wiki page on license compatibility issues (
http://www.scipy.org/License_Compatibility ). I haven't added any items to the
"compatible" list yet, only to the "incompatible" list. Could someone with more
knowledge on these issues than myself take a look at the wording and see if it
looks ok before I add any licenses to the "compatible" list?

Also, would a link on the "developer zone" section of the web-site to this page
be appropriate? or is there a better place to link to it?

Thanks,

- Matt Knox



From matthieu.brucher at gmail.com  Tue Feb 27 07:54:58 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Tue, 27 Feb 2007 13:54:58 +0100
Subject: [SciPy-dev] Proposal for more generic optimizers (posted before on
	scipy-user)
Message-ID: <e76aa17f0702270454q6edbe9c3oe07330e3bd140f41@mail.gmail.com>

Hi,

I'm migratting toward Python for some weeks, but I do not find the tools I
had to develop for my PhD in SciPy at the moment. I can't, for instance,
find an elegant way to save the set of parameters used in an optimization
for the standard algorithms. What is more, I think they can be more generic.

What I did in C++, and I'd like your opinion about porting it in Python, was
to define a standard optimizer with no iteration loop - iterate was a pure
virtual method called by a optimize method -. This iteration loop was then
defined for standard optimizer or damped optimizer. Each time, the
parameters tested could be saved. Then, the step that had to be taken was an
instance of a class that used a gradient step, a Newton step, ... and the
same was used for the stoping criterion. The function was a class that
defined value, gradient, hessian, ... if needed.
For instance, a simplified instruction could have been :
Optimizer* optimizer = StandardOptimizer</*some more parameters not relevant
in Python*/(function, GradientStep(), SimpleCriterion(NbMaxIterations),
step, saveParameters);
optimizer->optimize();
optimizer->getOptimalParameters();

The "step" argument was a constant by which the computed step had to be
multiplied, by default, it was 1.

I know that this kind of writting is not as clear and lightweight as the
current one, which is used by Matlab too. But perhaps giving more latitude
to the user can be proposed with this system. If people want, I can try
making a real Python example...

Matthieu

P.S. : sorry for the multiposting, I forgot that there were two ML for SciPy
:(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070227/ef47cf8f/attachment.html>

From mattknox_ca at hotmail.com  Tue Feb 27 13:44:00 2007
From: mattknox_ca at hotmail.com (Matt Knox)
Date: Tue, 27 Feb 2007 13:44:00 -0500
Subject: [SciPy-dev] request to be added to editors list wiki page
Message-ID: <BAY118-W19EE0EC547B3D614E0339C8C820@phx.gbl>


I'm working on a wiki (http://www.scipy.org/TimeSeriesPackage) and need to edit/delete some attachments I have placed there. Could someone please add me to the editors list for the scipy wiki? My wiki username is "MattKnox". Thanks,
 
- Matt Knox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070227/a4d34b40/attachment.html>

From robert.kern at gmail.com  Tue Feb 27 14:20:37 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 27 Feb 2007 13:20:37 -0600
Subject: [SciPy-dev] request to be added to editors list wiki page
In-Reply-To: <BAY118-W19EE0EC547B3D614E0339C8C820@phx.gbl>
References: <BAY118-W19EE0EC547B3D614E0339C8C820@phx.gbl>
Message-ID: <45E48485.5040002@gmail.com>

Matt Knox wrote:
> I'm working on a wiki (http://www.scipy.org/TimeSeriesPackage) and need
> to edit/delete some attachments I have placed there. Could someone
> please add me to the editors list for the scipy wiki? My wiki username
> is "MattKnox". Thanks,

Done.

-- 
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


From jeremit0 at gmail.com  Tue Feb 27 15:31:43 2007
From: jeremit0 at gmail.com (Jeremy Conlin)
Date: Tue, 27 Feb 2007 15:31:43 -0500
Subject: [SciPy-dev] no linalg module and failed check_integer test
Message-ID: <3db594f70702271231s2b0f3fd3l79f1342b11d408d2@mail.gmail.com>

I just installed scipy from svn and I am having some problems.  The
most vexing is that I can no longer load the linalg package, at least
I can't do anything with it.  For example:

Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
>>> scipy.pkgload('linalg')
>>> help(scipy.linalg)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'linalg'
>>> A = scipy.ones((10,10))
>>> scipy.linalg.eig(A)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'linalg'
>>>

I didn't notice any errors during the installation.  I know this isn't
a lot of information to go on, but does anyone know what the problem
is?

Secondly, and this might be related, when I run

scipy.test(1,10)

I get the error shown below.  Could this be the cause of my linalg problem?
Thanks in advance,
Jeremy


test_init (scipy.io.tests.test_npfile.test_npfile) ... ok
test_parse_endian (scipy.io.tests.test_npfile.test_npfile) ... ok
test_read_write_array (scipy.io.tests.test_npfile.test_npfile) ... ok
test_read_write_raw (scipy.io.tests.test_npfile.test_npfile) ... ok
test_remaining_bytes (scipy.io.tests.test_npfile.test_npfile) ... ok

======================================================================
ERROR: check_integer (scipy.io.tests.test_array_import.test_read_array)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/io/tests/test_array_import.py",
line 55, in check_integer
    from scipy import stats
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/stats/__init__.py",
line 7, in <module>
    from stats import *
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/stats/stats.py",
line 190, in <module>
    import scipy.special as special
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/special/__init__.py",
line 8, in <module>
    from basic import *
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/special/basic.py",
line 8, in <module>
    from _cephes import *
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/special/_cephes.so,
2): Symbol not found: ___dso_handle
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/special/_cephes.so
  Expected in: dynamic lookup


----------------------------------------------------------------------
Ran 554 tests in 2.424s

FAILED (errors=1)
<unittest.TextTestRunner object at 0x2a49fb0>


From v-nijs at kellogg.northwestern.edu  Tue Feb 27 15:44:28 2007
From: v-nijs at kellogg.northwestern.edu (Vincent Nijs)
Date: Tue, 27 Feb 2007 14:44:28 -0600
Subject: [SciPy-dev] from scipy import * error on ppc
Message-ID: <C209F44C.663E%v-nijs@kellogg.northwestern.edu>

I get the following output on a G5 PPC, OS 10.4.8 when I do 'from scipy
import *'. I am using the most recent Mac developer tools and gfortran. This
is for todays SVN builds of numpy and scipy.

Thanks,

Vincent



In [4]: from scipy import *
---------------------------------------------------------------------------
exceptions.OverflowError                             Traceback (most recent
call last)

/Users/vrn953/<ipython console>

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-package
s/scipy/io/__init__.py
     10 from mio import *
     11 from npfile import npfile
---> 12 from recaster import sctype_attributes, Recaster
     13 from array_import import *
     14 from data_store import *

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-package
s/scipy/io/recaster.py
     47     pass
     48 
---> 49 class Recaster(object):
     50     ''' Class to recast arrays to one of acceptable scalar types
     51 

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-package
s/scipy/io/recaster.py in Recaster()
     59     '''
     60 
---> 61     _sctype_attributes = sctype_attributes()
     62     _k = 2**10
     63     _option_defaults = {

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-package
s/scipy/io/recaster.py in sctype_attributes()
     13         t_list = sctypes[sc_type]
     14         for T in t_list:
---> 15             F = finfo(T)
     16             dt = dtype(T)
     17             d_dict[T] = {

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-package
s/numpy/lib/getlimits.py in __new__(cls, dtype)
     47         if obj is not None:
     48             return obj
---> 49         obj = object.__new__(cls)._init(dtype)
     50         for dt in dtypes:
     51             cls._finfo_cache[dt] = obj

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-package
s/numpy/lib/getlimits.py in _init(self, dtype)
     73                         lambda v:array(_frz(v)[0], dtype),
     74                         lambda v: fmt % array(_frz(v)[0], dtype),
---> 75                         'numpy %s precision floating point number' %
precname)
     76 
     77         for word in ['precision', 'iexp',

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-package
s/numpy/lib/machar.py in __init__(self, float_conv, int_conv,
float_to_float, float_to_str, title)
    263 
    264         import math
--> 265         self.precision = int(-math.log10(float_to_float(self.eps)))
    266         ten = two + two + two + two + two
    267         resolution = ten ** (-self.precision)

OverflowError: math range error

-- 





From nwagner at iam.uni-stuttgart.de  Wed Feb 28 04:38:12 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 28 Feb 2007 10:38:12 +0100
Subject: [SciPy-dev] UMFPACKv4.4 and swig memory leak of type 'void *'
Message-ID: <45E54D84.8010103@iam.uni-stuttgart.de>

Hi all,

scipy.test(1,10) reports a lot of memory leaks, e.g.

Getting factors of complex matrixswig/python detected a memory leak of
type 'void *', no destructor found.
Getting factors of real matrixswig/python detected a memory leak of type
'void *', no destructor found.
Solve with UMFPACK: double precision complexswig/python detected a
memory leak of type 'void *', no destructor found.
swig/python detected a memory leak of type 'void *', no destructor found.
 ... ok
Solve: single precision complexUse minimum degree ordering on A'+A.
 ... ok
Solve with UMFPACK: double precisionswig/python detected a memory leak
of type 'void *', no destructor found.
swig/python detected a memory leak of type 'void *', no destructor found.
 ... ok

Is this a swig problem ?

I am using

Numpy version 1.0.2.dev3562
Scipy version 0.5.3.dev2774

cat /proc/cpuinfo yields

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping        : 6
cpu MHz         : 1596.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 3726.92
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping        : 6
cpu MHz         : 1596.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 3724.17
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

amd_info:
    libraries = ['amd']
    library_dirs = ['/usr/local/src/UMFPACKv4.4/AMD/Lib']
    define_macros = [('SCIPY_AMD_H', None)]
    swig_opts = ['-I/usr/local/src/UMFPACKv4.4/AMD/Include']
    include_dirs = ['/usr/local/src/UMFPACKv4.4/AMD/Include']

umfpack_info:
    libraries = ['umfpack', 'amd']
    library_dirs = ['/usr/local/src/UMFPACKv4.4/UMFPACK/Lib',
'/usr/local/src/UMFPACKv4.4/AMD/Lib']
    define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)]
    swig_opts = ['-I/usr/local/src/UMFPACKv4.4/UMFPACK/Include',
'-I/usr/local/src/UMFPACKv4.4/AMD/Include']
    include_dirs = ['/usr/local/src/UMFPACKv4.4/UMFPACK/Include',
'/usr/local/src/UMFPACKv4.4/AMD/Include']

rpm -qi swig
Name        : swig                         Relocations: (not relocatable)
Version     : 1.3.29                            Vendor: SUSE LINUX
Products GmbH, Nuernberg, Germany
Release     : 29                            Build Date: Mon 27 Nov 2006
10:46:51 PM CET
Install Date: Mon 19 Feb 2007 09:04:53 AM CET      Build Host:
lanner.suse.de
Group       : Development/Languages/C and C++   Source RPM:
swig-1.3.29-29.src.rpm
Size        : 3602040                          License: BSD License and
BSD-like
Signature   : DSA/SHA1, Mon 27 Nov 2006 10:57:29 PM CET, Key ID
a84edae89c800aca
Packager    : http://bugs.opensuse.org
URL         : http://www.swig.org
Summary     : Simplified Wrapper and Interface Generator
 
Nils
 


From cimrman3 at ntc.zcu.cz  Wed Feb 28 06:31:40 2007
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Wed, 28 Feb 2007 12:31:40 +0100
Subject: [SciPy-dev] UMFPACKv4.4 and swig memory leak of type 'void *'
In-Reply-To: <45E54D84.8010103@iam.uni-stuttgart.de>
References: <45E54D84.8010103@iam.uni-stuttgart.de>
Message-ID: <45E5681C.6020400@ntc.zcu.cz>

Nils Wagner wrote:
> Hi all,
> 
> scipy.test(1,10) reports a lot of memory leaks, e.g.
> 
> Getting factors of complex matrixswig/python detected a memory leak of
> type 'void *', no destructor found.
> Getting factors of real matrixswig/python detected a memory leak of type
> 'void *', no destructor found.
> Solve with UMFPACK: double precision complexswig/python detected a
> memory leak of type 'void *', no destructor found.
> swig/python detected a memory leak of type 'void *', no destructor found.
>  ... ok
> Solve: single precision complexUse minimum degree ordering on A'+A.
>  ... ok
> Solve with UMFPACK: double precisionswig/python detected a memory leak
> of type 'void *', no destructor found.
> swig/python detected a memory leak of type 'void *', no destructor found.
>  ... ok
> 
> Is this a swig problem ?

Hi Nils,

It did appear with recent versions of swig, but I am not sure whether it
is a swig problem (they could just add a new warning), or a problem in
my wrappers. I have just asked on swig ML...

r.