From warren.weckesser at enthought.com Sat Dec 4 15:40:13 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sat, 4 Dec 2010 14:40:13 -0600 Subject: [SciPy-Dev] Use NPY_INFINITY in cephes code in scipy.special? Message-ID: scipy.special.zeta(1.0, 1) returns 1.7976931348623157e+308 to indicate infinity. Here's the relevant snippet from zeta.c: ----- if( x == 1.0 ) goto retinf; if( x < 1.0 ) { domerr: mtherr( "zeta", DOMAIN ); return(NPY_NAN); } if( q <= 0.0 ) { if(q == floor(q)) { mtherr( "zeta", SING ); retinf: return( MAXNUM ); } if( x != floor(x) ) goto domerr; /* because q^-x not defined */ } ----- Is there any problem with changing MAXNUM to NPY_INFINITY? Note that the use of NPY_NAN was added in r5880, with the check-in comment "Use npy_math NAN and INFINITY instead of hacked/buggy version of cephes.". David, if you're out there, can you see any reason to not use NPY_INFINITY here instead of MAXNUM? Similar (ab)uses of MAXNUM occur in other special functions. For example, in ndtri() (the inverse of the normal distribution's CDF), we have: ----- if( y0 <= 0.0 ) { mtherr( "ndtri", DOMAIN ); return( -MAXNUM ); } if( y0 >= 1.0 ) { mtherr( "ndtri", DOMAIN ); return( MAXNUM ); } ----- but this makes more sense to me (and it matches the behavior of scipy.stats.norm.ppf()): ----- if (y0 < 0.0 || y > 1.0) { mtherr("ndtri", DOMAIN); return(NPY_NAN); } if (y0 == 0.0) { return(-NPY_INFINITY); } if (y0 == 1.0) { return(NPY_INFINITY); } ----- Before I pursue this further, is there any reason to *not* make changes like these? Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Sat Dec 4 15:48:25 2010 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 4 Dec 2010 20:48:25 +0000 (UTC) Subject: [SciPy-Dev] Use NPY_INFINITY in cephes code in scipy.special? References: Message-ID: On Sat, 04 Dec 2010 14:40:13 -0600, Warren Weckesser wrote: > scipy.special.zeta(1.0, 1) returns 1.7976931348623157e+308 to indicate > infinity. Here's the relevant snippet from zeta.c: [clip] Yes, proper infinities should be used instead of MAXNUM. I don't think there's any valid mathematical reason for returning a big but finite result at points where the function is numerically infinite. Fixing these systematically could be useful. -- Pauli Virtanen From pav at iki.fi Sat Dec 4 16:32:32 2010 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 4 Dec 2010 21:32:32 +0000 (UTC) Subject: [SciPy-Dev] ARPACK fixes before 0.9 References: Message-ID: On Mon, 29 Nov 2010 17:40:37 -0700, Aric Hagberg wrote: [clip] > The simplest is to raise an error though it would be nice, and fitting > of the name eigsh, to fall back to eigs(). Ok, the commits are in. I decided to make eigsh() raise an error on complex input, and leave it to the user to use the correct routine. -- Pauli Virtanen From ralf.gommers at googlemail.com Sun Dec 5 03:31:58 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 5 Dec 2010 16:31:58 +0800 Subject: [SciPy-Dev] reminder: 0.9.x branching this Friday Message-ID: Hi all, Here's a friendly reminder that the 0.9.x branch will be created this coming Friday. Please get your new code/features in before then. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From cimrman3 at ntc.zcu.cz Mon Dec 6 06:20:50 2010 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Mon, 06 Dec 2010 12:20:50 +0100 Subject: [SciPy-Dev] ANN: SfePy 2010.4 Message-ID: <4CFCC712.9050508@ntc.zcu.cz> I am pleased to announce release 2010.4 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method. The code is based on NumPy and SciPy packages. It is distributed under the new BSD license. Home page: http://sfepy.org Mailing lists, issue tracking: http://code.google.com/p/sfepy/ Git (source) repository: http://github.com/sfepy Documentation: http://docs.sfepy.org/doc Highlights of this release -------------------------- - higher order elements - refactoring of geometries (reference mappings) - transparent DOF vector synchronization with variables - interface variables defined on a surface region For more information on this release, see http://sfepy.googlecode.com/svn/web/releases/2010.4_RELEASE_NOTES.txt (full release notes, rather long and technical). Best regards, Robert Cimrman and Contributors (*) (*) Contributors to this release (alphabetical order): Vladim?r Luke?, Logan Sorenson, Olivier Verdier From dagss at student.matnat.uio.no Wed Dec 8 08:26:55 2010 From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn) Date: Wed, 08 Dec 2010 14:26:55 +0100 Subject: [SciPy-Dev] fwrap refactor: Emulating f2py array shape handling? Message-ID: <4CFF879F.4050700@student.matnat.uio.no> In the ongoing fwrap refactor I'm trying hard to emulate f2py completely. Still it'd be good to know whether you consider the behaviour of f2py a feature or a mis-feature. If the latter, it'd be trivial to, e.g., include a flag that would allow people to experiment with fwrap vs. f2py behaviour, and change to the former at some point if the fwrap refactor is pulled upstream. The question is how functions should deal with arrays of a different rank than what they expect. Possibilities: f2py behaviour: Go to very great lengths to convert array shapes. Assume the function to be called wants a 2D array, then: - Array of shape (1, 1, 3, 1, 1, 4, 1) is treated as (3, 4) # ignore 1-length - (1, 1, 3, 1, 5, 6) => (3, 30) # flatten trailing dimensions - (3) -> (3, 1) # pad with 1-length dims on right side - I think there's more... fwrap behaviour: Simply raise exception if the rank and dimension does not match. My opinion: I think f2py is going too far, and would prefer something that is closer to the simpler broadcasting rules of NumPy ("Explicit is better than implicit"). Perhaps allow (3,) -> (3, 1), but not the others... Dag Sverre From oliphant at enthought.com Wed Dec 8 08:57:56 2010 From: oliphant at enthought.com (Travis Oliphant) Date: Wed, 8 Dec 2010 07:57:56 -0600 Subject: [SciPy-Dev] fwrap refactor: Emulating f2py array shape handling? In-Reply-To: <4CFF879F.4050700@student.matnat.uio.no> References: <4CFF879F.4050700@student.matnat.uio.no> Message-ID: <61195DD5-AC25-42D2-8FB3-071631BF9CA8@enthought.com> I think f2py behavior is too aggressive as well. Definitely broadcasting should be supported, but probably not much else. Travis -- (mobile phone of) Travis Oliphant Enthought, Inc. 1-512-536-1057 http://www.enthought.com On Dec 8, 2010, at 7:26 AM, Dag Sverre Seljebotn wrote: > In the ongoing fwrap refactor I'm trying hard to emulate f2py > completely. Still it'd be good to know whether you consider the > behaviour of f2py a feature or a mis-feature. If the latter, it'd be > trivial to, e.g., include a flag that would allow people to experiment > with fwrap vs. f2py behaviour, and change to the former at some point if > the fwrap refactor is pulled upstream. > > The question is how functions should deal with arrays of a different > rank than what they expect. Possibilities: > > f2py behaviour: Go to very great lengths to convert array shapes. Assume > the function to be called wants a 2D array, then: > > - Array of shape (1, 1, 3, 1, 1, 4, 1) is treated as (3, 4) # ignore > 1-length > - (1, 1, 3, 1, 5, 6) => (3, 30) # flatten trailing dimensions > - (3) -> (3, 1) # pad with 1-length dims on right side > - I think there's more... > > fwrap behaviour: Simply raise exception if the rank and dimension does > not match. > > My opinion: I think f2py is going too far, and would prefer something > that is closer to the simpler broadcasting rules of NumPy ("Explicit is > better than implicit"). Perhaps allow (3,) -> (3, 1), but not the others... > > Dag Sverre > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From paulymer at gmail.com Wed Dec 8 15:44:54 2010 From: paulymer at gmail.com (Sidney Elmer) Date: Wed, 8 Dec 2010 12:44:54 -0800 Subject: [SciPy-Dev] scipy-0.8.0 install feedback: python-2.7.1 numpy-1.5.1 MacOSX-10.5.8 Message-ID: Hi, I'm not sure if this is the proper place to report bugs; if not, I apologize and hope that it will get passed along to the appropriate list. I am using a Mac Pro Dual Quad Core Intel Xeon, 2.26 GHz (Nehalem) with Mac OS X 10.5.8. I installed python2.7.1 with architecture flags -arch i386 -arch x86_64. I also installed numpy1.5.1. I used the standard command to install scipy-0.8.0: $ sudo python setup.py install (this is the 64 bit python executable). While building scipy.sparse.linalg I got the following errors: building 'scipy.sparse.linalg.isolve._iterative' extension compiling C sources C compiler: gcc -fno-strict-aliasing -fno-common -dynamic -arch i386 -arch x86_64 -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes creating build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse creating build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg creating build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve creating build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative compile options: '-DNO_ATLAS_INFO=3 -Ibuild/src.macosx-10.5-intel-2.7 -I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy /core/include -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c' extra options: '-faltivec' gcc: build/src.macosx-10.5-intel-2.7/fortranobject.c gcc: build/src.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/_iterativemodule.c compiling Fortran sources Fortran f77 compiler: /usr/local/bin/g77 -g -Wall -fno-second-underscore -fPIC -O3 -funroll-loops creating build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse creating build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg creating build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve creating build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative compile options: '-DNO_ATLAS_INFO=3 -Ibuild/src.macosx-10.5-intel-2.7 -I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy /core/include -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c' g77:f77: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/STOPTEST2.f g77:f77: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/getbreak.f g77:f77: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGREVCOM.f g77:f77: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.f build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.f: In subroutine `sbicgstabrevcom': build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.f:275: warning: CALL sAXPY( N, -OMEGA, WORK(1,V), 1, WORK(1,P), 1 ) 1 build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.f:277: (continued): CALL sAXPY( N, ONE, WORK(1,R), 1, WORK(1,P), 1 ) 2 Argument #2 of `saxpy' is one precision at (2) but is some other precision at (1) [info -f g77 M GLOBALS] build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.f: In subroutine `cbicgstabrevcom': build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.f:1131: warning: CALL cAXPY( N, -OMEGA, WORK(1,V), 1, WORK(1,P), 1 ) 1 build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.f:1133: (continued): CALL cAXPY( N, ONE, WORK(1,R), 1, WORK(1,P), 1 ) 2 Argument #2 of `caxpy' is one precision at (2) but is some other precision at (1) [info -f g77 M GLOBALS] g77:f77: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/CGREVCOM.f g77:f77: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/CGSREVCOM.f g77:f77: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/GMRESREVCOM.f g77:f77: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.f build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.f: In subroutine `dqmrrevcom': In file included from build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.f:0: build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.f:685: warning: unused variable 'deltatolepstol' build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.f: In subroutine `zqmrrevcom': build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.f:1809: warning: unused variable 'deltatolepstol' /usr/local/bin/g77 -g -Wall -g -Wall -undefined dynamic_lookup -bundle build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/build/src.macosx-10 .5-intel-2.7/scipy/sparse/linalg/isolve/iterative/_iterativemodule.o build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/fortranobject.o build /temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/STOPTEST2.o build/temp.macosx-10.5-intel-2.7/build/src.mac osx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/getbreak.o build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/iso lve/iterative/BiCGREVCOM.o build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.o build/tem p.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/CGREVCOM.o build/temp.macosx-10.5-intel-2.7/build/src.macosx-1 0.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/CGSREVCOM.o build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/ iterative/GMRESREVCOM.o build/temp.macosx-10.5-intel-2.7/build/src.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.o -L/usr/local/lib/ gcc/i686-apple-darwin8.8.1/3.4.0 -Lbuild/temp.macosx-10.5-intel-2.7 -lg2c -o build/lib.macosx-10.5-intel-2.7/scipy/sparse/linalg/isolve/_iterative.so -Wl,- framework -Wl,Accelerate Now, when I try to use the scipy.sparse.linalg module in the 64 bit python executable, the module cannot be loaded: $ python Python 2.7.1 (r271:86832, Dec 3 2010, 14:46:24) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.sparse.linalg Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/sparse/linalg/__init__.py", line 5, in from isolve import * File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/sparse/linalg/isolve/__init__.py", line 4, in from iterative import * File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/sparse/linalg/isolve/iterative.py", line 5, in import _iterative ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/sparse/linalg/isolve/_iterative.so, 2): no suitable image found. Did find: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/sparse/linalg/isolve/_iterative.so: mach-o, but wrong architecture But when I use the 32 bit python executable, it loads fine: $ python-32 Python 2.7.1 (r271:86832, Dec 3 2010, 14:46:24) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.sparse.linalg I hope this information is helpful to fix this problem. Let me know if you need any more information. Sid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Thu Dec 9 07:27:54 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 9 Dec 2010 20:27:54 +0800 Subject: [SciPy-Dev] scipy-0.8.0 install feedback: python-2.7.1 numpy-1.5.1 MacOSX-10.5.8 In-Reply-To: References: Message-ID: On Thu, Dec 9, 2010 at 4:44 AM, Sidney Elmer wrote: > Hi, > > I'm not sure if this is the proper place to report bugs; if not, I > apologize and hope that it will get passed along to the appropriate list. I > am using a Mac Pro Dual Quad Core Intel Xeon, 2.26 GHz (Nehalem) with Mac OS > X 10.5.8. I installed python2.7.1 with architecture flags -arch i386 -arch > x86_64. I also installed numpy1.5.1. > Please check that ">>> numpy.test('full')" gives you no failures. > I used the standard command to install scipy-0.8.0: $ sudo python > setup.py install (this is the 64 bit python executable). > You shouldn't use sudo, just "python setup.py install" works better. And install either from svn trunk or the 0.8.x branch, 0.8.0 does not work with Python 2.7 out of the box. > While building scipy.sparse.linalg I got the following errors: > You should use gfortran instead of g77. Get it from http://r.research.att.com/tools/. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagss at student.matnat.uio.no Thu Dec 9 14:11:56 2010 From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn) Date: Thu, 09 Dec 2010 20:11:56 +0100 Subject: [SciPy-Dev] fwrap refactor: What about complex -> real? Message-ID: <4D0129FC.4020603@student.matnat.uio.no> When faced with Fortran functions expecting a real scalar, f2py will happily accept complex numbers and silently discard the imaginary part. Is this really the preferred behaviour? It would take quite a bit of work to have fwrap behave like that, and I've heard occasional complaints about the behaviour earlier (can't say I'm fond of it myself either). Opinions? (Note that Python implements ".real" on float objects, so the fix is in all cases trivial when this breaks things for people, one just appends ".real" when calling the function, which should also increase the readability of the code.) Dag Sverre From charles.moliere at gmail.com Thu Dec 9 14:39:42 2010 From: charles.moliere at gmail.com (Charles Moliere) Date: Thu, 9 Dec 2010 14:39:42 -0500 Subject: [SciPy-Dev] (no subject) Message-ID: charles.moliere at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.moliere at gmail.com Thu Dec 9 14:34:55 2010 From: charles.moliere at gmail.com (Charles) Date: Thu, 9 Dec 2010 19:34:55 +0000 (UTC) Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example References: Message-ID: Skipper Seabold gmail.com> writes: > > On Tue, Sep 28, 2010 at 1:12 PM, James Phillips zunzun.com> wrote: > > Since I observed the following behavior in the SVN respository version > > of SciPy, it seemed to me proper to post to the dev mailing list. ?I'm > > using Ubuntu Lucid Lynx 32 bit and a fresh GIT of Numpy. ?I am not > > sure if a Trac bug report needs to be entered. > > > > > > Below is some example code for fitting two statistical distributions. > > Sometimes the numpy-generated data is fit, as I can see the estimated > > and fitted parameters are different. ?Sometimes I receive many > > messages repeated on the command line like: > > > > Warning: invalid value encountered in absolute > > Warning: invalid value encountered in subtract > > > > and the estimated parameters equal the fitted parameter values, > > indicating no fitting took place. ?Sometimes I receive on the command > > line: > > > > Traceback (most recent call last): > > ?File "/home/zunzun/local/lib/python2.6/site- packages/scipy/stats/distributions.py", > > line 1987, in func > > ? ?sk = 2*(b-a)*math.sqrt(a + b + 1) / (a + b + 2) / math.sqrt(a*b) > > ValueError: math domain error > > Traceback (most recent call last): > > ?File "example.py", line 10, in > > ? ?fitStart_beta = scipy.stats.beta._fitstart(data) > > ?File "/home/zunzun/local/lib/python2.6/site- packages/scipy/stats/distributions.py", > > line 1992, in _fitstart > > ? ?a, b = optimize.fsolve(func, (1.0, 1.0)) > > ?File "/home/zunzun/local/lib/python2.6/site- packages/scipy/optimize/minpack.py", > > line 125, in fsolve > > ? ?maxfev, ml, mu, epsfcn, factor, diag) > > minpack.error: Error occured while calling the Python function named func > > > > and program flow is stopped. > > > > > > In summary, three behaviors: (1) Fits OK (2) Many exceptions with no > > fitting (3) minpack error. ?Running the program 10 times or so will > > reproduce these behaviors without fail from the "bleeding-edge" > > repository code. > > > > ? ? James Phillips > > > > > > ######################################################## > > > > import numpy, scipy, scipy.stats > > > > # test uniform distribution fitting > > data = numpy.random.uniform(2.0, 3.0, size=100) > > fitStart_uniform = scipy.stats.uniform._fitstart(data) > > fittedParameters_uniform = scipy.stats.uniform.fit(data) > > > > # test beta distribution fitting > > data = numpy.random.beta(2.0, 3.0, size=100) > > fitStart_beta = scipy.stats.beta._fitstart(data) > > fittedParameters_beta = scipy.stats.beta.fit(data) > > > > print > > print 'uniform._fitstart returns', fitStart_uniform > > print 'fitted parameters for uniform =', fittedParameters_uniform > > print > > print 'beta._fitstart returns', fitStart_beta > > print 'fitted parameters for beta =', fittedParameters_beta > > print > > _______________________________________________ > > Is there an existing bug ticket for this? If not there probably should be... > > I think the fitting code should be looked at as experimental. It's > good that you caught that no fitting is actually done in these cases. > The problem stems (for the most part) from bad starting values > (outside the support of the distribution for those with bounded > support). I've tried to go through and fix this, giving very naive > (but correct) starting values to fit methods, but I haven't gotten > much further than that. > > I don't know if Travis or Josef have gone back to look at this. > Hopefully one of these days I will find some more time to look at this > and try to give a systematic fix. > > Skipper > Hi, I'm very sorry for entering the thread like this, but after a long search over the web, this thread is the more relevant to my problem which I'm stuck with. I'm actually trying to fit a gamma distribution on a set of experimental values with gamma.fit() in scipy 0.8.0. Here is the very simple code I'm using with a sample of my data: ########################## import scipy as sp import scipy.stats as ss exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] data = sp.array(exp_data) fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) print(fit_alpha,fit_loc,fit_beta) ######################### I then receive many messages on the command line: Warning: invalid value encountered in subtract Which ends with no fitting of the parameters: (1.0, 0.0, 1.0) With earlier version of scipy (0.7.2), the error message are absent but still no fitting is done. Apparently, it is the extrem value of "4500.3" that is causing problem with the fitting in this case. I know you metionned earlier that the fitting code should be considered as experimental, however I was wondering if this should be considered as a bug, or if I'm making a mistake. In either case, is there a fix for the fit method to work with a gamma distribution? Many thanks, Charles From jsseabold at gmail.com Thu Dec 9 15:12:52 2010 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 9 Dec 2010 15:12:52 -0500 Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example In-Reply-To: References: Message-ID: On Thu, Dec 9, 2010 at 2:34 PM, Charles wrote: > Skipper Seabold gmail.com> writes: > >> >> On Tue, Sep 28, 2010 at 1:12 PM, James Phillips zunzun.com> > wrote: >> > Since I observed the following behavior in the SVN respository version >> > of SciPy, it seemed to me proper to post to the dev mailing list. ?I'm >> > using Ubuntu Lucid Lynx 32 bit and a fresh GIT of Numpy. ?I am not >> > sure if a Trac bug report needs to be entered. >> > >> > >> > Below is some example code for fitting two statistical distributions. >> > Sometimes the numpy-generated data is fit, as I can see the estimated >> > and fitted parameters are different. ?Sometimes I receive many >> > messages repeated on the command line like: >> > >> > Warning: invalid value encountered in absolute >> > Warning: invalid value encountered in subtract >> > >> > and the estimated parameters equal the fitted parameter values, >> > indicating no fitting took place. ?Sometimes I receive on the command >> > line: >> > >> > Traceback (most recent call last): >> > ?File "/home/zunzun/local/lib/python2.6/site- > packages/scipy/stats/distributions.py", >> > line 1987, in func >> > ? ?sk = 2*(b-a)*math.sqrt(a + b + 1) / (a + b + 2) / math.sqrt(a*b) >> > ValueError: math domain error >> > Traceback (most recent call last): >> > ?File "example.py", line 10, in >> > ? ?fitStart_beta = scipy.stats.beta._fitstart(data) >> > ?File "/home/zunzun/local/lib/python2.6/site- > packages/scipy/stats/distributions.py", >> > line 1992, in _fitstart >> > ? ?a, b = optimize.fsolve(func, (1.0, 1.0)) >> > ?File "/home/zunzun/local/lib/python2.6/site- > packages/scipy/optimize/minpack.py", >> > line 125, in fsolve >> > ? ?maxfev, ml, mu, epsfcn, factor, diag) >> > minpack.error: Error occured while calling the Python function named func >> > >> > and program flow is stopped. >> > >> > >> > In summary, three behaviors: (1) Fits OK (2) Many exceptions with no >> > fitting (3) minpack error. ?Running the program 10 times or so will >> > reproduce these behaviors without fail from the "bleeding-edge" >> > repository code. >> > >> > ? ? James Phillips >> > >> > >> > ######################################################## >> > >> > import numpy, scipy, scipy.stats >> > >> > # test uniform distribution fitting >> > data = numpy.random.uniform(2.0, 3.0, size=100) >> > fitStart_uniform = scipy.stats.uniform._fitstart(data) >> > fittedParameters_uniform = scipy.stats.uniform.fit(data) >> > >> > # test beta distribution fitting >> > data = numpy.random.beta(2.0, 3.0, size=100) >> > fitStart_beta = scipy.stats.beta._fitstart(data) >> > fittedParameters_beta = scipy.stats.beta.fit(data) >> > >> > print >> > print 'uniform._fitstart returns', fitStart_uniform >> > print 'fitted parameters for uniform =', fittedParameters_uniform >> > print >> > print 'beta._fitstart returns', fitStart_beta >> > print 'fitted parameters for beta =', fittedParameters_beta >> > print >> > _______________________________________________ >> >> Is there an existing bug ticket for this? ?If not there probably should be... >> >> I think the fitting code should be looked at as experimental. ?It's >> good that you caught that no fitting is actually done in these cases. >> The problem stems (for the most part) from bad starting values >> (outside the support of the distribution for those with bounded >> support). ?I've tried to go through and fix this, giving very naive >> (but correct) starting values to fit methods, but I haven't gotten >> much further than that. >> >> I don't know if Travis or Josef have gone back to look at this. >> Hopefully one of these days I will find some more time to look at this >> and try to give a systematic fix. >> >> Skipper >> > > > Hi, > I'm very sorry for entering the thread like this, but after a long search over > the web, this thread is the more relevant to my problem which I'm stuck with. > I'm actually trying to fit a gamma distribution on a set of experimental > values with gamma.fit() in scipy 0.8.0. Here is the very simple code I'm using > with a sample of my data: > > ########################## > import scipy as sp > import scipy.stats as ss > > exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] > data = sp.array(exp_data) > > fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) > print(fit_alpha,fit_loc,fit_beta) > ######################### > > I then receive many messages on the command line: > Warning: invalid value encountered in subtract > > Which ends with no fitting of the parameters: > (1.0, 0.0, 1.0) > > With earlier version of scipy (0.7.2), the error message are absent but still > no fitting is done. Apparently, it is the extrem value of "4500.3" that is > causing problem with the fitting in this case. > > I know you metionned earlier that the fitting code should be considered as > experimental, however I was wondering if this should be considered as a bug, > or if I'm making a mistake. In either case, is there a fix for the fit > method to work with a gamma distribution? > It looks like Josef's recent changes have got this working. Using the most recent trunk, so you might want to upgrade or see the changeset In [1]: import scipy as sp In [2]: import scipy.stats as ss In [3]: In [4]: exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] In [5]: data = sp.array(exp_data) In [6]: In [7]: fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) In [8]: print(fit_alpha, fit_loc, fit_beta) (0.37079887324711569, 25.599999999999998, 2459.7323873048508) Skipper From pav at iki.fi Thu Dec 9 15:29:39 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 9 Dec 2010 20:29:39 +0000 (UTC) Subject: [SciPy-Dev] fwrap refactor: What about complex -> real? References: <4D0129FC.4020603@student.matnat.uio.no> Message-ID: Thu, 09 Dec 2010 20:11:56 +0100, Dag Sverre Seljebotn wrote: > When faced with Fortran functions expecting a real scalar, f2py will > happily accept complex numbers and silently discard the imaginary part. > > Is this really the preferred behaviour? It would take quite a bit of > work to have fwrap behave like that, and I've heard occasional > complaints about the behaviour earlier (can't say I'm fond of it myself > either). IMHO, it's not a desired behavior. We are probably working towards addressing this issue in Numpy. Even the idea of disallowing implicit real->complex cast for Numpy 2.0 has been floated around. Personally, I don't see it worthwhile trying to emulate f2py here if it's not trivial. Scipy is not as frozen as Numpy anyway, so I believe changing this would not be a problem. > (Note that Python implements ".real" on float objects, so the fix is in > all cases trivial when this breaks things for people, one just appends > ".real" when calling the function, which should also increase the > readability of the code.) Yes, this is true. Also in this case explicit is better than implicit. -- Pauli Virtanen From charles.moliere at gmail.com Thu Dec 9 15:30:55 2010 From: charles.moliere at gmail.com (Charles Moliere) Date: Thu, 9 Dec 2010 15:30:55 -0500 Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example In-Reply-To: References: Message-ID: Thanks Skipper for the quick answer. I'm using scipy 0.8.0 with pydev and eclipse. So there is a newer version than 0.8.0? 2010/12/9 Skipper Seabold > On Thu, Dec 9, 2010 at 2:34 PM, Charles > wrote: > > Skipper Seabold gmail.com> writes: > > > >> > >> On Tue, Sep 28, 2010 at 1:12 PM, James Phillips zunzun.com > > > > wrote: > >> > Since I observed the following behavior in the SVN respository version > >> > of SciPy, it seemed to me proper to post to the dev mailing list. I'm > >> > using Ubuntu Lucid Lynx 32 bit and a fresh GIT of Numpy. I am not > >> > sure if a Trac bug report needs to be entered. > >> > > >> > > >> > Below is some example code for fitting two statistical distributions. > >> > Sometimes the numpy-generated data is fit, as I can see the estimated > >> > and fitted parameters are different. Sometimes I receive many > >> > messages repeated on the command line like: > >> > > >> > Warning: invalid value encountered in absolute > >> > Warning: invalid value encountered in subtract > >> > > >> > and the estimated parameters equal the fitted parameter values, > >> > indicating no fitting took place. Sometimes I receive on the command > >> > line: > >> > > >> > Traceback (most recent call last): > >> > File "/home/zunzun/local/lib/python2.6/site- > > packages/scipy/stats/distributions.py", > >> > line 1987, in func > >> > sk = 2*(b-a)*math.sqrt(a + b + 1) / (a + b + 2) / math.sqrt(a*b) > >> > ValueError: math domain error > >> > Traceback (most recent call last): > >> > File "example.py", line 10, in > >> > fitStart_beta = scipy.stats.beta._fitstart(data) > >> > File "/home/zunzun/local/lib/python2.6/site- > > packages/scipy/stats/distributions.py", > >> > line 1992, in _fitstart > >> > a, b = optimize.fsolve(func, (1.0, 1.0)) > >> > File "/home/zunzun/local/lib/python2.6/site- > > packages/scipy/optimize/minpack.py", > >> > line 125, in fsolve > >> > maxfev, ml, mu, epsfcn, factor, diag) > >> > minpack.error: Error occured while calling the Python function named > func > >> > > >> > and program flow is stopped. > >> > > >> > > >> > In summary, three behaviors: (1) Fits OK (2) Many exceptions with no > >> > fitting (3) minpack error. Running the program 10 times or so will > >> > reproduce these behaviors without fail from the "bleeding-edge" > >> > repository code. > >> > > >> > James Phillips > >> > > >> > > >> > ######################################################## > >> > > >> > import numpy, scipy, scipy.stats > >> > > >> > # test uniform distribution fitting > >> > data = numpy.random.uniform(2.0, 3.0, size=100) > >> > fitStart_uniform = scipy.stats.uniform._fitstart(data) > >> > fittedParameters_uniform = scipy.stats.uniform.fit(data) > >> > > >> > # test beta distribution fitting > >> > data = numpy.random.beta(2.0, 3.0, size=100) > >> > fitStart_beta = scipy.stats.beta._fitstart(data) > >> > fittedParameters_beta = scipy.stats.beta.fit(data) > >> > > >> > print > >> > print 'uniform._fitstart returns', fitStart_uniform > >> > print 'fitted parameters for uniform =', fittedParameters_uniform > >> > print > >> > print 'beta._fitstart returns', fitStart_beta > >> > print 'fitted parameters for beta =', fittedParameters_beta > >> > print > >> > _______________________________________________ > >> > >> Is there an existing bug ticket for this? If not there probably should > be... > >> > >> I think the fitting code should be looked at as experimental. It's > >> good that you caught that no fitting is actually done in these cases. > >> The problem stems (for the most part) from bad starting values > >> (outside the support of the distribution for those with bounded > >> support). I've tried to go through and fix this, giving very naive > >> (but correct) starting values to fit methods, but I haven't gotten > >> much further than that. > >> > >> I don't know if Travis or Josef have gone back to look at this. > >> Hopefully one of these days I will find some more time to look at this > >> and try to give a systematic fix. > >> > >> Skipper > >> > > > > > > Hi, > > I'm very sorry for entering the thread like this, but after a long search > over > > the web, this thread is the more relevant to my problem which I'm stuck > with. > > I'm actually trying to fit a gamma distribution on a set of experimental > > values with gamma.fit() in scipy 0.8.0. Here is the very simple code I'm > using > > with a sample of my data: > > > > ########################## > > import scipy as sp > > import scipy.stats as ss > > > > exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] > > data = sp.array(exp_data) > > > > fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) > > print(fit_alpha,fit_loc,fit_beta) > > ######################### > > > > I then receive many messages on the command line: > > Warning: invalid value encountered in subtract > > > > Which ends with no fitting of the parameters: > > (1.0, 0.0, 1.0) > > > > With earlier version of scipy (0.7.2), the error message are absent but > still > > no fitting is done. Apparently, it is the extrem value of "4500.3" that > is > > causing problem with the fitting in this case. > > > > I know you metionned earlier that the fitting code should be considered > as > > experimental, however I was wondering if this should be considered as a > bug, > > or if I'm making a mistake. In either case, is there a fix for the fit > > method to work with a gamma distribution? > > > > It looks like Josef's recent changes have got this working. Using the > most recent trunk, so you might want to upgrade or see the changeset > > In [1]: import scipy as sp > > In [2]: import scipy.stats as ss > > In [3]: > > In [4]: exp_data > =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] > > In [5]: data = sp.array(exp_data) > > In [6]: > > In [7]: fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) > > In [8]: print(fit_alpha, fit_loc, fit_beta) > (0.37079887324711569, 25.599999999999998, 2459.7323873048508) > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsseabold at gmail.com Thu Dec 9 15:36:00 2010 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 9 Dec 2010 15:36:00 -0500 Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example In-Reply-To: References: Message-ID: On Thu, Dec 9, 2010 at 3:30 PM, Charles Moliere wrote: > Thanks Skipper for the quick answer.?I'm using scipy 0.8.0 with pydev and > eclipse.?So there is a newer version than 0.8.0? > You can get the development version and install it yourself. http://www.scipy.org/Download#head-d0ec9f4cfbf6ed3029a2c409b6d9899586eee0e3 I think 0.9 is to be released fairly soon (?) if you want to wait for an official release. Skipper From josef.pktd at gmail.com Thu Dec 9 15:53:38 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 9 Dec 2010 15:53:38 -0500 Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example In-Reply-To: References: Message-ID: On Thu, Dec 9, 2010 at 3:12 PM, Skipper Seabold wrote: > On Thu, Dec 9, 2010 at 2:34 PM, Charles wrote: >> Skipper Seabold gmail.com> writes: >> >>> >>> On Tue, Sep 28, 2010 at 1:12 PM, James Phillips zunzun.com> >> wrote: >>> > Since I observed the following behavior in the SVN respository version >>> > of SciPy, it seemed to me proper to post to the dev mailing list. ?I'm >>> > using Ubuntu Lucid Lynx 32 bit and a fresh GIT of Numpy. ?I am not >>> > sure if a Trac bug report needs to be entered. >>> > >>> > >>> > Below is some example code for fitting two statistical distributions. >>> > Sometimes the numpy-generated data is fit, as I can see the estimated >>> > and fitted parameters are different. ?Sometimes I receive many >>> > messages repeated on the command line like: >>> > >>> > Warning: invalid value encountered in absolute >>> > Warning: invalid value encountered in subtract >>> > >>> > and the estimated parameters equal the fitted parameter values, >>> > indicating no fitting took place. ?Sometimes I receive on the command >>> > line: >>> > >>> > Traceback (most recent call last): >>> > ?File "/home/zunzun/local/lib/python2.6/site- >> packages/scipy/stats/distributions.py", >>> > line 1987, in func >>> > ? ?sk = 2*(b-a)*math.sqrt(a + b + 1) / (a + b + 2) / math.sqrt(a*b) >>> > ValueError: math domain error >>> > Traceback (most recent call last): >>> > ?File "example.py", line 10, in >>> > ? ?fitStart_beta = scipy.stats.beta._fitstart(data) >>> > ?File "/home/zunzun/local/lib/python2.6/site- >> packages/scipy/stats/distributions.py", >>> > line 1992, in _fitstart >>> > ? ?a, b = optimize.fsolve(func, (1.0, 1.0)) >>> > ?File "/home/zunzun/local/lib/python2.6/site- >> packages/scipy/optimize/minpack.py", >>> > line 125, in fsolve >>> > ? ?maxfev, ml, mu, epsfcn, factor, diag) >>> > minpack.error: Error occured while calling the Python function named func >>> > >>> > and program flow is stopped. >>> > >>> > >>> > In summary, three behaviors: (1) Fits OK (2) Many exceptions with no >>> > fitting (3) minpack error. ?Running the program 10 times or so will >>> > reproduce these behaviors without fail from the "bleeding-edge" >>> > repository code. >>> > >>> > ? ? James Phillips >>> > >>> > >>> > ######################################################## >>> > >>> > import numpy, scipy, scipy.stats >>> > >>> > # test uniform distribution fitting >>> > data = numpy.random.uniform(2.0, 3.0, size=100) >>> > fitStart_uniform = scipy.stats.uniform._fitstart(data) >>> > fittedParameters_uniform = scipy.stats.uniform.fit(data) >>> > >>> > # test beta distribution fitting >>> > data = numpy.random.beta(2.0, 3.0, size=100) >>> > fitStart_beta = scipy.stats.beta._fitstart(data) >>> > fittedParameters_beta = scipy.stats.beta.fit(data) >>> > >>> > print >>> > print 'uniform._fitstart returns', fitStart_uniform >>> > print 'fitted parameters for uniform =', fittedParameters_uniform >>> > print >>> > print 'beta._fitstart returns', fitStart_beta >>> > print 'fitted parameters for beta =', fittedParameters_beta >>> > print >>> > _______________________________________________ >>> >>> Is there an existing bug ticket for this? ?If not there probably should be... >>> >>> I think the fitting code should be looked at as experimental. ?It's >>> good that you caught that no fitting is actually done in these cases. >>> The problem stems (for the most part) from bad starting values >>> (outside the support of the distribution for those with bounded >>> support). ?I've tried to go through and fix this, giving very naive >>> (but correct) starting values to fit methods, but I haven't gotten >>> much further than that. >>> >>> I don't know if Travis or Josef have gone back to look at this. >>> Hopefully one of these days I will find some more time to look at this >>> and try to give a systematic fix. >>> >>> Skipper >>> >> >> >> Hi, >> I'm very sorry for entering the thread like this, but after a long search over >> the web, this thread is the more relevant to my problem which I'm stuck with. >> I'm actually trying to fit a gamma distribution on a set of experimental >> values with gamma.fit() in scipy 0.8.0. Here is the very simple code I'm using >> with a sample of my data: >> >> ########################## >> import scipy as sp >> import scipy.stats as ss >> >> exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] >> data = sp.array(exp_data) >> >> fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) >> print(fit_alpha,fit_loc,fit_beta) >> ######################### >> >> I then receive many messages on the command line: >> Warning: invalid value encountered in subtract >> >> Which ends with no fitting of the parameters: >> (1.0, 0.0, 1.0) >> >> With earlier version of scipy (0.7.2), the error message are absent but still >> no fitting is done. Apparently, it is the extrem value of "4500.3" that is >> causing problem with the fitting in this case. >> >> I know you metionned earlier that the fitting code should be considered as >> experimental, however I was wondering if this should be considered as a bug, >> or if I'm making a mistake. In either case, is there a fix for the fit >> method to work with a gamma distribution? >> > > It looks like Josef's recent changes have got this working. ?Using the > most recent trunk, so you might want to upgrade or see the changeset I don't remember any changes, but in this case choosing the right starting values will be important, and the default ones might work with one scipy version but with an other. I think the warnings mean that the starting values don't make much sense and the likelihood is evaluated at "bad" places Josef > > In [1]: import scipy as sp > > In [2]: import scipy.stats as ss > > In [3]: > > In [4]: exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] > > In [5]: data = sp.array(exp_data) > > In [6]: > > In [7]: fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) > > In [8]: print(fit_alpha, fit_loc, fit_beta) > (0.37079887324711569, 25.599999999999998, 2459.7323873048508) > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From jsseabold at gmail.com Thu Dec 9 15:59:35 2010 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 9 Dec 2010 15:59:35 -0500 Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example In-Reply-To: References: Message-ID: On Thu, Dec 9, 2010 at 3:53 PM, wrote: > On Thu, Dec 9, 2010 at 3:12 PM, Skipper Seabold wrote: >> On Thu, Dec 9, 2010 at 2:34 PM, Charles wrote: >>> >>> Hi, >>> I'm very sorry for entering the thread like this, but after a long search over >>> the web, this thread is the more relevant to my problem which I'm stuck with. >>> I'm actually trying to fit a gamma distribution on a set of experimental >>> values with gamma.fit() in scipy 0.8.0. Here is the very simple code I'm using >>> with a sample of my data: >>> >>> ########################## >>> import scipy as sp >>> import scipy.stats as ss >>> >>> exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] >>> data = sp.array(exp_data) >>> >>> fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) >>> print(fit_alpha,fit_loc,fit_beta) >>> ######################### >>> >>> I then receive many messages on the command line: >>> Warning: invalid value encountered in subtract >>> >>> Which ends with no fitting of the parameters: >>> (1.0, 0.0, 1.0) >>> >>> With earlier version of scipy (0.7.2), the error message are absent but still >>> no fitting is done. Apparently, it is the extrem value of "4500.3" that is >>> causing problem with the fitting in this case. >>> >>> I know you metionned earlier that the fitting code should be considered as >>> experimental, however I was wondering if this should be considered as a bug, >>> or if I'm making a mistake. In either case, is there a fix for the fit >>> method to work with a gamma distribution? >>> >> >> It looks like Josef's recent changes have got this working. ?Using the >> most recent trunk, so you might want to upgrade or see the changeset > > I don't remember any changes, but in this case choosing the right > starting values will be important, and the default ones might work > with one scipy version but with an other. > Ah, well I had an older trunk installed on this machine and got the same as the OP. I updated and then it worked (ie., returned something)... Skipper From josef.pktd at gmail.com Thu Dec 9 16:20:39 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 9 Dec 2010 16:20:39 -0500 Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example In-Reply-To: References: Message-ID: On Thu, Dec 9, 2010 at 3:59 PM, Skipper Seabold wrote: > On Thu, Dec 9, 2010 at 3:53 PM, ? wrote: >> On Thu, Dec 9, 2010 at 3:12 PM, Skipper Seabold wrote: >>> On Thu, Dec 9, 2010 at 2:34 PM, Charles wrote: >>>> >>>> Hi, >>>> I'm very sorry for entering the thread like this, but after a long search over >>>> the web, this thread is the more relevant to my problem which I'm stuck with. >>>> I'm actually trying to fit a gamma distribution on a set of experimental >>>> values with gamma.fit() in scipy 0.8.0. Here is the very simple code I'm using >>>> with a sample of my data: >>>> >>>> ########################## >>>> import scipy as sp >>>> import scipy.stats as ss >>>> >>>> exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] >>>> data = sp.array(exp_data) >>>> >>>> fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) >>>> print(fit_alpha,fit_loc,fit_beta) >>>> ######################### >>>> >>>> I then receive many messages on the command line: >>>> Warning: invalid value encountered in subtract >>>> >>>> Which ends with no fitting of the parameters: >>>> (1.0, 0.0, 1.0) >>>> >>>> With earlier version of scipy (0.7.2), the error message are absent but still >>>> no fitting is done. Apparently, it is the extrem value of "4500.3" that is >>>> causing problem with the fitting in this case. >>>> >>>> I know you metionned earlier that the fitting code should be considered as >>>> experimental, however I was wondering if this should be considered as a bug, >>>> or if I'm making a mistake. In either case, is there a fix for the fit >>>> method to work with a gamma distribution? >>>> >>> >>> It looks like Josef's recent changes have got this working. ?Using the >>> most recent trunk, so you might want to upgrade or see the changeset >> >> I don't remember any changes, but in this case choosing the right >> starting values will be important, and the default ones might work >> with one scipy version but with an other. >> > > Ah, well I had an older trunk installed on this machine and got the > same as the OP. ?I updated and then it worked (ie., returned > something)... with the version I have: >>> stats.gamma._fitstart([25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3]) (0.56777181998920023, -422.95393359547484, 1742.449869411083) >>> stats.gamma.fit([25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3]) (0.37079853616614639, 25.599999999999998, 2459.7325273317128) Charles, you could try starting parameters like (0.5, 0.0, 2000) and see if this works. I still haven't looked at all the changes in the fit Josef > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From charles.moliere at gmail.com Thu Dec 9 16:44:39 2010 From: charles.moliere at gmail.com (Charles Moliere) Date: Thu, 9 Dec 2010 16:44:39 -0500 Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example In-Reply-To: References: Message-ID: 2010/12/9 > On Thu, Dec 9, 2010 at 3:59 PM, Skipper Seabold > wrote: > > On Thu, Dec 9, 2010 at 3:53 PM, wrote: > >> On Thu, Dec 9, 2010 at 3:12 PM, Skipper Seabold > wrote: > >>> On Thu, Dec 9, 2010 at 2:34 PM, Charles > wrote: > >>>> > >>>> Hi, > >>>> I'm very sorry for entering the thread like this, but after a long > search over > >>>> the web, this thread is the more relevant to my problem which I'm > stuck with. > >>>> I'm actually trying to fit a gamma distribution on a set of > experimental > >>>> values with gamma.fit() in scipy 0.8.0. Here is the very simple code > I'm using > >>>> with a sample of my data: > >>>> > >>>> ########################## > >>>> import scipy as sp > >>>> import scipy.stats as ss > >>>> > >>>> exp_data =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] > >>>> data = sp.array(exp_data) > >>>> > >>>> fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) > >>>> print(fit_alpha,fit_loc,fit_beta) > >>>> ######################### > >>>> > >>>> I then receive many messages on the command line: > >>>> Warning: invalid value encountered in subtract > >>>> > >>>> Which ends with no fitting of the parameters: > >>>> (1.0, 0.0, 1.0) > >>>> > >>>> With earlier version of scipy (0.7.2), the error message are absent > but still > >>>> no fitting is done. Apparently, it is the extrem value of "4500.3" > that is > >>>> causing problem with the fitting in this case. > >>>> > >>>> I know you metionned earlier that the fitting code should be > considered as > >>>> experimental, however I was wondering if this should be considered as > a bug, > >>>> or if I'm making a mistake. In either case, is there a fix for the fit > >>>> method to work with a gamma distribution? > >>>> > >>> > >>> It looks like Josef's recent changes have got this working. Using the > >>> most recent trunk, so you might want to upgrade or see the changeset > >> > >> I don't remember any changes, but in this case choosing the right > >> starting values will be important, and the default ones might work > >> with one scipy version but with an other. > >> > > > > Ah, well I had an older trunk installed on this machine and got the > > same as the OP. I updated and then it worked (ie., returned > > something)... > > with the version I have: > > >>> > stats.gamma._fitstart([25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3]) > (0.56777181998920023, -422.95393359547484, 1742.449869411083) > > >>> > stats.gamma.fit([25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3]) > (0.37079853616614639, 25.599999999999998, 2459.7325273317128) > > Charles, > you could try starting parameters like (0.5, 0.0, 2000) and see if this > works. > > I still haven't looked at all the changes in the fit > > Josef > > > > > Skipper > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > Thanks a lot for your help to you both. I haven't found any documentation about _fitstart(). Is it a new fitting that uses the data to choose the starting parameters (as mentioned in ticket#808 http://projects.scipy.org/scipy/ticket/808)? In this case, is it available in the new trunk or in 0.9.0? I also noticed you are both using 64bits, perhaps it could have an effect on the convergence of the fitting? I apologize for all the questions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.moliere at gmail.com Thu Dec 9 16:59:48 2010 From: charles.moliere at gmail.com (Charles Moliere) Date: Thu, 9 Dec 2010 16:59:48 -0500 Subject: [SciPy-Dev] Subversion scipy.stats irregular problem with source code example In-Reply-To: References: Message-ID: 2010/12/9 Charles Moliere > > > 2010/12/9 > > On Thu, Dec 9, 2010 at 3:59 PM, Skipper Seabold >> wrote: >> > On Thu, Dec 9, 2010 at 3:53 PM, wrote: >> >> On Thu, Dec 9, 2010 at 3:12 PM, Skipper Seabold >> wrote: >> >>> On Thu, Dec 9, 2010 at 2:34 PM, Charles >> wrote: >> >>>> >> >>>> Hi, >> >>>> I'm very sorry for entering the thread like this, but after a long >> search over >> >>>> the web, this thread is the more relevant to my problem which I'm >> stuck with. >> >>>> I'm actually trying to fit a gamma distribution on a set of >> experimental >> >>>> values with gamma.fit() in scipy 0.8.0. Here is the very simple code >> I'm using >> >>>> with a sample of my data: >> >>>> >> >>>> ########################## >> >>>> import scipy as sp >> >>>> import scipy.stats as ss >> >>>> >> >>>> exp_data >> =[25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3] >> >>>> data = sp.array(exp_data) >> >>>> >> >>>> fit_alpha, fit_loc, fit_beta = ss.gamma.fit(data) >> >>>> print(fit_alpha,fit_loc,fit_beta) >> >>>> ######################### >> >>>> >> >>>> I then receive many messages on the command line: >> >>>> Warning: invalid value encountered in subtract >> >>>> >> >>>> Which ends with no fitting of the parameters: >> >>>> (1.0, 0.0, 1.0) >> >>>> >> >>>> With earlier version of scipy (0.7.2), the error message are absent >> but still >> >>>> no fitting is done. Apparently, it is the extrem value of "4500.3" >> that is >> >>>> causing problem with the fitting in this case. >> >>>> >> >>>> I know you metionned earlier that the fitting code should be >> considered as >> >>>> experimental, however I was wondering if this should be considered as >> a bug, >> >>>> or if I'm making a mistake. In either case, is there a fix for the >> fit >> >>>> method to work with a gamma distribution? >> >>>> >> >>> >> >>> It looks like Josef's recent changes have got this working. Using the >> >>> most recent trunk, so you might want to upgrade or see the changeset >> >> >> >> I don't remember any changes, but in this case choosing the right >> >> starting values will be important, and the default ones might work >> >> with one scipy version but with an other. >> >> >> > >> > Ah, well I had an older trunk installed on this machine and got the >> > same as the OP. I updated and then it worked (ie., returned >> > something)... >> >> with the version I have: >> >> >>> >> stats.gamma._fitstart([25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3]) >> (0.56777181998920023, -422.95393359547484, 1742.449869411083) >> >> >>> >> stats.gamma.fit([25.6,35.8,100.2,115.2,125.2,140.1,160.6,210.1,250.5,4500.3]) >> (0.37079853616614639, 25.599999999999998, 2459.7325273317128) >> >> Charles, >> you could try starting parameters like (0.5, 0.0, 2000) and see if this >> works. >> >> I still haven't looked at all the changes in the fit >> >> Josef >> >> > >> > Skipper >> > _______________________________________________ >> > SciPy-Dev mailing list >> > SciPy-Dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/scipy-dev >> > >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> > > > Thanks a lot for your help to you both. > > I haven't found any documentation about _fitstart(). Is it a new fitting > that uses the data to choose the starting parameters (as mentioned in > ticket#808 http://projects.scipy.org/scipy/ticket/808)? In this case, is > it available in the new trunk or in 0.9.0? > > I also noticed you are both using 64bits, perhaps it could have an effect > on the convergence of the fitting? > > I apologize for all the questions. > Got my answer: http://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.rv_continuous.fit.html It is in 0.9.x. Then I'll have to wait for the release as i'm not familiar with compiling. Many thanks again! -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliphant at enthought.com Thu Dec 9 17:02:38 2010 From: oliphant at enthought.com (Travis Oliphant) Date: Thu, 9 Dec 2010 16:02:38 -0600 Subject: [SciPy-Dev] fwrap refactor: What about complex -> real? In-Reply-To: References: <4D0129FC.4020603@student.matnat.uio.no> Message-ID: +1 -- (mobile phone of) Travis Oliphant Enthought, Inc. 1-512-536-1057 http://www.enthought.com On Dec 9, 2010, at 2:29 PM, Pauli Virtanen wrote: > Thu, 09 Dec 2010 20:11:56 +0100, Dag Sverre Seljebotn wrote: >> When faced with Fortran functions expecting a real scalar, f2py will >> happily accept complex numbers and silently discard the imaginary part. >> >> Is this really the preferred behaviour? It would take quite a bit of >> work to have fwrap behave like that, and I've heard occasional >> complaints about the behaviour earlier (can't say I'm fond of it myself >> either). > > IMHO, it's not a desired behavior. We are probably working towards > addressing this issue in Numpy. Even the idea of disallowing implicit > real->complex cast for Numpy 2.0 has been floated around. > > Personally, I don't see it worthwhile trying to emulate f2py here if it's > not trivial. Scipy is not as frozen as Numpy anyway, so I believe > changing this would not be a problem. > >> (Note that Python implements ".real" on float objects, so the fix is in >> all cases trivial when this breaks things for people, one just appends >> ".real" when calling the function, which should also increase the >> readability of the code.) > > Yes, this is true. Also in this case explicit is better than implicit. > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From ben.root at ou.edu Fri Dec 10 17:54:45 2010 From: ben.root at ou.edu (Benjamin Root) Date: Fri, 10 Dec 2010 16:54:45 -0600 Subject: [SciPy-Dev] Bug in KDTree Message-ID: Hello, I came across an issue using KDTree. I searched the bug list, and it appears that there has already been a patch submitted for review. I have added comments to the bug report and I think the patch is good to go. I am not an expert in KDTree myself, but I think the logic is sound. http://projects.scipy.org/scipy/ticket/1052 If the first node of the tree is a leafnode, then query_pairs() will fail if the points are closer than the distance threshold. This is because the algorithm is assuming that the first node will always be an innernode. By rearranging the if-statements so that a check for a leafnode is done first, you protect against such a situation. At least, that is my understanding. I welcome comments on this. Thanks, Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at vincentdavis.net Sun Dec 12 23:08:23 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Sun, 12 Dec 2010 21:08:23 -0700 Subject: [SciPy-Dev] error in scipy 9.0b1 build, not sure what test fails (maybe stupid question) Message-ID: Ok so maybe this is a stupid question but I am not sure how to know what scipy test is failing from this error. (numpy.test('full') runs clean) >>> scipy.test(verbose=2) Running unit tests for scipy NumPy version 1.5.1 NumPy is installed in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy SciPy version 0.9.0b1 SciPy is installed in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy Python version 2.7.1 (r271:86882M, Nov 30 2010, 09:39:13) [GCC 4.0.1 (Apple Inc. build 5494)] nose version 0.10.4 test_linkage_cophenet_tdist_Z (test_hierarchy.TestCopheneticDistance) Tests cophenet(Z) on tdist data set. ... ok Need to import PIL for this test test_imresize3 (test_pilutil.TestPILUtil) ... SKIP: Skipping test: test_imresize3 Need to import PIL for this test Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/nosetester.py", line 327, in test t = NumpyTestProgram(argv=argv, exit=False, plugins=plugins) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/core.py", line 219, in __init__ argv=argv, testRunner=testRunner, testLoader=testLoader) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/main.py", line 95, in __init__ self.runTests() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/noseclasses.py", line 349, in runTests self.result = self.testRunner.run(self.test) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/core.py", line 62, in run test(result) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 138, in __call__ return self.run(*arg, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 168, in run test(orig) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 138, in __call__ return self.run(*arg, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 168, in run test(orig) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 138, in __call__ return self.run(*arg, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 168, in run test(orig) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 138, in __call__ return self.run(*arg, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 168, in run test(orig) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 138, in __call__ return self.run(*arg, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 168, in run test(orig) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 138, in __call__ return self.run(*arg, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 158, in run result.addError(self, self.exc_info()) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/proxy.py", line 112, in addError self.assertMyTest(test) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/proxy.py", line 97, in assertMyTest % (self.test, id(self.test), test, id(test))) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/suite.py", line 129, in __repr__ unittest._strclass(self.__class__), AttributeError: 'module' object has no attribute '_strclass' -- Thanks Vincent Davis 720-301-3003 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Dec 13 11:12:32 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 14 Dec 2010 00:12:32 +0800 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 Message-ID: Hi, I am pleased to announce the availability of the first beta of SciPy 0.9.0. This will be the first SciPy release to include support for Python 3, as well as for Python 2.7. Please try this beta and report any problems on the scipy-dev mailing list. Binaries, sources and release notes can be found athttp://sourceforge.net/projects/scipy/files/scipy/0.9.0b1/. Note that not all binaries (win32-py27, *-macosx10.3) are uploaded yet, they will follow in the next day or two. There are still a few known issues (so no need to report these): 1. Arpack related errors on 64-bit OS X. 2. Correlate complex192 errors on Windows. 3. correlate/conjugate current behavior is deprecated and should be removed before RC1. Enjoy, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Dec 13 11:46:22 2010 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 13 Dec 2010 16:46:22 +0000 (UTC) Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 References: Message-ID: Tue, 14 Dec 2010 00:12:32 +0800, Ralf Gommers wrote: > I am pleased to announce the availability of the first beta of SciPy > 0.9.0. This will be the first SciPy release to include support for > Python 3, as well as for Python 2.7. Note: scipy.weave does not work on Python 3 yet; the other parts of Scipy do. -- Pauli Virtanen From ben.root at ou.edu Mon Dec 13 11:43:44 2010 From: ben.root at ou.edu (Benjamin Root) Date: Mon, 13 Dec 2010 10:43:44 -0600 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Mon, Dec 13, 2010 at 10:12 AM, Ralf Gommers wrote: > Hi, > > I am pleased to announce the availability of the first beta of SciPy 0.9.0. > This will be the first SciPy release to include support for Python 3, as > well as for Python 2.7. Please try this beta and report any problems on > the scipy-dev mailing list. > > Binaries, sources and release notes can be found athttp://sourceforge.net/projects/scipy/files/scipy/0.9.0b1/. > Note that not all binaries (win32-py27, *-macosx10.3) are uploaded yet, they > will follow in the next day or two. > > There are still a few known issues (so no need to report these): > 1. Arpack related errors on 64-bit OS X. > 2. Correlate complex192 errors on Windows. > 3. correlate/conjugate current behavior is deprecated and should be removed > before RC1. > > Enjoy, > Ralf > > Just did a clean rebuild (after a clean rebuild of numpy) and had two errors in the tests: ====================================================================== FAIL: test_imresize (test_pilutil.TestPILUtil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line 25, in test_imresize assert_equal(im1.shape,(11,22)) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=0 ACTUAL: 10 DESIRED: 11 ====================================================================== FAIL: test_basic (test_signaltools.TestMedFilt) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bvr/Programs/scipy/scipy/signal/tests/test_signaltools.py", line 284, in test_basic [ 0, 7, 11, 7, 4, 4, 19, 19, 24, 0]]) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 686, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 618, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 8.0%) x: array([[ 0., 50., 50., 50., 42., 15., 15., 18., 27., 0.], [ 0., 50., 50., 50., 50., 42., 19., 21., 29., 0.], [ 50., 50., 50., 50., 50., 47., 34., 34., 46., 35.],... y: array([[ 0, 50, 50, 50, 42, 15, 15, 18, 27, 0], [ 0, 50, 50, 50, 50, 42, 19, 21, 29, 0], [50, 50, 50, 50, 50, 47, 34, 34, 46, 35],... ---------------------------------------------------------------------- Ran 4822 tests in 199.244s FAILED (KNOWNFAIL=12, SKIP=35, failures=2) Don't know about the first one, but the second one looks like a type-casting issue, because all the values are the same, except one is floating point and the other is integer. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgohlke at uci.edu Mon Dec 13 13:18:13 2010 From: cgohlke at uci.edu (Christoph Gohlke) Date: Mon, 13 Dec 2010 10:18:13 -0800 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: <4D066365.5090104@uci.edu> On 12/13/2010 8:12 AM, Ralf Gommers wrote: > Hi, > > I am pleased to announce the availability of the first beta of SciPy > 0.9.0. This will be the first SciPy release to include support for > Python 3, as well as for Python 2.7. Please try this beta and report any > problems on the scipy-dev mailing list. > > Binaries, sources and release notes can be found > athttp://sourceforge.net/projects/scipy/files/scipy/0.9.0b1/ > . Note that not all > binaries (win32-py27, *-macosx10.3) are uploaded yet, they will follow > in the next day or two. > > There are still a few known issues (so no need to report these): > 1. Arpack related errors on 64-bit OS X. > 2. Correlate complex192 errors on Windows. > 3. correlate/conjugate current behavior is deprecated and should be > removed before RC1. > > Enjoy, > Ralf > > Thank you! I ran into the following issues with scipy 0.9.0b1 on Windows when building with msvc 9 and intel 11.1 compilers. Numpy is version 1.5.1, linked against MKL. 1) after patching some source files and setup scripts (see msvc9.diff attachment), "python setup.py bdist_winist" succeeds on 32- and 64-bit Python 2.6, 2.7, and 3.1. The Visual C compiler reproducibly crashes while compiling scipy\special\cephes\ndtr.c. Running the build command again (without cleaning the build directory) seems to work. 2) the build process fails on Python 3.2b1 with the following errors: scipy\sparse\sparsetools\csr_wrap.cxx(2451) : error C3861: 'PyCObject_Import': identifier not found scipy\sparse\sparsetools\csr_wrap.cxx(2521) : error C3861: 'PyCObject_FromVoidPtr': identifier not found scipy\sparse\sparsetools\csr_wrap.cxx(2544) : error C3861: 'PyCObject_AsVoidPtr': identifier not found 3) 32-bit Python 2.6 is the only platform where scipy.test() finishes; albeit with 32 failures. Besides the Correlate complex192 and TestODR errors (http://projects.scipy.org/scipy/ticket/678) I get FAIL: Real-valued Bessel domains ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python26\lib\site-packages\scipy\special\tests\test_basic.py", line 1704, in test_ticket_854 assert_(not isnan(special.airye(-1)[2:4]).any(), special.airye(-1)) File "X:\Python26\lib\site-packages\numpy\testing\utils.py", line 34, in assert_ raise AssertionError(msg) AssertionError: (nan, nan, nan, nan) 4) scipy.test() on Python 2.7 and 3.1 crashes as reported in ticket #1210 5) On 64 bit platforms, scipy.test() quits at the following test test_interpnd.TestCloughTocher2DInterpolator.test_dense ... QH6084 qhull internal error (qh_meminit): sizeof(void*) 8 > sizeof(ptr_intT) 4. Change ptr_intT in mem.h to 'long long' -- Christoph -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvc9.diff URL: From pav at iki.fi Mon Dec 13 16:43:21 2010 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 13 Dec 2010 21:43:21 +0000 (UTC) Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 References: <4D066365.5090104@uci.edu> Message-ID: On Mon, 13 Dec 2010 10:18:13 -0800, Christoph Gohlke wrote: [clip] > I ran into the following issues with scipy 0.9.0b1 on Windows when > building with msvc 9 and intel 11.1 compilers. Numpy is version 1.5.1, > linked against MKL. > > 1) after patching some source files and setup scripts (see msvc9.diff > attachment), "python setup.py bdist_winist" succeeds on 32- and 64-bit > Python 2.6, 2.7, and 3.1. The Visual C compiler reproducibly crashes > while compiling scipy\special\cephes\ndtr.c. Running the build command > again (without cleaning the build directory) seems to work. Some of that patch should end up in the tree? I'm not sure which parts, though. [clip] > 2) the build process fails on Python 3.2b1 with the following errors: > > scipy\sparse\sparsetools\csr_wrap.cxx(2451) : error C3861: > 'PyCObject_Import': identifier not found > scipy\sparse\sparsetools\csr_wrap.cxx(2521) : error C3861: > 'PyCObject_FromVoidPtr': identifier not found > scipy\sparse\sparsetools\csr_wrap.cxx(2544) : error C3861: > 'PyCObject_AsVoidPtr': identifier not found It seems that the version of SWIG used there is not compatible with Python 3.2. > 3) 32-bit Python 2.6 is the only platform where scipy.test() finishes; > albeit with 32 failures. Besides the Correlate complex192 and TestODR > errors (http://projects.scipy.org/scipy/ticket/678) I get [clip] > FAIL: Real-valued Bessel domains [clip] > AssertionError: (nan, nan, nan, nan) This indicates some issue with AMOS and ifort. What do you get from import warnings, scipy.special as sc warnings.simplefilter('always', sc.SpecialFunctionWarning) sc.errprint(1) sc.airye(-1) It's possible that the test is too strict. > 4) scipy.test() on Python 2.7 and 3.1 crashes as reported in ticket > #1210 This smells like something triggering a DeprecationWarning when GIL is released. If so, it should be compiler independent and reproducible on wine+mingw. Or, some PyCObject/PyCapsule issue. > 5) On 64 bit platforms, scipy.test() quits at the following test > > test_interpnd.TestCloughTocher2DInterpolator.test_dense ... QH6084 qhull > internal error (qh_meminit): sizeof(void*) 8 > sizeof(ptr_intT) 4. > Change ptr_intT in mem.h to 'long long' Should be fixed in r7013 -- Pauli Virtanen From cgohlke at uci.edu Mon Dec 13 17:21:13 2010 From: cgohlke at uci.edu (Christoph Gohlke) Date: Mon, 13 Dec 2010 14:21:13 -0800 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: <4D066365.5090104@uci.edu> Message-ID: <4D069C59.4000003@uci.edu> On 12/13/2010 1:43 PM, Pauli Virtanen wrote: > On Mon, 13 Dec 2010 10:18:13 -0800, Christoph Gohlke wrote: > [clip] >> I ran into the following issues with scipy 0.9.0b1 on Windows when >> building with msvc 9 and intel 11.1 compilers. Numpy is version 1.5.1, >> linked against MKL. >> >> 1) after patching some source files and setup scripts (see msvc9.diff >> attachment), "python setup.py bdist_winist" succeeds on 32- and 64-bit >> Python 2.6, 2.7, and 3.1. The Visual C compiler reproducibly crashes >> while compiling scipy\special\cephes\ndtr.c. Running the build command >> again (without cleaning the build directory) seems to work. > > Some of that patch should end up in the tree? I'm not sure which parts, > though. The patch can not be applied as is. It is a quick hack to get scipy compiling with msvc9/ifort again and likely breaks things in other build environments. I can open tickets later. > > [clip] >> 2) the build process fails on Python 3.2b1 with the following errors: >> >> scipy\sparse\sparsetools\csr_wrap.cxx(2451) : error C3861: >> 'PyCObject_Import': identifier not found >> scipy\sparse\sparsetools\csr_wrap.cxx(2521) : error C3861: >> 'PyCObject_FromVoidPtr': identifier not found >> scipy\sparse\sparsetools\csr_wrap.cxx(2544) : error C3861: >> 'PyCObject_AsVoidPtr': identifier not found > > It seems that the version of SWIG used there is not compatible with > Python 3.2. Yes, see SWIG bug #3057804 "[Python] wrapper does not compile with python 3.2" > >> 3) 32-bit Python 2.6 is the only platform where scipy.test() finishes; >> albeit with 32 failures. Besides the Correlate complex192 and TestODR >> errors (http://projects.scipy.org/scipy/ticket/678) I get > [clip] >> FAIL: Real-valued Bessel domains > [clip] >> AssertionError: (nan, nan, nan, nan) > > This indicates some issue with AMOS and ifort. What do you get from > > import warnings, scipy.special as sc > warnings.simplefilter('always', sc.SpecialFunctionWarning) > sc.errprint(1) 0 > sc.airye(-1) __main__:1: SpecialFunctionWarning: airye:: unknown error __main__:1: SpecialFunctionWarning: airye:: unknown error (nan, nan, 0.10399738949694459, 0.59237562642279229) > > It's possible that the test is too strict. > >> 4) scipy.test() on Python 2.7 and 3.1 crashes as reported in ticket >> #1210 > > This smells like something triggering a DeprecationWarning when GIL is > released. If so, it should be compiler independent and reproducible on > wine+mingw. Or, some PyCObject/PyCapsule issue. > >> 5) On 64 bit platforms, scipy.test() quits at the following test >> >> test_interpnd.TestCloughTocher2DInterpolator.test_dense ... QH6084 qhull >> internal error (qh_meminit): sizeof(void*) 8> sizeof(ptr_intT) 4. >> Change ptr_intT in mem.h to 'long long' > > Should be fixed in r7013 Thanks. From pav at iki.fi Mon Dec 13 17:43:22 2010 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 13 Dec 2010 22:43:22 +0000 (UTC) Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 References: <4D066365.5090104@uci.edu> <4D069C59.4000003@uci.edu> Message-ID: On Mon, 13 Dec 2010 14:21:13 -0800, Christoph Gohlke wrote: [clip] > Yes, see SWIG bug #3057804 "[Python] wrapper does not compile with > python 3.2" > Possibly addressed by this: https://github.com/pv/scipy-work/tree/bug/sparsetools-reswig If it fixes it, then it's probably the correct solution. It's also possible that the issue (4) is related to this on Python 2.7/3.1, since I can't think of much else than the PyCObject/PyCapsule issue that would have changed in between. >>> 3) 32-bit Python 2.6 is the only platform where scipy.test() finishes; [clip] >> sc.airye(-1) > > __main__:1: SpecialFunctionWarning: airye:: unknown error > __main__:1: SpecialFunctionWarning: airye:: unknown error > (nan, nan, 0.10399738949694459, 0.59237562642279229) Then I don't understand why in the test the function gives (nan, nan, nan, nan) OTOH, there are some other bugs, where when linked with MKL, some non-local effects (indicating memory corruption / fp state stuff) on function return values appear. -- Pauli Virtanen From ralf.gommers at googlemail.com Tue Dec 14 07:14:57 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 14 Dec 2010 20:14:57 +0800 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Tue, Dec 14, 2010 at 12:46 AM, Pauli Virtanen wrote: > Tue, 14 Dec 2010 00:12:32 +0800, Ralf Gommers wrote: > > I am pleased to announce the availability of the first beta of SciPy > > 0.9.0. This will be the first SciPy release to include support for > > Python 3, as well as for Python 2.7. > > Note: scipy.weave does not work on Python 3 yet; the other parts of > Scipy do. > > Do you (or anyone else) plan to work on this before the final release? If not I'll update the release notes. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Tue Dec 14 07:28:41 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 14 Dec 2010 12:28:41 +0000 (UTC) Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 References: Message-ID: Tue, 14 Dec 2010 20:14:57 +0800, Ralf Gommers wrote: [clip] > Do you (or anyone else) plan to work on this before the final release? > If not I'll update the release notes. If I find time for it before the RC. If someone else wants to take a shot at it, be welcome. In any case it's best to update the release notes to reflect the current situation. Pauli From ralf.gommers at googlemail.com Tue Dec 14 07:38:14 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 14 Dec 2010 20:38:14 +0800 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root wrote: > On Mon, Dec 13, 2010 at 10:12 AM, Ralf Gommers < > ralf.gommers at googlemail.com> wrote: > >> Hi, >> >> I am pleased to announce the availability of the first beta of SciPy >> 0.9.0. This will be the first SciPy release to include support for Python >> 3, as well as for Python 2.7. Please try this beta and report any >> problems on the scipy-dev mailing list. >> >> Binaries, sources and release notes can be found athttp://sourceforge.net/projects/scipy/files/scipy/0.9.0b1/. >> Note that not all binaries (win32-py27, *-macosx10.3) are uploaded yet, they >> will follow in the next day or two. >> >> There are still a few known issues (so no need to report these): >> 1. Arpack related errors on 64-bit OS X. >> 2. Correlate complex192 errors on Windows. >> 3. correlate/conjugate current behavior is deprecated and should be >> removed before RC1. >> >> Enjoy, >> Ralf >> >> Hi Ben, > > Just did a clean rebuild (after a clean rebuild of numpy) and had two > errors in the tests: > What platform are you on? > > ====================================================================== > FAIL: test_imresize (test_pilutil.TestPILUtil) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, in > skipper_func > return f(*args, **kwargs) > File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line > 25, in test_imresize > assert_equal(im1.shape,(11,22)) > File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in > assert_equal > assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), > verbose) > File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in > assert_equal > raise AssertionError(msg) > AssertionError: > Items are not equal: > item=0 > > ACTUAL: 10 > DESIRED: 11 > This test should be changed to use a fixed seed (add as a first line of the test "np.random.seed(12345678)"). Can you provide one that fails? > > ====================================================================== > FAIL: test_basic (test_signaltools.TestMedFilt) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/bvr/Programs/scipy/scipy/signal/tests/test_signaltools.py", > line 284, in test_basic > [ 0, 7, 11, 7, 4, 4, 19, 19, 24, 0]]) > File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 686, in > assert_array_equal > verbose=verbose, header='Arrays are not equal') > File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 618, in > assert_array_compare > raise AssertionError(msg) > AssertionError: > Arrays are not equal > > (mismatch 8.0%) > x: array([[ 0., 50., 50., 50., 42., 15., 15., 18., 27., 0.], > [ 0., 50., 50., 50., 50., 42., 19., 21., 29., 0.], > [ 50., 50., 50., 50., 50., 47., 34., 34., 46., 35.],... > y: array([[ 0, 50, 50, 50, 42, 15, 15, 18, 27, 0], > [ 0, 50, 50, 50, 50, 42, 19, 21, 29, 0], > [50, 50, 50, 50, 50, 47, 34, 34, 46, 35],... > > ---------------------------------------------------------------------- > Ran 4822 tests in 199.244s > > FAILED (KNOWNFAIL=12, SKIP=35, failures=2) > > > > Don't know about the first one, but the second one looks like a > type-casting issue, because all the values are the same, except one is > floating point and the other is integer. > This was also reported by Nils some days ago, he had one value that was different between arrays. Ralf > > Ben Root > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Tue Dec 14 09:02:53 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 14 Dec 2010 22:02:53 +0800 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: <4D066365.5090104@uci.edu> Message-ID: On Tue, Dec 14, 2010 at 5:43 AM, Pauli Virtanen wrote: > On Mon, 13 Dec 2010 10:18:13 -0800, Christoph Gohlke wrote: > [clip] > > I ran into the following issues with scipy 0.9.0b1 on Windows when > > building with msvc 9 and intel 11.1 compilers. Numpy is version 1.5.1, > > linked against MKL. > > > > 1) after patching some source files and setup scripts (see msvc9.diff > > attachment), "python setup.py bdist_winist" succeeds on 32- and 64-bit > > Python 2.6, 2.7, and 3.1. The Visual C compiler reproducibly crashes > > while compiling scipy\special\cephes\ndtr.c. Running the build command > > again (without cleaning the build directory) seems to work. > > Some of that patch should end up in the tree? I'm not sure which parts, > though. > > [clip] > > 2) the build process fails on Python 3.2b1 with the following errors: > > > > scipy\sparse\sparsetools\csr_wrap.cxx(2451) : error C3861: > > 'PyCObject_Import': identifier not found > > scipy\sparse\sparsetools\csr_wrap.cxx(2521) : error C3861: > > 'PyCObject_FromVoidPtr': identifier not found > > scipy\sparse\sparsetools\csr_wrap.cxx(2544) : error C3861: > > 'PyCObject_AsVoidPtr': identifier not found > > It seems that the version of SWIG used there is not compatible with > Python 3.2. > > > 3) 32-bit Python 2.6 is the only platform where scipy.test() finishes; > > albeit with 32 failures. Besides the Correlate complex192 and TestODR > > errors (http://projects.scipy.org/scipy/ticket/678) I get > [clip] > > FAIL: Real-valued Bessel domains > [clip] > > AssertionError: (nan, nan, nan, nan) > > This indicates some issue with AMOS and ifort. What do you get from > > import warnings, scipy.special as sc > warnings.simplefilter('always', sc.SpecialFunctionWarning) > sc.errprint(1) > sc.airye(-1) > > It's possible that the test is too strict. > > > 4) scipy.test() on Python 2.7 and 3.1 crashes as reported in ticket > > #1210 > > This smells like something triggering a DeprecationWarning when GIL is > released. If so, it should be compiler independent and reproducible on > wine+mingw. Or, some PyCObject/PyCapsule issue. > > On wine+mingw there are no crashes. With 3.1 there are no DeprecationWarning's, with 2.7 there is one: Z:\Users\rgommers\.wine\drive_c\Python27\lib\site-packages\scipy\ndimage\morphology.py:254: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7. Please use capsule objects instead. structure, mask, output, border_value, origin, invert, cit, 1) Other than that there is one other (unrelated) failure that I don't think has been reported before, see below. Full test logs are attached. Cheers, Ralf ====================================================================== FAIL: test_linesearch.TestLineSearch.test_line_search_wolfe1 ---------------------------------------------------------------------- Traceback (most recent call last): File "Z:\Users\rgommers\.wine\drive_c\Python27\lib\site-packages\nose-0.11.4-py2.7.egg\nose\case.py", line 186, in runTest self.test(*self.arg) File "Z:\Users\rgommers\.wine\drive_c\Python27\lib\site-packages\scipy\optimize\tests\test_linesearch.py", line 165, in test_line_search_wolfe1 assert_equal(gv, fprime(x + s*p)) File "Z:\Users\rgommers\.wine\drive_c\Python27\lib\site-packages\numpy\testing\utils.py", line 256, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "Z:\Users\rgommers\.wine\drive_c\Python27\lib\site-packages\numpy\testing\utils.py", line 686, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "Z:\Users\rgommers\.wine\drive_c\Python27\lib\site-packages\numpy\testing\utils.py", line 618, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 35.0%) x: array([ 0.59815369, 16.47021747, 3.04622715, 15.93277506, 10.10616782, -10.90475125, -10.885384 , 1.20593902, 9.66558674, -8.59479687, 2.08976118, 15.85496522,... y: array([ 0.59815369, 16.47021747, 3.04622715, 15.93277506, 10.10616782, -10.90475125, -10.885384 , 1.20593902, 9.66558674, -8.59479687, 2.08976118, 15.85496522,... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scipy090b1_tests_wine_py31.log Type: application/octet-stream Size: 51674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scipy090b1_tests_wine_py27.log Type: application/octet-stream Size: 50169 bytes Desc: not available URL: From ben.root at ou.edu Tue Dec 14 11:01:55 2010 From: ben.root at ou.edu (Benjamin Root) Date: Tue, 14 Dec 2010 10:01:55 -0600 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Tue, Dec 14, 2010 at 6:38 AM, Ralf Gommers wrote: > > > On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root wrote: > >> On Mon, Dec 13, 2010 at 10:12 AM, Ralf Gommers < >> ralf.gommers at googlemail.com> wrote: >> >>> Hi, >>> >>> I am pleased to announce the availability of the first beta of SciPy >>> 0.9.0. This will be the first SciPy release to include support for >>> Python 3, as well as for Python 2.7. Please try this beta and report any >>> problems on the scipy-dev mailing list. >>> >>> Binaries, sources and release notes can be found athttp://sourceforge.net/projects/scipy/files/scipy/0.9.0b1/. >>> Note that not all binaries (win32-py27, *-macosx10.3) are uploaded yet, they >>> will follow in the next day or two. >>> >>> There are still a few known issues (so no need to report these): >>> 1. Arpack related errors on 64-bit OS X. >>> 2. Correlate complex192 errors on Windows. >>> 3. correlate/conjugate current behavior is deprecated and should be >>> removed before RC1. >>> >>> Enjoy, >>> Ralf >>> >>> > Hi Ben, > >> >> Just did a clean rebuild (after a clean rebuild of numpy) and had two >> errors in the tests: >> > > What platform are you on? > I reran the tests on just this scipy.misc module, here is the output: >>> scipy.misc.test() Running unit tests for scipy.misc NumPy version 2.0.0.dev-799179d NumPy is installed in /home/bvr/Programs/numpy/numpy SciPy version 0.10.0.dev SciPy is installed in /home/bvr/Programs/scipy/scipy Python version 2.6.4 (r264:75706, Jun 4 2010, 18:20:16) [GCC 4.4.4 20100503 (Red Hat 4.4.4-2)] nose version 0.11.3 ...........F..... ====================================================================== FAIL: test_imresize (test_pilutil.TestPILUtil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line 28, in test_imresize assert_equal(im1.shape,(11,22)) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=0 ACTUAL: 10 DESIRED: 11 ---------------------------------------------------------------------- Ran 17 tests in 0.089s FAILED (failures=1) Note, that I am still getting this error with the suggested addition of "np.random.seed(12345678)" to scipy/misc/tests/test_pilutil.py. I tried it both at line 20 (before the call to class TestPILUtil) and at line 24 (before the call to np.random.random() in test_imresize. I do not see how setting the seed value for these tests would make any difference since they are merely testing the resulting shape of the image after a resize, not the values of the resized image itself. > >> ====================================================================== >> FAIL: test_imresize (test_pilutil.TestPILUtil) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, >> in skipper_func >> return f(*args, **kwargs) >> File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line >> 25, in test_imresize >> assert_equal(im1.shape,(11,22)) >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in >> assert_equal >> assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), >> verbose) >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in >> assert_equal >> raise AssertionError(msg) >> AssertionError: >> Items are not equal: >> item=0 >> >> ACTUAL: 10 >> DESIRED: 11 >> > > This test should be changed to use a fixed seed (add as a first line of the > test "np.random.seed(12345678)"). Can you provide one that fails? > > Also, I am not sure what you mean by "Can you provide one that fails?". > >> ====================================================================== >> FAIL: test_basic (test_signaltools.TestMedFilt) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/home/bvr/Programs/scipy/scipy/signal/tests/test_signaltools.py", >> line 284, in test_basic >> [ 0, 7, 11, 7, 4, 4, 19, 19, 24, 0]]) >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 686, in >> assert_array_equal >> verbose=verbose, header='Arrays are not equal') >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 618, in >> assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Arrays are not equal >> >> (mismatch 8.0%) >> x: array([[ 0., 50., 50., 50., 42., 15., 15., 18., 27., 0.], >> [ 0., 50., 50., 50., 50., 42., 19., 21., 29., 0.], >> [ 50., 50., 50., 50., 50., 47., 34., 34., 46., 35.],... >> y: array([[ 0, 50, 50, 50, 42, 15, 15, 18, 27, 0], >> [ 0, 50, 50, 50, 50, 42, 19, 21, 29, 0], >> [50, 50, 50, 50, 50, 47, 34, 34, 46, 35],... >> >> ---------------------------------------------------------------------- >> Ran 4822 tests in 199.244s >> >> FAILED (KNOWNFAIL=12, SKIP=35, failures=2) >> >> >> Oddly enough, this second error does not always repeat itself (I had one run of the test where it did not happen...). Also, something interesting occurred while trying to get more verbose output from scipy.signal.test. When I ran it for the second time in a python session, a regression error pops up, but this never happens in the first run of the test. ====================================================================== FAIL: Regression test for #651: better handling of badly conditioned ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bvr/Programs/scipy/scipy/signal/tests/test_filter_design.py", line 32, in test_bad_filter assert_raises(BadCoefficients, tf2zpk, [1e-15], [1.0, 1.0]) File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 982, in assert_raises return nose.tools.assert_raises(*args,**kwargs) AssertionError: BadCoefficients not raised I hope this is helpful. Let me know what other information I can provide. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Tue Dec 14 11:13:52 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 15 Dec 2010 00:13:52 +0800 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Wed, Dec 15, 2010 at 12:01 AM, Benjamin Root wrote: > > > On Tue, Dec 14, 2010 at 6:38 AM, Ralf Gommers > wrote: > >> >> >> On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root wrote: >> >> Hi Ben, >> >>> >>> Just did a clean rebuild (after a clean rebuild of numpy) and had two >>> errors in the tests: >>> >> >> What platform are you on? >> > > I reran the tests on just this scipy.misc module, here is the output: > > >>> scipy.misc.test() > Running unit tests for scipy.misc > NumPy version 2.0.0.dev-799179d > NumPy is installed in /home/bvr/Programs/numpy/numpy > SciPy version 0.10.0.dev > SciPy is installed in /home/bvr/Programs/scipy/scipy > Python version 2.6.4 (r264:75706, Jun 4 2010, 18:20:16) [GCC 4.4.4 > 20100503 (Red Hat 4.4.4-2)] > nose version 0.11.3 > ...........F..... > > ====================================================================== > FAIL: test_imresize (test_pilutil.TestPILUtil) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, in > skipper_func > return f(*args, **kwargs) > File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line > 28, in test_imresize > > assert_equal(im1.shape,(11,22)) > File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in > assert_equal > assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), > verbose) > File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in > assert_equal > raise AssertionError(msg) > AssertionError: > Items are not equal: > item=0 > > ACTUAL: 10 > DESIRED: 11 > > ---------------------------------------------------------------------- > Ran 17 tests in 0.089s > > FAILED (failures=1) > > > Note, that I am still getting this error with the suggested addition of > "np.random.seed(12345678)" to scipy/misc/tests/test_pilutil.py. I tried it > both at line 20 (before the call to class TestPILUtil) and at line 24 > (before the call to np.random.random() in test_imresize. I do not see how > setting the seed value for these tests would make any difference since they > are merely testing the resulting shape of the image after a resize, not the > values of the resized image itself. > The seeding may not matter (I haven't actually looked in detail yet), but I thought I had seen this error pop up before, but not reproducibly. The imresize function does some interpolation, so the numerical values could matter. In that case seeding would help. > > >> >>> ====================================================================== >>> FAIL: test_imresize (test_pilutil.TestPILUtil) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, >>> in skipper_func >>> return f(*args, **kwargs) >>> File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line >>> 25, in test_imresize >>> assert_equal(im1.shape,(11,22)) >>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in >>> assert_equal >>> assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), >>> verbose) >>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in >>> assert_equal >>> raise AssertionError(msg) >>> AssertionError: >>> Items are not equal: >>> item=0 >>> >>> ACTUAL: 10 >>> DESIRED: 11 >>> >> >> This test should be changed to use a fixed seed (add as a first line of >> the test "np.random.seed(12345678)"). Can you provide one that fails? >> >> > > Also, I am not sure what you mean by "Can you provide one that fails?". > I meant a seed value that fails. This one does, that's all we need. > > >> >>> ====================================================================== >>> FAIL: test_basic (test_signaltools.TestMedFilt) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/home/bvr/Programs/scipy/scipy/signal/tests/test_signaltools.py", >>> line 284, in test_basic >>> [ 0, 7, 11, 7, 4, 4, 19, 19, 24, 0]]) >>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 686, in >>> assert_array_equal >>> verbose=verbose, header='Arrays are not equal') >>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 618, in >>> assert_array_compare >>> raise AssertionError(msg) >>> AssertionError: >>> Arrays are not equal >>> >>> (mismatch 8.0%) >>> x: array([[ 0., 50., 50., 50., 42., 15., 15., 18., 27., 0.], >>> [ 0., 50., 50., 50., 50., 42., 19., 21., 29., 0.], >>> [ 50., 50., 50., 50., 50., 47., 34., 34., 46., 35.],... >>> y: array([[ 0, 50, 50, 50, 42, 15, 15, 18, 27, 0], >>> [ 0, 50, 50, 50, 50, 42, 19, 21, 29, 0], >>> [50, 50, 50, 50, 50, 47, 34, 34, 46, 35],... >>> >>> ---------------------------------------------------------------------- >>> Ran 4822 tests in 199.244s >>> >>> FAILED (KNOWNFAIL=12, SKIP=35, failures=2) >>> >>> >>> > Oddly enough, this second error does not always repeat itself (I had one > run of the test where it did not happen...). Also, something interesting > occurred while trying to get more verbose output from scipy.signal.test. > When I ran it for the second time in a python session, a regression error > pops up, but this never happens in the first run of the test. > That's just because warnings like that are only raised once from the same module. So the second time the check fails. Nothing to worry about. Cheers, Ralf > > ====================================================================== > FAIL: Regression test for #651: better handling of badly conditioned > > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/bvr/Programs/scipy/scipy/signal/tests/test_filter_design.py", > line 32, in test_bad_filter > assert_raises(BadCoefficients, tf2zpk, [1e-15], [1.0, 1.0]) > File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 982, in > assert_raises > return nose.tools.assert_raises(*args,**kwargs) > AssertionError: BadCoefficients not raised > > I hope this is helpful. Let me know what other information I can provide. > > Ben Root > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Tue Dec 14 12:52:59 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 14 Dec 2010 11:52:59 -0600 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Tue, Dec 14, 2010 at 10:13 AM, Ralf Gommers wrote: > > > On Wed, Dec 15, 2010 at 12:01 AM, Benjamin Root wrote: >> >> >> On Tue, Dec 14, 2010 at 6:38 AM, Ralf Gommers >> wrote: >>> >>> >>> On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root wrote: >>> >>> Hi Ben, >>>> >>>> Just did a clean rebuild (after a clean rebuild of numpy) and had two >>>> errors in the tests: >>> >>> What platform are you on? >> >> I reran the tests on just this scipy.misc module, here is the output: >> >> >>> scipy.misc.test() >> Running unit tests for scipy.misc >> NumPy version 2.0.0.dev-799179d >> NumPy is installed in /home/bvr/Programs/numpy/numpy >> SciPy version 0.10.0.dev >> SciPy is installed in /home/bvr/Programs/scipy/scipy >> Python version 2.6.4 (r264:75706, Jun? 4 2010, 18:20:16) [GCC 4.4.4 >> 20100503 (Red Hat 4.4.4-2)] >> nose version 0.11.3 >> ...........F..... >> ====================================================================== >> FAIL: test_imresize (test_pilutil.TestPILUtil) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> ? File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, >> in skipper_func >> ??? return f(*args, **kwargs) >> ? File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line >> 28, in test_imresize >> ??? assert_equal(im1.shape,(11,22)) >> ? File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in >> assert_equal >> ??? assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), >> verbose) >> ? File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in >> assert_equal >> ??? raise AssertionError(msg) >> AssertionError: >> Items are not equal: >> item=0 >> >> ?ACTUAL: 10 >> ?DESIRED: 11 >> >> ---------------------------------------------------------------------- >> Ran 17 tests in 0.089s >> >> FAILED (failures=1) >> >> >> Note, that I am still getting this error with the suggested addition of >> "np.random.seed(12345678)" to scipy/misc/tests/test_pilutil.py.? I tried it >> both at line 20 (before the call to class TestPILUtil) and at line 24 >> (before the call to np.random.random() in test_imresize.? I do not see how >> setting the seed value for these tests would make any difference since they >> are merely testing the resulting shape of the image after a resize, not the >> values of the resized image itself. > > The seeding may not matter (I haven't actually looked in detail yet), but I > thought I had seen this error pop up before, but not reproducibly. The > imresize function does some interpolation, so the numerical values could > matter. In that case seeding would help. >> >> >>>> >>>> ====================================================================== >>>> FAIL: test_imresize (test_pilutil.TestPILUtil) >>>> ---------------------------------------------------------------------- >>>> Traceback (most recent call last): >>>> ? File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, >>>> in skipper_func >>>> ??? return f(*args, **kwargs) >>>> ? File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line >>>> 25, in test_imresize >>>> ??? assert_equal(im1.shape,(11,22)) >>>> ? File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in >>>> assert_equal >>>> ??? assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), >>>> verbose) >>>> ? File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in >>>> assert_equal >>>> ??? raise AssertionError(msg) >>>> AssertionError: >>>> Items are not equal: >>>> item=0 >>>> >>>> ?ACTUAL: 10 >>>> ?DESIRED: 11 >>> >>> This test should be changed to use a fixed seed (add as a first line of >>> the test "np.random.seed(12345678)"). Can you provide one that fails? >>> >> >> Also, I am not sure what you mean by "Can you provide one that fails?". > > I meant a seed value that fails. This one does, that's all we need. On my 64-bit linux system with Python 2.7, the error appears comes from float16 dtype rather than the actual seed >>> np.random.seed(12345678) >>> for T in np.sctypes['float'] + [float]: ... im1 = pilutil.imresize(im,T(1.1)) ... print T, im.shape, im1.shape ... (10, 20) (10, 21) (10, 20) (11, 22) (10, 20) (11, 22) (10, 20) (11, 22) (10, 20) (11, 22) Here only the float16 has different shape from the rest. Two other items: There is a print statement in the function test_cg for 'conjugate gradient optimization routine' that needs to be commented out: See line 70 of scipy-0.9.0b1/scipy/optimize/tests/test_optimize.py: 'print self.funccalls, self.gradcalls' There is a PendingDeprecationWarning with Python2.7 which I can add a ticket for if this is non-trivial. Relevant line from verbose=10: binary dilation 29 ... /usr/lib64/python2.7/site-packages/scipy/ndimage/morphology.py:254: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7. Please use capsule objects instead. structure, mask, output, border_value, origin, invert, cit, 1) ok Is it possible to silence the 'ComplexWarning: Casting complex values to real discards the imaginary part' message and perhaps the 'Warning: divide by zero encountered in log' message while running the tests? My reasoning is that these tend to hide real problems. Bruce From charlesr.harris at gmail.com Tue Dec 14 15:09:11 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 14 Dec 2010 13:09:11 -0700 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Tue, Dec 14, 2010 at 10:52 AM, Bruce Southey wrote: > On Tue, Dec 14, 2010 at 10:13 AM, Ralf Gommers > wrote: > > > > > > On Wed, Dec 15, 2010 at 12:01 AM, Benjamin Root wrote: > >> > >> > >> On Tue, Dec 14, 2010 at 6:38 AM, Ralf Gommers > >> wrote: > >>> > >>> > >>> On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root > wrote: > >>> > >>> Hi Ben, > >>>> > >>>> Just did a clean rebuild (after a clean rebuild of numpy) and had two > >>>> errors in the tests: > >>> > >>> What platform are you on? > >> > >> I reran the tests on just this scipy.misc module, here is the output: > >> > >> >>> scipy.misc.test() > >> Running unit tests for scipy.misc > >> NumPy version 2.0.0.dev-799179d > >> NumPy is installed in /home/bvr/Programs/numpy/numpy > >> SciPy version 0.10.0.dev > >> SciPy is installed in /home/bvr/Programs/scipy/scipy > >> Python version 2.6.4 (r264:75706, Jun 4 2010, 18:20:16) [GCC 4.4.4 > >> 20100503 (Red Hat 4.4.4-2)] > >> nose version 0.11.3 > >> ...........F..... > >> ====================================================================== > >> FAIL: test_imresize (test_pilutil.TestPILUtil) > >> ---------------------------------------------------------------------- > >> Traceback (most recent call last): > >> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, > >> in skipper_func > >> return f(*args, **kwargs) > >> File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line > >> 28, in test_imresize > >> assert_equal(im1.shape,(11,22)) > >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in > >> assert_equal > >> assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), > >> verbose) > >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in > >> assert_equal > >> raise AssertionError(msg) > >> AssertionError: > >> Items are not equal: > >> item=0 > >> > >> ACTUAL: 10 > >> DESIRED: 11 > >> > >> ---------------------------------------------------------------------- > >> Ran 17 tests in 0.089s > >> > >> FAILED (failures=1) > >> > >> > >> Note, that I am still getting this error with the suggested addition of > >> "np.random.seed(12345678)" to scipy/misc/tests/test_pilutil.py. I tried > it > >> both at line 20 (before the call to class TestPILUtil) and at line 24 > >> (before the call to np.random.random() in test_imresize. I do not see > how > >> setting the seed value for these tests would make any difference since > they > >> are merely testing the resulting shape of the image after a resize, not > the > >> values of the resized image itself. > > > > The seeding may not matter (I haven't actually looked in detail yet), but > I > > thought I had seen this error pop up before, but not reproducibly. The > > imresize function does some interpolation, so the numerical values could > > matter. In that case seeding would help. > >> > >> > >>>> > >>>> ====================================================================== > >>>> FAIL: test_imresize (test_pilutil.TestPILUtil) > >>>> ---------------------------------------------------------------------- > >>>> Traceback (most recent call last): > >>>> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line > 146, > >>>> in skipper_func > >>>> return f(*args, **kwargs) > >>>> File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", > line > >>>> 25, in test_imresize > >>>> assert_equal(im1.shape,(11,22)) > >>>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in > >>>> assert_equal > >>>> assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), > >>>> verbose) > >>>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in > >>>> assert_equal > >>>> raise AssertionError(msg) > >>>> AssertionError: > >>>> Items are not equal: > >>>> item=0 > >>>> > >>>> ACTUAL: 10 > >>>> DESIRED: 11 > >>> > >>> This test should be changed to use a fixed seed (add as a first line of > >>> the test "np.random.seed(12345678)"). Can you provide one that fails? > >>> > >> > >> Also, I am not sure what you mean by "Can you provide one that fails?". > > > > I meant a seed value that fails. This one does, that's all we need. > > On my 64-bit linux system with Python 2.7, the error appears comes > from float16 dtype rather than the actual seed > >>> np.random.seed(12345678) > >>> for T in np.sctypes['float'] + [float]: > ... im1 = pilutil.imresize(im,T(1.1)) > ... print T, im.shape, im1.shape > ... > (10, 20) (10, 21) > (10, 20) (11, 22) > (10, 20) (11, 22) > (10, 20) (11, 22) > (10, 20) (11, 22) > > Here only the float16 has different shape from the rest. > > Ah, you compiled against numpy master instead of numpy 1.5.1, float16 is only in the development branch. I think the test should be fixed to use an explicit list of types supported by pilutil. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Tue Dec 14 15:15:59 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 14 Dec 2010 14:15:59 -0600 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: <4D07D07F.8050003@gmail.com> On 12/14/2010 02:09 PM, Charles R Harris wrote: > > > On Tue, Dec 14, 2010 at 10:52 AM, Bruce Southey > wrote: > > On Tue, Dec 14, 2010 at 10:13 AM, Ralf Gommers > > > wrote: > > > > > > On Wed, Dec 15, 2010 at 12:01 AM, Benjamin Root > wrote: > >> > >> > >> On Tue, Dec 14, 2010 at 6:38 AM, Ralf Gommers > >> > wrote: > >>> > >>> > >>> On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root > > wrote: > >>> > >>> Hi Ben, > >>>> > >>>> Just did a clean rebuild (after a clean rebuild of numpy) and > had two > >>>> errors in the tests: > >>> > >>> What platform are you on? > >> > >> I reran the tests on just this scipy.misc module, here is the > output: > >> > >> >>> scipy.misc.test() > >> Running unit tests for scipy.misc > >> NumPy version 2.0.0.dev-799179d > >> NumPy is installed in /home/bvr/Programs/numpy/numpy > >> SciPy version 0.10.0.dev > >> SciPy is installed in /home/bvr/Programs/scipy/scipy > >> Python version 2.6.4 (r264:75706, Jun 4 2010, 18:20:16) [GCC 4.4.4 > >> 20100503 (Red Hat 4.4.4-2)] > >> nose version 0.11.3 > >> ...........F..... > >> > ====================================================================== > >> FAIL: test_imresize (test_pilutil.TestPILUtil) > >> > ---------------------------------------------------------------------- > >> Traceback (most recent call last): > >> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", > line 146, > >> in skipper_func > >> return f(*args, **kwargs) > >> File > "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line > >> 28, in test_imresize > >> assert_equal(im1.shape,(11,22)) > >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line > 251, in > >> assert_equal > >> assert_equal(actual[k], desired[k], 'item=%r\n%s' % > (k,err_msg), > >> verbose) > >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line > 313, in > >> assert_equal > >> raise AssertionError(msg) > >> AssertionError: > >> Items are not equal: > >> item=0 > >> > >> ACTUAL: 10 > >> DESIRED: 11 > >> > >> > ---------------------------------------------------------------------- > >> Ran 17 tests in 0.089s > >> > >> FAILED (failures=1) > >> > >> > >> Note, that I am still getting this error with the suggested > addition of > >> "np.random.seed(12345678)" to > scipy/misc/tests/test_pilutil.py. I tried it > >> both at line 20 (before the call to class TestPILUtil) and at > line 24 > >> (before the call to np.random.random() in test_imresize. I do > not see how > >> setting the seed value for these tests would make any > difference since they > >> are merely testing the resulting shape of the image after a > resize, not the > >> values of the resized image itself. > > > > The seeding may not matter (I haven't actually looked in detail > yet), but I > > thought I had seen this error pop up before, but not > reproducibly. The > > imresize function does some interpolation, so the numerical > values could > > matter. In that case seeding would help. > >> > >> > >>>> > >>>> > ====================================================================== > >>>> FAIL: test_imresize (test_pilutil.TestPILUtil) > >>>> > ---------------------------------------------------------------------- > >>>> Traceback (most recent call last): > >>>> File > "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line 146, > >>>> in skipper_func > >>>> return f(*args, **kwargs) > >>>> File > "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", line > >>>> 25, in test_imresize > >>>> assert_equal(im1.shape,(11,22)) > >>>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", > line 251, in > >>>> assert_equal > >>>> assert_equal(actual[k], desired[k], 'item=%r\n%s' % > (k,err_msg), > >>>> verbose) > >>>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", > line 313, in > >>>> assert_equal > >>>> raise AssertionError(msg) > >>>> AssertionError: > >>>> Items are not equal: > >>>> item=0 > >>>> > >>>> ACTUAL: 10 > >>>> DESIRED: 11 > >>> > >>> This test should be changed to use a fixed seed (add as a > first line of > >>> the test "np.random.seed(12345678)"). Can you provide one that > fails? > >>> > >> > >> Also, I am not sure what you mean by "Can you provide one that > fails?". > > > > I meant a seed value that fails. This one does, that's all we need. > > On my 64-bit linux system with Python 2.7, the error appears comes > from float16 dtype rather than the actual seed > >>> np.random.seed(12345678) > >>> for T in np.sctypes['float'] + [float]: > ... im1 = pilutil.imresize(im,T(1.1)) > ... print T, im.shape, im1.shape > ... > (10, 20) (10, 21) > (10, 20) (11, 22) > (10, 20) (11, 22) > (10, 20) (11, 22) > (10, 20) (11, 22) > > Here only the float16 has different shape from the rest. > > > Ah, you compiled against numpy master instead of numpy 1.5.1, float16 > is only in the development branch. I think the test should be fixed to > use an explicit list of types supported by pilutil. > > Chuck > > Sorry, I forgot to add the numpy version '2.0.0.dev-799179d' because 1.5.1 is just too old and I am too lazy to go back and downgrade :-) Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Tue Dec 14 16:23:28 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 14 Dec 2010 15:23:28 -0600 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: <4D07D07F.8050003@gmail.com> References: <4D07D07F.8050003@gmail.com> Message-ID: On Tue, Dec 14, 2010 at 2:15 PM, Bruce Southey wrote: > On 12/14/2010 02:09 PM, Charles R Harris wrote: > > On Tue, Dec 14, 2010 at 10:52 AM, Bruce Southey wrote: >> >> On Tue, Dec 14, 2010 at 10:13 AM, Ralf Gommers >> wrote: >> > >> > >> > On Wed, Dec 15, 2010 at 12:01 AM, Benjamin Root wrote: >> >> >> >> >> >> On Tue, Dec 14, 2010 at 6:38 AM, Ralf Gommers >> >> wrote: >> >>> >> >>> >> >>> On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root >> >>> wrote: >> >>> >> >>> Hi Ben, >> >>>> >> >>>> Just did a clean rebuild (after a clean rebuild of numpy) and had two >> >>>> errors in the tests: >> >>> >> >>> What platform are you on? >> >> >> >> I reran the tests on just this scipy.misc module, here is the output: >> >> >> >> >>> scipy.misc.test() >> >> Running unit tests for scipy.misc >> >> NumPy version 2.0.0.dev-799179d >> >> NumPy is installed in /home/bvr/Programs/numpy/numpy >> >> SciPy version 0.10.0.dev >> >> SciPy is installed in /home/bvr/Programs/scipy/scipy >> >> Python version 2.6.4 (r264:75706, Jun? 4 2010, 18:20:16) [GCC 4.4.4 >> >> 20100503 (Red Hat 4.4.4-2)] >> >> nose version 0.11.3 >> >> ...........F..... >> >> ====================================================================== >> >> FAIL: test_imresize (test_pilutil.TestPILUtil) >> >> ---------------------------------------------------------------------- >> >> Traceback (most recent call last): >> >> ? File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line >> >> 146, >> >> in skipper_func >> >> ??? return f(*args, **kwargs) >> >> ? File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", >> >> line >> >> 28, in test_imresize >> >> ??? assert_equal(im1.shape,(11,22)) >> >> ? File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in >> >> assert_equal >> >> ??? assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), >> >> verbose) >> >> ? File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in >> >> assert_equal >> >> ??? raise AssertionError(msg) >> >> AssertionError: >> >> Items are not equal: >> >> item=0 >> >> >> >> ?ACTUAL: 10 >> >> ?DESIRED: 11 >> >> >> >> ---------------------------------------------------------------------- >> >> Ran 17 tests in 0.089s >> >> >> >> FAILED (failures=1) >> >> >> >> >> >> Note, that I am still getting this error with the suggested addition of >> >> "np.random.seed(12345678)" to scipy/misc/tests/test_pilutil.py.? I >> >> tried it >> >> both at line 20 (before the call to class TestPILUtil) and at line 24 >> >> (before the call to np.random.random() in test_imresize.? I do not see >> >> how >> >> setting the seed value for these tests would make any difference since >> >> they >> >> are merely testing the resulting shape of the image after a resize, not >> >> the >> >> values of the resized image itself. >> > >> > The seeding may not matter (I haven't actually looked in detail yet), >> > but I >> > thought I had seen this error pop up before, but not reproducibly. The >> > imresize function does some interpolation, so the numerical values could >> > matter. In that case seeding would help. >> >> >> >> >> >>>> >> >>>> >> >>>> ====================================================================== >> >>>> FAIL: test_imresize (test_pilutil.TestPILUtil) >> >>>> >> >>>> ---------------------------------------------------------------------- >> >>>> Traceback (most recent call last): >> >>>> ? File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line >> >>>> 146, >> >>>> in skipper_func >> >>>> ??? return f(*args, **kwargs) >> >>>> ? File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", >> >>>> line >> >>>> 25, in test_imresize >> >>>> ??? assert_equal(im1.shape,(11,22)) >> >>>> ? File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, >> >>>> in >> >>>> assert_equal >> >>>> ??? assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), >> >>>> verbose) >> >>>> ? File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, >> >>>> in >> >>>> assert_equal >> >>>> ??? raise AssertionError(msg) >> >>>> AssertionError: >> >>>> Items are not equal: >> >>>> item=0 >> >>>> >> >>>> ?ACTUAL: 10 >> >>>> ?DESIRED: 11 >> >>> >> >>> This test should be changed to use a fixed seed (add as a first line >> >>> of >> >>> the test "np.random.seed(12345678)"). Can you provide one that fails? >> >>> >> >> >> >> Also, I am not sure what you mean by "Can you provide one that fails?". >> > >> > I meant a seed value that fails. This one does, that's all we need. >> >> On my 64-bit linux system with Python 2.7, the error appears comes >> from float16 dtype rather than the actual seed >> >>> np.random.seed(12345678) >> >>> for T in np.sctypes['float'] + [float]: >> ... ? ? im1 = pilutil.imresize(im,T(1.1)) >> ... ? ? print T, im.shape, im1.shape >> ... >> (10, 20) (10, 21) >> (10, 20) (11, 22) >> (10, 20) (11, 22) >> (10, 20) (11, 22) >> (10, 20) (11, 22) >> >> Here only the float16 has different shape from the rest. >> > > Ah, you compiled against numpy master instead of numpy 1.5.1, float16 is > only in the development branch. I think the test should be fixed to use an > explicit list of types supported by pilutil. > > Chuck > > > Sorry, > I forgot to add the numpy version '2.0.0.dev-799179d' because 1.5.1 is just > too old and I am too lazy to go back and downgrade :-) > > > Bruce > Okay, No issues with numpy 1.5.1 under Python 2.7 - given below. I get this error under Python 3.1:' FAIL: test_highpass (test_fir_filter_design.TestFirWinMore)'. This appears to be integer division as the test passes when line 126 of 'scipy/signal/tests/test_fir_filter_design.py' is changed to: assert_array_almost_equal(taps[:ntaps//2], taps[ntaps:ntaps-ntaps//2-1:-1]) Bruce $ python -c "import scipy; scipy.test()" Running unit tests for scipy NumPy version 1.5.1 NumPy is installed in /usr/lib64/python2.7/site-packages/numpy SciPy version 0.9.0b1 SciPy is installed in /usr/lib64/python2.7/site-packages/scipy Python version 2.7 (r27:82500, Sep 16 2010, 18:02:00) [GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] nose version 0.11.2 [snip] ......................................................................... ---------------------------------------------------------------------- Ran 4794 tests in 41.009s OK (KNOWNFAIL=12, SKIP=35) $ python3 -c "import scipy; scipy.test()" Running unit tests for scipy NumPy version 1.5.1 NumPy is installed in /usr/lib64/python3.1/site-packages/numpy SciPy version 0.9.0b1 SciPy is installed in /usr/lib64/python3.1/site-packages/scipy Python version 3.1.2 (r312:79147, Sep 8 2010, 23:02:57) [GCC 4.5.1 20100812 (Red Hat 4.5.1-1)] nose version 3.0.0 [snip] ..............................................................................................................................E ====================================================================== ERROR: Failure: ImportError (No module named c_spec) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python3.1/site-packages/nose/failure.py", line 37, in runTest reraise(self.exc_class, self.exc_val, self.tb) File "/usr/lib/python3.1/site-packages/nose/_3.py", line 7, in reraise raise exc_class(exc_val).with_traceback(tb) File "/usr/lib/python3.1/site-packages/nose/loader.py", line 389, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python3.1/site-packages/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python3.1/site-packages/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/usr/lib64/python3.1/site-packages/scipy/weave/__init__.py", line 13, in from .inline_tools import inline File "/usr/lib64/python3.1/site-packages/scipy/weave/inline_tools.py", line 5, in from . import ext_tools File "/usr/lib64/python3.1/site-packages/scipy/weave/ext_tools.py", line 7, in from . import converters File "/usr/lib64/python3.1/site-packages/scipy/weave/converters.py", line 5, in from . import c_spec File "/usr/lib64/python3.1/site-packages/scipy/weave/c_spec.py", line 380, in import os, c_spec # yes, I import myself to find out my __file__ location. ImportError: No module named c_spec ====================================================================== FAIL: test_highpass (test_fir_filter_design.TestFirWinMore) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python3.1/site-packages/scipy/signal/tests/test_fir_filter_design.py", line 126, in test_highpass assert_array_almost_equal(taps[:ntaps/2], taps[ntaps:ntaps-ntaps/2-1:-1]) File "/usr/lib64/python3.1/site-packages/numpy/testing/utils.py", line 774, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/lib64/python3.1/site-packages/numpy/testing/utils.py", line 579, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (shapes (196,), (197,) mismatch) x: array([ -2.21482814e-21, 9.49475306e-08, -8.72925108e-21, -1.69672728e-07, -2.55604897e-21, 2.73170159e-07, -9.89221963e-22, -4.12424017e-07, 4.88221354e-21,... y: array([ -2.21482814e-21, 9.49475306e-08, -8.72925108e-21, -1.69672728e-07, -2.55604897e-21, 2.73170159e-07, -9.89221963e-22, -4.12424017e-07, 4.88221354e-21,... ---------------------------------------------------------------------- Ran 4657 tests in 42.204s FAILED (KNOWNFAIL=12, SKIP=41, errors=1, failures=1) From ben.root at ou.edu Tue Dec 14 17:07:58 2010 From: ben.root at ou.edu (Benjamin Root) Date: Tue, 14 Dec 2010 16:07:58 -0600 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Tue, Dec 14, 2010 at 2:09 PM, Charles R Harris wrote: > > > On Tue, Dec 14, 2010 at 10:52 AM, Bruce Southey wrote: > >> On Tue, Dec 14, 2010 at 10:13 AM, Ralf Gommers >> wrote: >> > >> > >> > On Wed, Dec 15, 2010 at 12:01 AM, Benjamin Root >> wrote: >> >> >> >> >> >> On Tue, Dec 14, 2010 at 6:38 AM, Ralf Gommers >> >> wrote: >> >>> >> >>> >> >>> On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root >> wrote: >> >>> >> >>> Hi Ben, >> >>>> >> >>>> Just did a clean rebuild (after a clean rebuild of numpy) and had two >> >>>> errors in the tests: >> >>> >> >>> What platform are you on? >> >> >> >> I reran the tests on just this scipy.misc module, here is the output: >> >> >> >> >>> scipy.misc.test() >> >> Running unit tests for scipy.misc >> >> NumPy version 2.0.0.dev-799179d >> >> NumPy is installed in /home/bvr/Programs/numpy/numpy >> >> SciPy version 0.10.0.dev >> >> SciPy is installed in /home/bvr/Programs/scipy/scipy >> >> Python version 2.6.4 (r264:75706, Jun 4 2010, 18:20:16) [GCC 4.4.4 >> >> 20100503 (Red Hat 4.4.4-2)] >> >> nose version 0.11.3 >> >> ...........F..... >> >> ====================================================================== >> >> FAIL: test_imresize (test_pilutil.TestPILUtil) >> >> ---------------------------------------------------------------------- >> >> Traceback (most recent call last): >> >> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line >> 146, >> >> in skipper_func >> >> return f(*args, **kwargs) >> >> File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", >> line >> >> 28, in test_imresize >> >> assert_equal(im1.shape,(11,22)) >> >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, in >> >> assert_equal >> >> assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), >> >> verbose) >> >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, in >> >> assert_equal >> >> raise AssertionError(msg) >> >> AssertionError: >> >> Items are not equal: >> >> item=0 >> >> >> >> ACTUAL: 10 >> >> DESIRED: 11 >> >> >> >> ---------------------------------------------------------------------- >> >> Ran 17 tests in 0.089s >> >> >> >> FAILED (failures=1) >> >> >> >> >> >> Note, that I am still getting this error with the suggested addition of >> >> "np.random.seed(12345678)" to scipy/misc/tests/test_pilutil.py. I >> tried it >> >> both at line 20 (before the call to class TestPILUtil) and at line 24 >> >> (before the call to np.random.random() in test_imresize. I do not see >> how >> >> setting the seed value for these tests would make any difference since >> they >> >> are merely testing the resulting shape of the image after a resize, not >> the >> >> values of the resized image itself. >> > >> > The seeding may not matter (I haven't actually looked in detail yet), >> but I >> > thought I had seen this error pop up before, but not reproducibly. The >> > imresize function does some interpolation, so the numerical values could >> > matter. In that case seeding would help. >> >> >> >> >> >>>> >> >>>> >> ====================================================================== >> >>>> FAIL: test_imresize (test_pilutil.TestPILUtil) >> >>>> >> ---------------------------------------------------------------------- >> >>>> Traceback (most recent call last): >> >>>> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line >> 146, >> >>>> in skipper_func >> >>>> return f(*args, **kwargs) >> >>>> File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", >> line >> >>>> 25, in test_imresize >> >>>> assert_equal(im1.shape,(11,22)) >> >>>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, >> in >> >>>> assert_equal >> >>>> assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), >> >>>> verbose) >> >>>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, >> in >> >>>> assert_equal >> >>>> raise AssertionError(msg) >> >>>> AssertionError: >> >>>> Items are not equal: >> >>>> item=0 >> >>>> >> >>>> ACTUAL: 10 >> >>>> DESIRED: 11 >> >>> >> >>> This test should be changed to use a fixed seed (add as a first line >> of >> >>> the test "np.random.seed(12345678)"). Can you provide one that fails? >> >>> >> >> >> >> Also, I am not sure what you mean by "Can you provide one that fails?". >> > >> > I meant a seed value that fails. This one does, that's all we need. >> >> On my 64-bit linux system with Python 2.7, the error appears comes >> from float16 dtype rather than the actual seed >> >>> np.random.seed(12345678) >> >>> for T in np.sctypes['float'] + [float]: >> ... im1 = pilutil.imresize(im,T(1.1)) >> ... print T, im.shape, im1.shape >> ... >> (10, 20) (10, 21) >> (10, 20) (11, 22) >> (10, 20) (11, 22) >> (10, 20) (11, 22) >> (10, 20) (11, 22) >> >> Here only the float16 has different shape from the rest. >> >> > Ah, you compiled against numpy master instead of numpy 1.5.1, float16 is > only in the development branch. I think the test should be fixed to use an > explicit list of types supported by pilutil. > > Chuck > > > Good eye, Chuck! That is also the case for me. I will give the 1.5.1 build a spin to see if the other error was also dependent on the numpy versions. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Mon Dec 20 09:13:48 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 20 Dec 2010 22:13:48 +0800 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: Message-ID: On Thu, Dec 16, 2010 at 9:14 PM, Ralf Gommers wrote: > > > On Wed, Dec 15, 2010 at 1:52 AM, Bruce Southey wrote: > >> >> There is a print statement in the function test_cg for 'conjugate >> gradient optimization routine' that needs to be commented out: >> See line 70 of scipy-0.9.0b1/scipy/optimize/tests/test_optimize.py: >> 'print self.funccalls, self.gradcalls' >> >> There is a PendingDeprecationWarning with Python2.7 which I can add a >> ticket for if this is non-trivial. Relevant line from verbose=10: >> >> binary dilation 29 ... >> /usr/lib64/python2.7/site-packages/scipy/ndimage/morphology.py:254: >> PendingDeprecationWarning: The CObject type is marked Pending >> Deprecation in Python 2.7. Please use capsule objects instead. >> structure, mask, output, border_value, origin, invert, cit, 1) >> ok >> >> Is it possible to silence the 'ComplexWarning: Casting complex values >> to real discards the imaginary part' message and perhaps the >> 'Warning: divide by zero encountered in log' message while running the >> tests? My reasoning is that these tend to hide real problems. >> > > I plan to work on this before RC1, but I won't have time for it till at > least the second week of January. So if anyone wants to make a start, please > go for it. > > Cheers, > Ralf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Schellart at astro.ru.nl Mon Dec 20 16:27:30 2010 From: P.Schellart at astro.ru.nl (Pim Schellart) Date: Mon, 20 Dec 2010 22:27:30 +0100 Subject: [SciPy-Dev] Lomb-Scargle periodogram Message-ID: Dear SciPy developers, in my research field of Astronomy we often encounter timeseries with uneven temporal sampling. Such timeseries cannot be analyzed with the standard Fast Fourier Transform. The most frequently used tool to analyze such timeseries is the Lomb-Scargle periodogram, developed by Lomb (1976) and further extended by Scargle (1982). Currently, to my knowledge, SciPy does not include a routine to calculate such periodograms. Therefore I would like to contribute the following code which efficiently calculates the periodogram. It is licensed under the terms of the BSD open source license but I would be willing to release it under any other language if this is necessary for possible inclusion with SciPy. The routine is written in Fortran 95 and wrapped with f2py, but I would be willing to rewrite it in C if required. Also included is a Python test script. Please provide me with any feedback in case you would consider including this. Kind regards, Pim Schellart -------------- next part -------------- A non-text attachment was scrubbed... Name: lombscargle.f90 Type: application/octet-stream Size: 4613 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: text/x-python-script Size: 661 bytes Desc: not available URL: From warren.weckesser at enthought.com Tue Dec 21 23:11:37 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Tue, 21 Dec 2010 22:11:37 -0600 Subject: [SciPy-Dev] ANN: SciPy 0.9.0 beta 1 In-Reply-To: References: <4D07D07F.8050003@gmail.com> Message-ID: On Tue, Dec 14, 2010 at 3:23 PM, Bruce Southey wrote: > On Tue, Dec 14, 2010 at 2:15 PM, Bruce Southey wrote: > > On 12/14/2010 02:09 PM, Charles R Harris wrote: > > > > On Tue, Dec 14, 2010 at 10:52 AM, Bruce Southey > wrote: > >> > >> On Tue, Dec 14, 2010 at 10:13 AM, Ralf Gommers > >> wrote: > >> > > >> > > >> > On Wed, Dec 15, 2010 at 12:01 AM, Benjamin Root > wrote: > >> >> > >> >> > >> >> On Tue, Dec 14, 2010 at 6:38 AM, Ralf Gommers > >> >> wrote: > >> >>> > >> >>> > >> >>> On Tue, Dec 14, 2010 at 12:43 AM, Benjamin Root > >> >>> wrote: > >> >>> > >> >>> Hi Ben, > >> >>>> > >> >>>> Just did a clean rebuild (after a clean rebuild of numpy) and had > two > >> >>>> errors in the tests: > >> >>> > >> >>> What platform are you on? > >> >> > >> >> I reran the tests on just this scipy.misc module, here is the output: > >> >> > >> >> >>> scipy.misc.test() > >> >> Running unit tests for scipy.misc > >> >> NumPy version 2.0.0.dev-799179d > >> >> NumPy is installed in /home/bvr/Programs/numpy/numpy > >> >> SciPy version 0.10.0.dev > >> >> SciPy is installed in /home/bvr/Programs/scipy/scipy > >> >> Python version 2.6.4 (r264:75706, Jun 4 2010, 18:20:16) [GCC 4.4.4 > >> >> 20100503 (Red Hat 4.4.4-2)] > >> >> nose version 0.11.3 > >> >> ...........F..... > >> >> > ====================================================================== > >> >> FAIL: test_imresize (test_pilutil.TestPILUtil) > >> >> > ---------------------------------------------------------------------- > >> >> Traceback (most recent call last): > >> >> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line > >> >> 146, > >> >> in skipper_func > >> >> return f(*args, **kwargs) > >> >> File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", > >> >> line > >> >> 28, in test_imresize > >> >> assert_equal(im1.shape,(11,22)) > >> >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, > in > >> >> assert_equal > >> >> assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), > >> >> verbose) > >> >> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, > in > >> >> assert_equal > >> >> raise AssertionError(msg) > >> >> AssertionError: > >> >> Items are not equal: > >> >> item=0 > >> >> > >> >> ACTUAL: 10 > >> >> DESIRED: 11 > >> >> > >> >> > ---------------------------------------------------------------------- > >> >> Ran 17 tests in 0.089s > >> >> > >> >> FAILED (failures=1) > >> >> > >> >> > >> >> Note, that I am still getting this error with the suggested addition > of > >> >> "np.random.seed(12345678)" to scipy/misc/tests/test_pilutil.py. I > >> >> tried it > >> >> both at line 20 (before the call to class TestPILUtil) and at line 24 > >> >> (before the call to np.random.random() in test_imresize. I do not > see > >> >> how > >> >> setting the seed value for these tests would make any difference > since > >> >> they > >> >> are merely testing the resulting shape of the image after a resize, > not > >> >> the > >> >> values of the resized image itself. > >> > > >> > The seeding may not matter (I haven't actually looked in detail yet), > >> > but I > >> > thought I had seen this error pop up before, but not reproducibly. The > >> > imresize function does some interpolation, so the numerical values > could > >> > matter. In that case seeding would help. > >> >> > >> >> > >> >>>> > >> >>>> > >> >>>> > ====================================================================== > >> >>>> FAIL: test_imresize (test_pilutil.TestPILUtil) > >> >>>> > >> >>>> > ---------------------------------------------------------------------- > >> >>>> Traceback (most recent call last): > >> >>>> File "/home/bvr/Programs/numpy/numpy/testing/decorators.py", line > >> >>>> 146, > >> >>>> in skipper_func > >> >>>> return f(*args, **kwargs) > >> >>>> File "/home/bvr/Programs/scipy/scipy/misc/tests/test_pilutil.py", > >> >>>> line > >> >>>> 25, in test_imresize > >> >>>> assert_equal(im1.shape,(11,22)) > >> >>>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 251, > >> >>>> in > >> >>>> assert_equal > >> >>>> assert_equal(actual[k], desired[k], 'item=%r\n%s' % > (k,err_msg), > >> >>>> verbose) > >> >>>> File "/home/bvr/Programs/numpy/numpy/testing/utils.py", line 313, > >> >>>> in > >> >>>> assert_equal > >> >>>> raise AssertionError(msg) > >> >>>> AssertionError: > >> >>>> Items are not equal: > >> >>>> item=0 > >> >>>> > >> >>>> ACTUAL: 10 > >> >>>> DESIRED: 11 > >> >>> > >> >>> This test should be changed to use a fixed seed (add as a first line > >> >>> of > >> >>> the test "np.random.seed(12345678)"). Can you provide one that > fails? > >> >>> > >> >> > >> >> Also, I am not sure what you mean by "Can you provide one that > fails?". > >> > > >> > I meant a seed value that fails. This one does, that's all we need. > >> > >> On my 64-bit linux system with Python 2.7, the error appears comes > >> from float16 dtype rather than the actual seed > >> >>> np.random.seed(12345678) > >> >>> for T in np.sctypes['float'] + [float]: > >> ... im1 = pilutil.imresize(im,T(1.1)) > >> ... print T, im.shape, im1.shape > >> ... > >> (10, 20) (10, 21) > >> (10, 20) (11, 22) > >> (10, 20) (11, 22) > >> (10, 20) (11, 22) > >> (10, 20) (11, 22) > >> > >> Here only the float16 has different shape from the rest. > >> > > > > Ah, you compiled against numpy master instead of numpy 1.5.1, float16 is > > only in the development branch. I think the test should be fixed to use > an > > explicit list of types supported by pilutil. > > > > Chuck > > > > > > Sorry, > > I forgot to add the numpy version '2.0.0.dev-799179d' because 1.5.1 is > just > > too old and I am too lazy to go back and downgrade :-) > > > > > > Bruce > > > > Okay, > No issues with numpy 1.5.1 under Python 2.7 - given below. > > I get this error under Python 3.1:' FAIL: test_highpass > (test_fir_filter_design.TestFirWinMore)'. > This appears to be integer division as the test passes when line 126 > of 'scipy/signal/tests/test_fir_filter_design.py' is changed to: > assert_array_almost_equal(taps[:ntaps//2], taps[ntaps:ntaps-ntaps//2-1:-1]) > > Bruce > > $ python -c "import scipy; scipy.test()" > Running unit tests for scipy > NumPy version 1.5.1 > NumPy is installed in /usr/lib64/python2.7/site-packages/numpy > SciPy version 0.9.0b1 > SciPy is installed in /usr/lib64/python2.7/site-packages/scipy > Python version 2.7 (r27:82500, Sep 16 2010, 18:02:00) [GCC 4.5.1 > 20100907 (Red Hat 4.5.1-3)] > nose version 0.11.2 > [snip] > ......................................................................... > ---------------------------------------------------------------------- > Ran 4794 tests in 41.009s > > OK (KNOWNFAIL=12, SKIP=35) > > > $ python3 -c "import scipy; scipy.test()" > Running unit tests for scipy > NumPy version 1.5.1 > NumPy is installed in /usr/lib64/python3.1/site-packages/numpy > SciPy version 0.9.0b1 > SciPy is installed in /usr/lib64/python3.1/site-packages/scipy > Python version 3.1.2 (r312:79147, Sep 8 2010, 23:02:57) [GCC 4.5.1 > 20100812 (Red Hat 4.5.1-1)] > nose version 3.0.0 > [snip] > > > ..............................................................................................................................E > ====================================================================== > ERROR: Failure: ImportError (No module named c_spec) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python3.1/site-packages/nose/failure.py", line 37, in > runTest > reraise(self.exc_class, self.exc_val, self.tb) > File "/usr/lib/python3.1/site-packages/nose/_3.py", line 7, in reraise > raise exc_class(exc_val).with_traceback(tb) > File "/usr/lib/python3.1/site-packages/nose/loader.py", line 389, in > loadTestsFromName > addr.filename, addr.module) > File "/usr/lib/python3.1/site-packages/nose/importer.py", line 39, > in importFromPath > return self.importFromDir(dir_path, fqname) > File "/usr/lib/python3.1/site-packages/nose/importer.py", line 86, > in importFromDir > mod = load_module(part_fqname, fh, filename, desc) > File "/usr/lib64/python3.1/site-packages/scipy/weave/__init__.py", > line 13, in > from .inline_tools import inline > File "/usr/lib64/python3.1/site-packages/scipy/weave/inline_tools.py", > line 5, in > from . import ext_tools > File "/usr/lib64/python3.1/site-packages/scipy/weave/ext_tools.py", > line 7, in > from . import converters > File "/usr/lib64/python3.1/site-packages/scipy/weave/converters.py", > line 5, in > from . import c_spec > File "/usr/lib64/python3.1/site-packages/scipy/weave/c_spec.py", > line 380, in > import os, c_spec # yes, I import myself to find out my __file__ > location. > ImportError: No module named c_spec > > ====================================================================== > FAIL: test_highpass (test_fir_filter_design.TestFirWinMore) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/lib64/python3.1/site-packages/scipy/signal/tests/test_fir_filter_design.py", > line 126, in test_highpass > assert_array_almost_equal(taps[:ntaps/2], > taps[ntaps:ntaps-ntaps/2-1:-1]) > File "/usr/lib64/python3.1/site-packages/numpy/testing/utils.py", > line 774, in assert_array_almost_equal > header='Arrays are not almost equal') > File "/usr/lib64/python3.1/site-packages/numpy/testing/utils.py", > line 579, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Arrays are not almost equal > > (shapes (196,), (197,) mismatch) > x: array([ -2.21482814e-21, 9.49475306e-08, -8.72925108e-21, > -1.69672728e-07, -2.55604897e-21, 2.73170159e-07, > -9.89221963e-22, -4.12424017e-07, 4.88221354e-21,... > y: array([ -2.21482814e-21, 9.49475306e-08, -8.72925108e-21, > -1.69672728e-07, -2.55604897e-21, 2.73170159e-07, > -9.89221963e-22, -4.12424017e-07, 4.88221354e-21,... > > ---------------------------------------------------------------------- > Ran 4657 tests in 42.204s > > FAILED (KNOWNFAIL=12, SKIP=41, errors=1, failures=1) > In r7019, I updated test_fir_filter_design.py in trunk to use explicit integer division where appropriate. Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Wed Dec 22 13:20:51 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Wed, 22 Dec 2010 12:20:51 -0600 Subject: [SciPy-Dev] Lomb-Scargle periodogram In-Reply-To: References: Message-ID: On Mon, Dec 20, 2010 at 3:27 PM, Pim Schellart wrote: > Dear SciPy developers, > > in my research field of Astronomy we often encounter timeseries with uneven > temporal sampling. > Such timeseries cannot be analyzed with the standard Fast Fourier > Transform. > The most frequently used tool to analyze such timeseries is the > Lomb-Scargle periodogram, developed by Lomb (1976) and further extended by > Scargle (1982). > Currently, to my knowledge, SciPy does not include a routine to calculate > such periodograms. > Therefore I would like to contribute the following code which efficiently > calculates the periodogram. > It is licensed under the terms of the BSD open source license but I would > be willing to release it under any other language if this is necessary for > possible inclusion with SciPy. > The routine is written in Fortran 95 and wrapped with f2py, but I would be > willing to rewrite it in C if required. > Also included is a Python test script. > Please provide me with any feedback in case you would consider including > this. > > Pim, I think an implementation of Lomb-Scargle and related algorithms would be a great addition to SciPy. With the 0.9 release coming soon, and also being holiday season, I'm not sure how soon anyone will be able to look at your code. Could you add this as an enhancement request to the Trac system? Here's the link: http://projects.scipy.org/scipy/wiki Create an account, and then create a new ticket. You can attach the code to the ticket. Best regards, Warren P.S. There is a python/numpy implementation here: http://www.astropython.org/snippet/2010/9/Fast-Lomb-Scargle-algorithm -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Wed Dec 22 13:38:13 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 22 Dec 2010 13:38:13 -0500 Subject: [SciPy-Dev] Lomb-Scargle periodogram In-Reply-To: References: Message-ID: On Wed, Dec 22, 2010 at 1:20 PM, Warren Weckesser wrote: > > > On Mon, Dec 20, 2010 at 3:27 PM, Pim Schellart > wrote: >> >> Dear SciPy developers, >> >> in my research field of Astronomy we often encounter timeseries with >> uneven temporal sampling. >> Such timeseries cannot be analyzed with the standard Fast Fourier >> Transform. >> The most frequently used tool to analyze such timeseries is the >> Lomb-Scargle periodogram, developed by Lomb (1976) and further extended by >> Scargle (1982). >> Currently, to my knowledge, SciPy does not include a routine to calculate >> such periodograms. >> Therefore I would like to contribute the following code which efficiently >> calculates the periodogram. >> It is licensed under the terms of the BSD open source license but I would >> be willing to release it under any other language if this is necessary for >> possible inclusion with SciPy. >> The routine is written in Fortran 95 and wrapped with f2py, but I would be >> willing to rewrite it in C if required. >> Also included is a Python test script. >> Please provide me with any feedback in case you would consider including >> this. >> > > > Pim, > > I think an implementation of Lomb-Scargle and related algorithms would be a > great addition to SciPy.? With the 0.9 release coming soon, and also being > holiday season, I'm not sure how soon anyone will be able to look at your > code.? Could you add this as an enhancement request to the Trac system? > Here's the link: > > ??? http://projects.scipy.org/scipy/wiki > > Create an account, and then create a new ticket.? You can attach the code to > the ticket. > > Best regards, > > Warren > > P.S.? There is a python/numpy implementation here: > > ??? http://www.astropython.org/snippet/2010/9/Fast-Lomb-Scargle-algorithm I would also be interested, but I am, like scipy, still on fortran 77, g77 on older MingW Josef > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > From fabian.pedregosa at inria.fr Thu Dec 23 00:05:04 2010 From: fabian.pedregosa at inria.fr (Fabian Pedregosa) Date: Thu, 23 Dec 2010 06:05:04 +0100 Subject: [SciPy-Dev] ANN: scikits.learn 0.6 Message-ID: I am very pleased to announce the 0.6 release of scikits.learn, a Python module for machine learning. Documentation: http://scikit-learn.sourceforge.net Git: http://github.com/scikit-learn/scikit-learn/ Mailing list: https://lists.sourceforge.net/lists/listinfo/scikit-learn-general Installation --------- Source packages and precompiled windows binaries can be downloaded from sourceforge: https://sourceforge.net/projects/scikit-learn/files/ or installed through pip: pip install -U scikits.learn Changelog ---------- A complete changelog for this release can be found here: http://scikit-learn.sourceforge.net/whats_new.html Best regards, Fabian. From P.Schellart at astro.ru.nl Thu Dec 23 11:23:29 2010 From: P.Schellart at astro.ru.nl (Pim Schellart) Date: Thu, 23 Dec 2010 17:23:29 +0100 Subject: [SciPy-Dev] Ticket created for Lomb-Scargle periodogram Message-ID: Dear SciPy developers, as requested I created an enhancement ticket (http://projects.scipy.org/scipy/ticket/1352). I attached FORTRAN 95, FORTRAN 77 and ANSI C versions of the subroutine, so you may pick your favorite language :) Just let me know what the next step (if any) should be. Merry Christmas! Regards, Pim Schellart From cohen at lpta.in2p3.fr Fri Dec 24 03:59:00 2010 From: cohen at lpta.in2p3.fr (Johann Cohen-Tanugi) Date: Fri, 24 Dec 2010 09:59:00 +0100 Subject: [SciPy-Dev] Ticket created for Lomb-Scargle periodogram In-Reply-To: References: Message-ID: <4D1460D4.5040909@lpta.in2p3.fr> hi there, I did not look at the code, sorry, but is it the original LS periodogram, or the generalized one? best, Johann On 12/23/2010 05:23 PM, Pim Schellart wrote: > Dear SciPy developers, > > as requested I created an enhancement ticket (http://projects.scipy.org/scipy/ticket/1352). > I attached FORTRAN 95, FORTRAN 77 and ANSI C versions of the subroutine, so you may pick your favorite language :) > Just let me know what the next step (if any) should be. > Merry Christmas! > > Regards, > > Pim Schellart > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From P.Schellart at astro.ru.nl Fri Dec 24 14:45:32 2010 From: P.Schellart at astro.ru.nl (Pim Schellart) Date: Fri, 24 Dec 2010 20:45:32 +0100 Subject: [SciPy-Dev] Ticket created for Lomb-Scargle periodogram In-Reply-To: References: Message-ID: The code I submitted is for the original Lomb-Scargle periodogram. The equations themselves were only refactored to allow the periodogram to be calculated using only a single pass through the input arrays for each frequency. It might be possible to also add code for the generalized periodogram, although that is slightly more complicated because it involves several integrals, I'll have a look. Regards, Pim Schellart On Dec 24, 2010, at 7:00 PM, scipy-dev-request at scipy.org wrote: > Send SciPy-Dev mailing list submissions to > scipy-dev at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request at scipy.org > > You can reach the person managing the list at > scipy-dev-owner at scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. Re: Ticket created for Lomb-Scargle periodogram > (Johann Cohen-Tanugi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 24 Dec 2010 09:59:00 +0100 > From: Johann Cohen-Tanugi > Subject: Re: [SciPy-Dev] Ticket created for Lomb-Scargle periodogram > To: SciPy Developers List > Cc: Pim Schellart > Message-ID: <4D1460D4.5040909 at lpta.in2p3.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > hi there, I did not look at the code, sorry, but is it the original LS > periodogram, or the generalized one? > > best, > Johann > > On 12/23/2010 05:23 PM, Pim Schellart wrote: >> Dear SciPy developers, >> >> as requested I created an enhancement ticket (http://projects.scipy.org/scipy/ticket/1352). >> I attached FORTRAN 95, FORTRAN 77 and ANSI C versions of the subroutine, so you may pick your favorite language :) >> Just let me know what the next step (if any) should be. >> Merry Christmas! >> >> Regards, >> >> Pim Schellart >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> > > > ------------------------------ > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > End of SciPy-Dev Digest, Vol 86, Issue 20 > ***************************************** From ben.root at ou.edu Fri Dec 31 14:30:13 2010 From: ben.root at ou.edu (Benjamin Root) Date: Fri, 31 Dec 2010 13:30:13 -0600 Subject: [SciPy-Dev] Bug in KDTree In-Reply-To: References: Message-ID: On Fri, Dec 10, 2010 at 4:54 PM, Benjamin Root wrote: > Hello, > > I came across an issue using KDTree. I searched the bug list, and it > appears that there has already been a patch submitted for review. I have > added comments to the bug report and I think the patch is good to go. I am > not an expert in KDTree myself, but I think the logic is sound. > > http://projects.scipy.org/scipy/ticket/1052 > > If the first node of the tree is a leafnode, then query_pairs() will fail > if the points are closer than the distance threshold. This is because the > algorithm is assuming that the first node will always be an innernode. By > rearranging the if-statements so that a check for a leafnode is done first, > you protect against such a situation. > > At least, that is my understanding. I welcome comments on this. > > Thanks, > Ben Root > I am re-pinging this. Is there any chance this will make it to the upcoming release? I am very certain the patch given 6 months ago is correct. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: