From cimrman3 at ntc.zcu.cz Thu Aug 2 06:10:17 2012 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Thu, 02 Aug 2012 12:10:17 +0200 Subject: [SciPy-Dev] scipy.linalg.lapack + C(ython) Message-ID: <501A5209.8010508@ntc.zcu.cz> Hi, I need to write a C or Cython extension module that would involve repeated solves of a linear system with a dense matrix. For this, I would like to use the LAPACK function pointers provided by SciPy, to avoid dealing with LAPACK installation myself. I am aware of [1] so I know how to get to the right LAPACK function pointer, but it would help me a lot to look at an existing Cython or C code - has anyone done something similar? Best regards, r. [1] http://mail.scipy.org/pipermail/numpy-discussion/2012-March/061236.html From gael.varoquaux at normalesup.org Thu Aug 2 06:12:11 2012 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 2 Aug 2012 12:12:11 +0200 Subject: [SciPy-Dev] scipy.linalg.lapack + C(ython) In-Reply-To: <501A5209.8010508@ntc.zcu.cz> References: <501A5209.8010508@ntc.zcu.cz> Message-ID: <20120802101211.GA3358@phare.normalesup.org> Maybe Tokyo can be useful: http://www.vetta.org/2009/09/tokyo-a-cython-blas-wrapper-for-fast-matrix-math/ G On Thu, Aug 02, 2012 at 12:10:17PM +0200, Robert Cimrman wrote: > I need to write a C or Cython extension module that would involve repeated > solves of a linear system with a dense matrix. For this, I would like to use > the LAPACK function pointers provided by SciPy, to avoid dealing with LAPACK > installation myself. > I am aware of [1] so I know how to get to the right LAPACK function > pointer, but it would help me a lot to look at an existing Cython or C > code - has anyone done something similar? From cimrman3 at ntc.zcu.cz Thu Aug 2 09:49:47 2012 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Thu, 02 Aug 2012 15:49:47 +0200 Subject: [SciPy-Dev] scipy.linalg.lapack + C(ython) In-Reply-To: <20120802101211.GA3358@phare.normalesup.org> References: <501A5209.8010508@ntc.zcu.cz> <20120802101211.GA3358@phare.normalesup.org> Message-ID: <501A857B.1070102@ntc.zcu.cz> On 08/02/2012 12:12 PM, Gael Varoquaux wrote: > Maybe Tokyo can be useful: > http://www.vetta.org/2009/09/tokyo-a-cython-blas-wrapper-for-fast-matrix-math/ Thanks, Gael, for the link! It does not wrap lapack, but it shows a way. r. > G > > On Thu, Aug 02, 2012 at 12:10:17PM +0200, Robert Cimrman wrote: >> I need to write a C or Cython extension module that would involve repeated >> solves of a linear system with a dense matrix. For this, I would like to use >> the LAPACK function pointers provided by SciPy, to avoid dealing with LAPACK >> installation myself. > >> I am aware of [1] so I know how to get to the right LAPACK function >> pointer, but it would help me a lot to look at an existing Cython or C >> code - has anyone done something similar? From santosh.singh at ansys.com Fri Aug 3 07:59:22 2012 From: santosh.singh at ansys.com (Santosh Pratap Singh) Date: Fri, 3 Aug 2012 17:29:22 +0530 Subject: [SciPy-Dev] Unable to compile scipy for python 2.7 ( VC8 and Intel Fortran compiler) on win64. Message-ID: Greetings EveryOne, I am compiling SciPy (With BLAS and LAPACK Support) with the following 1: Python2.7 2: VC8 3: Intel Fortran I start compiling with this commands : 1: set BLAS=F:\scipy\scipy-0.10.1\blas.lib 2: set LAPACK=F:\scipy\scipy-0.10.1\lapack.lib (The blas.lib and lapack.lib I have copied from intel installation C:\Program Files (x86)\Intel\Composer XE 2011 SP1\mkl\lib\intel64\mkl_blas95_lp64.lib and C:\Program Files (x86)\Intel\Composer XE 2011 SP1\mkl\lib\intel64\mkl_blas95_lp64.lib respectively) 3: python setup.py install Seems like the compilation goes fine but I am getting issue while linking *link command:* C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:F:\scipy\scipy-0.10.1 /LIBPATH:F:\TeamcityBuilds\FluxBuilds\AFD15.0\CPython\2_7_3\winx64\Release\python\libs /LIBPATH:F:\TeamcityBuilds\FluxBuilds\AFD15.0\CPython\2_7_3\winx64\Release\python\PCbuild\amd64 /LIBPATH:build\temp.win-amd64-2.7 /LIBPATH:F:\TeamcityBuilds\FluxBuilds\AFD15.0\CPython\2_7_3\winx64\Release\python\libs /LIBPATH:F:\TeamcityBuilds\FluxBuilds\AFD15.0\CPython\2_7_3\winx64\Release\python\PCbuild\amd64 /LIBPATH:build\temp.win-amd64-2.7 odepack.lib linpack_lite.lib mach.lib blas.lib python27.lib /EXPORT:init_odepack build\temp.win-amd64-2.7\Release\scipy\integrate\_odepackmodule.obj /OUT:build\lib.win-amd64-2.7\scipy\integrate\_odepack.pyd /IMPLIB:build\temp.win-amd64-2.7\Release\scipy\integrate\_odepack.lib /MANIFESTFILE:build\temp.win-amd64-2.7\Release\scipy\integrate\_odepack.pyd.manifest *Error:* Found executable C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\link.exe _odepackmodule.obj : warning LNK4197: export 'init_odepack' specified multiple times; using first specification Creating library build\temp.win-amd64-2.7\Release\scipy\integrate\_odepack.lib and object build\temp.win-amd64-2.7\Release\scipy\integrate\_odepack.exp odepack.lib(vode.o) : error LNK2019: unresolved external symbol dcopy_ referenced in function dvode_ odepack.lib(vode.o) : error LNK2019: unresolved external symbol dscal_ referenced in function dvode_ linpack_lite.lib(dgbfa.o) : error LNK2001: unresolved external symbol dscal_ linpack_lite.lib(dgefa.o) : error LNK2001: unresolved external symbol dscal_ linpack_lite.lib(dgesl.o) : error LNK2001: unresolved external symbol daxpy_ odepack.lib(vode.o) : error LNK2019: unresolved external symbol daxpy_ referenced in function dvstep_ linpack_lite.lib(dgbfa.o) : error LNK2001: unresolved external symbol daxpy_ linpack_lite.lib(dgefa.o) : error LNK2001: unresolved external symbol daxpy_ linpack_lite.lib(dgbsl.o) : error LNK2001: unresolved external symbol daxpy_ linpack_lite.lib(dgbfa.o) : error LNK2019: unresolved external symbol idamax_ referenced in function dgbfa_ linpack_lite.lib(dgefa.o) : error LNK2001: unresolved external symbol idamax_ linpack_lite.lib(dgbsl.o) : error LNK2019: unresolved external symbol ddot_ referenced in function dgbsl_ linpack_lite.lib(dgesl.o) : error LNK2001: unresolved external symbol ddot_ build\lib.win-amd64-2.7\scipy\integrate\_odepack.pyd : fatal error LNK1120: 5 unresolved externals error: Command "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:F:\scipy\scipy-0.10.1 /LIBPATH:F:\TeamcityBuilds\FluxBuilds\AFD15.0\CPython\2_7_3\winx64\Release\python\libs /LIBPATH:F:\TeamcityBuilds\FluxBuilds\AFD15.0\CPython\2_7_3\winx64\Release\python\PCbuild\amd64 /LIBPATH:build\temp.win-amd64-2.7 /LIBPATH:F:\TeamcityBuilds\FluxBuilds\AFD15.0\CPython\2_7_3\winx64\Release\python\libs /LIBPATH:F:\TeamcityBuilds\FluxBuilds\AFD15.0\CPython\2_7_3\winx64\Release\python\PCbuild\amd64 /LIBPATH:build\temp.win-amd64-2.7 odepack.lib linpack_lite.lib mach.lib blas.lib python27.lib /EXPORT:init_odepack build\temp.win-amd64-2.7\Release\scipy\integrate\_odepackmodule.obj /OUT:build\lib.win-amd64-2.7\scipy\integrate\_odepack.pyd /IMPLIB:build\temp.win-amd64-2.7\Release\scipy\integrate\_odepack.lib /MANIFESTFILE:build\temp.win-amd64-2.7\Release\scipy\integrate\_odepack.pyd.manifest" failed with exit status 1120 I have also attached the log file for more details. I will really appreciate if someone tell me the exact steps I should follow. Thanks. Santosh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 21000 bytes Desc: not available URL: From ralf.gommers at googlemail.com Sat Aug 4 07:06:05 2012 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 4 Aug 2012 13:06:05 +0200 Subject: [SciPy-Dev] Contributing to SciPy? In-Reply-To: References: Message-ID: On Sun, Jul 29, 2012 at 2:23 PM, Thomas Haslwanter < thomas.haslwanter at alumni.ethz.ch> wrote: > Hi, > I found an error on the SciPy Cookbook (described below), and wanted to > fix it. > So I wrote a corrected version and a unittest procedure. But now I don't > know > how I can submit/contribute it to SciPy. (BTW, the wiki did not let me to > change > it, even after I registered.) That's odd. Can other people edit that page (I can)? > Is the only way to pull the whole sourcecode, > install Fortran and C++ compilers, etc? Or can I just submit Python code? > Please let me know. > > The Cookbook isn't part of the SciPy source code, so in this case the only way is to edit the wiki page. Or open a ticket as you did: http://projects.scipy.org/scipy/ticket/1706 If your question is how you would go about adding this function in scipy.signal, which as I noted on #1706 was discussed before, you can attach patches to Trac. The better way (i.e. lower overhead for scipy devs) would indeed be to use git and send a pull request. How to do that is described at https://github.com/scipy/scipy/blob/master/HACKING.rst.txt. Ralf The problem: > The Cookbook entry > http://www.scipy.org/Cookbook/SavitzkyGolay > has a number of problems: > > 1) As it is, it does in general not run. The line > "import numpy as np" > should be inserted before the first "try" in line 49 > > 2) I don't completely understand the workings of the code. However, when > you put in a sine-wave and calculate the first derivative, you get out > a negative(!) cosine - not a cosine. The correct result appears if you > replace "m," in line 68 with "m[::-1]," > > Since the Savitzky-Golay filter is a very commonly used filter, I regard > this mistake as significant. > > thomas > > _______________________________________________ > 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 gmail.com Mon Aug 6 17:21:34 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 6 Aug 2012 23:21:34 +0200 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.11.0 release candidate 1 In-Reply-To: References: <50096161.8060207@comcast.net> <5009BE8A.3080902@comcast.net> <5009C6DF.2030806@iki.fi> <500AE520.6030507@comcast.net> Message-ID: On Mon, Jul 30, 2012 at 10:36 PM, Ralf Gommers wrote: > > > On Sat, Jul 21, 2012 at 7:21 PM, John Hassler wrote: > >> >> On 7/20/2012 5:00 PM, Pauli Virtanen wrote: >> > 20.07.2012 22:24, John Hassler kirjoitti: >> >> The offending line is: >> >> AA,BB,Q,Z,sdim = qz(A,B,sort=sort) >> >> >> >> I couldn't find 'sort' defined anywhere, so I arbitrarily changed it to >> >> sort='lhp'. Then it runs, although the test fails. >> >> >> >> Is there something else I can try? >> > Seems to be a problem with the callable sort function then. >> > >> > That it works with sort='lhp' is strange, and probably means that there >> > is not a problem with all callback functions, but something goes wrong >> > in the algorithm. (Which would be expected, if *gees callbacks work >> > without problems.) >> > >> > If you can/know how to recompile, try recompiling with >> > >> > set OPT=-g -DDEBUGCFUNCS >> > python setup.py ......... >> > >> > This should make the f2py wrappers spit out extra information on what is >> > going on. >> > >> I'm not set up to recompile. > > > Is there anyone who can reproduce the issue and investigate this further? > Alternatively I can build some binaries with the above debug flags. I can't > reproduce the issue though, so that may be a painful way to debug. > I have been able to reproduce this now. Some tracebacks and details at http://projects.scipy.org/scipy/ticket/1717. If anyone has some ideas, shoot! Ralf > Ralf > > > >> I set up a little test program to >> reproduce the problem (below). It leads to the Fortran call to gges in >> _decomp_qz.py. This crashes if sort_t = 1 (which calls the lambda), but >> not for sort_t = 0. I didn't play with it any further. >> john >> >> # Test qz >> import numpy as np >> from scipy.linalg import qz >> >> A = np.array([[3.9, 12.5, -34.5, -0.5], >> [ 4.3, 21.5, -47.5, 7.5], >> [ 4.3, 21.5, -43.5, 3.5], >> [ 4.4, 26.0, -46.0, 6.0 ]]) >> >> B = np.array([[ 1.0, 2.0, -3.0, 1.0], >> [1.0, 3.0, -5.0, 4.0], >> [1.0, 3.0, -4.0, 3.0], >> [1.0, 3.0, -4.0, 4.0]]) >> >> >> #sort = lambda ar,ai,beta : ai == 0 ## crashes >> sort = None ## runs >> >> print(qz(A,B,sort=sort)) >> >> _______________________________________________ >> SciPy-User mailing list >> SciPy-User at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Aug 6 18:40:39 2012 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 07 Aug 2012 00:40:39 +0200 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.11.0 release candidate 1 In-Reply-To: References: <50096161.8060207@comcast.net> <5009BE8A.3080902@comcast.net> <5009C6DF.2030806@iki.fi> <500AE520.6030507@comcast.net> Message-ID: 06.08.2012 23:21, Ralf Gommers kirjoitti: > On Mon, Jul 30, 2012 at 10:36 PM, Ralf Gommers wrote: [clip] > I have been able to reproduce this now. Some tracebacks and details at > http://projects.scipy.org/scipy/ticket/1717. If anyone has some ideas, > shoot! If I understand correctly, this bug only occurs with the SSE3 binaries in our vendor repo. I should try to reproduce this also. Compiling with DEBUGFLAGS seems not to have worked out in your case. The f2py wrappers should spew out a lot of debug prints, if compiled with the correct debug #define enabled. The second thing is a longer shot, but wine does have a debugger, and obtaining a traceback from that could help. Or possibly not. Pauli From cell at michaelclerx.com Tue Aug 7 09:49:44 2012 From: cell at michaelclerx.com (Michael Clerx) Date: Tue, 07 Aug 2012 15:49:44 +0200 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" Message-ID: <50211CF8.9020108@michaelclerx.com> Dear all, First of all, scipy.org appears to be down and has been for some time today. Yesterday, when it was still up, I registered an account and tried adding a link to the topical software section but got the error "too many links". Does anybody know how/if I can fix this? kind regards, Michael From daniel.wheeler2 at gmail.com Tue Aug 7 09:49:35 2012 From: daniel.wheeler2 at gmail.com (Daniel Wheeler) Date: Tue, 7 Aug 2012 09:49:35 -0400 Subject: [SciPy-Dev] scipy.linalg.lapack + C(ython) In-Reply-To: <501A5209.8010508@ntc.zcu.cz> References: <501A5209.8010508@ntc.zcu.cz> Message-ID: On Thu, Aug 2, 2012 at 6:10 AM, Robert Cimrman wrote: > Hi, > > I need to write a C or Cython extension module that would involve repeated > solves of a linear system with a dense matrix. For this, I would like to > use > the LAPACK function pointers provided by SciPy, to avoid dealing with > LAPACK > installation myself. > > I am aware of [1] so I know how to get to the right LAPACK function > pointer, > but it would help me a lot to look at an existing Cython or C code - has > anyone > done something similar? > This may or may not help you. I set this up for doing multiple small matrix calculations. < http://matforge.org/fipy/browser/branches/riemann/fipy/tools/smallMatrixVectorOpsExt.pyx > and < http://matforge.org/fipy/browser/branches/riemann/fipy/tools/smallMatrixVectorOps.py > and Cheers -- Daniel Wheeler -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Tue Aug 7 11:57:30 2012 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Tue, 7 Aug 2012 10:57:30 -0500 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: <50211CF8.9020108@michaelclerx.com> References: <50211CF8.9020108@michaelclerx.com> Message-ID: scipy.org. is back up. I don't know about the "too many links" problem. That might be a limitation of the wiki software. Warren On Tue, Aug 7, 2012 at 8:49 AM, Michael Clerx wrote: > Dear all, > > First of all, scipy.org appears to be down and has been for some time > today. > > Yesterday, when it was still up, I registered an account and tried > adding a link to the topical software section but got the error "too > many links". Does anybody know how/if I can fix this? > > kind regards, > Michael > > > _______________________________________________ > 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 sturla at molden.no Tue Aug 7 11:59:47 2012 From: sturla at molden.no (Sturla Molden) Date: Tue, 07 Aug 2012 17:59:47 +0200 Subject: [SciPy-Dev] scipy.linalg.lapack + C(ython) In-Reply-To: <501A5209.8010508@ntc.zcu.cz> References: <501A5209.8010508@ntc.zcu.cz> Message-ID: <50213B73.9000307@molden.no> On 02.08.2012 12:10, Robert Cimrman wrote: > I need to write a C or Cython extension module that would involve repeated > solves of a linear system with a dense matrix. For this, I would like to use > the LAPACK function pointers provided by SciPy, to avoid dealing with LAPACK > installation myself. > > I am aware of [1] so I know how to get to the right LAPACK function pointer, > but it would help me a lot to look at an existing Cython or C code - has anyone > done something similar? Personally I feel that using the official C interfaces to BLAS and LAPACK (i.e. CBLAS and LAPACKE) are easier than dealing with Fortran interfaces (when using C or Cython). Particularly integer size and name mangling tend to very between Fortran compilers. With CBLAS and LAPACKE we know what the interface is in C, independent of the Fortran implementation. We can even use arrays that are C ordered, which most NumPy programs do. Sturla From ralf.gommers at gmail.com Tue Aug 7 15:14:47 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 7 Aug 2012 21:14:47 +0200 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.11.0 release candidate 1 In-Reply-To: References: <50096161.8060207@comcast.net> <5009BE8A.3080902@comcast.net> <5009C6DF.2030806@iki.fi> <500AE520.6030507@comcast.net> Message-ID: On Tue, Aug 7, 2012 at 12:40 AM, Pauli Virtanen wrote: > 06.08.2012 23:21, Ralf Gommers kirjoitti: > > On Mon, Jul 30, 2012 at 10:36 PM, Ralf Gommers wrote: > [clip] > > I have been able to reproduce this now. Some tracebacks and details at > > http://projects.scipy.org/scipy/ticket/1717. If anyone has some ideas, > > shoot! > > If I understand correctly, this bug only occurs with the SSE3 binaries > in our vendor repo. I should try to reproduce this also. > > Compiling with DEBUGFLAGS seems not to have worked out in your case. The > f2py wrappers should spew out a lot of debug prints, if compiled with > the correct debug #define enabled. > So where does f2py get its flags from? Since I can't set env variables in wine the way you suggested, I added this flag to the following items in "executables" in numpy/distutils/gnu.py (and checked that they were present in the build log): 'compiler_f77' 'compiler_f90' 'linker_so' 'linker_exe' Ralf > The second thing is a longer shot, but wine does have a debugger, and > obtaining a traceback from that could help. Or possibly not. > > Pauli > > > _______________________________________________ > 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 scott.sinclair.za at gmail.com Wed Aug 8 02:55:15 2012 From: scott.sinclair.za at gmail.com (Scott Sinclair) Date: Wed, 8 Aug 2012 08:55:15 +0200 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: <50211CF8.9020108@michaelclerx.com> References: <50211CF8.9020108@michaelclerx.com> Message-ID: On 7 August 2012 15:49, Michael Clerx wrote: > First of all, scipy.org appears to be down and has been for some time today. > > Yesterday, when it was still up, I registered an account and tried > adding a link to the topical software section but got the error "too > many links". Does anybody know how/if I can fix this? One fix might be to kill all the dead links (there are plenty, see http://validator.w3.org/checklink?uri=http%3A%2F%2Fscipy.org%2FTopical_Software&hide_type=all&depth=&check=Check). I wasted 30 minutes starting to do this a few days ago, but lost my changes to an internal server error. I'll have another go sometime, but not this week. The other (better) alternative is to split the sections into several pages and prune dead links at the same time. This sort of clean-up would be appreciated and would help with migrating the site away from the wiki.. Cheers, Scott From cell at michaelclerx.com Wed Aug 8 03:44:03 2012 From: cell at michaelclerx.com (Michael Clerx) Date: Wed, 08 Aug 2012 09:44:03 +0200 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: References: <50211CF8.9020108@michaelclerx.com> Message-ID: <502218C3.8020609@michaelclerx.com> On 08/08/2012 08:55 AM, Scott Sinclair wrote: > On 7 August 2012 15:49, Michael Clerx wrote: >> First of all, scipy.org appears to be down and has been for some time today. >> >> Yesterday, when it was still up, I registered an account and tried >> adding a link to the topical software section but got the error "too >> many links". Does anybody know how/if I can fix this? > One fix might be to kill all the dead links (there are plenty, see > http://validator.w3.org/checklink?uri=http%3A%2F%2Fscipy.org%2FTopical_Software&hide_type=all&depth=&check=Check). > > I wasted 30 minutes starting to do this a few days ago, but lost my > changes to an internal server error. I'll have another go sometime, > but not this week. > > The other (better) alternative is to split the sections into several > pages and prune dead links at the same time. > > This sort of clean-up would be appreciated and would help with > migrating the site away from the wiki.. > > Cheers, > Scott > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev I've just tried to make a start with such a split, but I think the problem isn't simply an upper bound on the number of links; I think it's to do with permissions. As it stands, I'm unable to save the page without adding any new links. Similarly, no option to create new pages is presented. kind regards, Michael From lists at hilboll.de Wed Aug 8 05:09:14 2012 From: lists at hilboll.de (Andreas Hilboll) Date: Wed, 08 Aug 2012 11:09:14 +0200 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: References: <50211CF8.9020108@michaelclerx.com> Message-ID: <50222CBA.5070202@hilboll.de> Am 08.08.2012 08:55, schrieb Scott Sinclair: > On 7 August 2012 15:49, Michael Clerx wrote: >> First of all, scipy.org appears to be down and has been for some time today. >> >> Yesterday, when it was still up, I registered an account and tried >> adding a link to the topical software section but got the error "too >> many links". Does anybody know how/if I can fix this? > > One fix might be to kill all the dead links (there are plenty, see > http://validator.w3.org/checklink?uri=http%3A%2F%2Fscipy.org%2FTopical_Software&hide_type=all&depth=&check=Check). I also get the "too many links" error. However, I doubt it's related to the page's contents, and therefore I don't think reducing the number of hyperlinks on the page will make the error go away. The stack trace my browser shows me says that the "too many links" is raised by a call to os.mkdir, so it must be a problem of the webserver's filesystem. Can the admins check how many files are in the directory /home/scipy/wiki/data/pages/? I suspect it's more than the file systems limitation (2^15 in case of ext2/3, IIRC). Maybe Moinmoin doesn't clean orphaned Backups from that directory automatically, and a cronjob could help? Cheers, A. From ognen at enthought.com Wed Aug 8 11:05:39 2012 From: ognen at enthought.com (Ognen Duzlevski) Date: Wed, 8 Aug 2012 10:05:39 -0500 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: <50222CBA.5070202@hilboll.de> References: <50211CF8.9020108@michaelclerx.com> <50222CBA.5070202@hilboll.de> Message-ID: Hello, On Wed, Aug 8, 2012 at 4:09 AM, Andreas Hilboll wrote: > I also get the "too many links" error. However, I doubt it's related to > the page's contents, and therefore I don't think reducing the number of > hyperlinks on the page will make the error go away. > > The stack trace my browser shows me says that the "too many links" is > raised by a call to os.mkdir, so it must be a problem of the webserver's > filesystem. > > Can the admins check how many files are in the directory > /home/scipy/wiki/data/pages/? I suspect it's more than the file systems > limitation (2^15 in case of ext2/3, IIRC). > > Maybe Moinmoin doesn't clean orphaned Backups from that directory > automatically, and a cronjob could help? You are right, there are a LOT of files in there, mostly spam. Here is a sampling: drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 kingfisher(2d)red(2d)airline(2d)website(2d)161(2f)MoinEditorBackup drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 kingfisher(2d)red(2d)airline(2d)website(2d)161 drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 indigo(2d)airlines(2d)office(2d)in(2d)chennai(2d)188 drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 japan(2d)airlines(2d)ticket(2d)confirmation(2d)11(2f)MoinEditorBackup drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 japan(2d)airlines(2d)ticket(2d)confirmation(2d)11 drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 indian(2d)airlines(2d)economy(2d)fares(2d)18(2f)MoinEditorBackup drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 indian(2d)airlines(2d)economy(2d)fares(2d)18 drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 97(e788b1)xxoo(2ce5b0b1e58ebbe788b1)97(2e)com(2b)www(2e)360jqsplts(2e)cn(2b)97(e5b0b1e58ebbe788b1e69c80e696b0e7bd91e59d80) drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 97(e788b1e79a84e69c80e696b0e7bd91e59d80)www(2e)360jqsplts(2e)cn(e889b2)97(e788b12c)97(e788b1e7bd91e7ab99) drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 97(e788b1e69c80e696b0e7bd91e59d80)www(2e)360jqsplts(2e)cn97(e788b1e7bd91e59d80) drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 7(e788b1e69c80e696b0e7bd91e59d802c)97(e788b1e7bd91e59d80)www(2e)360jqsplts(2e)cn97(e788b1e79a84e69c80e696b0e7bd91e59d80) drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 knocked drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 (e7be8ee5a5b3e8a3b8e4bd93)www(2e)360jqsplts(2e)cn(e5a5b3e4b88be983a8e8a3b8e4bd93e585a8e8baabe785a7e59bbe) drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 Ningbo(2b)Tourism drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 (e6bf80e68385e783ade8889e)www(2e)360jqsplts(2e)cn(e6bf80e68385e4baa4e58f8b2ce6bf80e68385e78987) drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 dgjingheng(2b)screw drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 cement(2b)mixer drwxrwx--- 2 scipy scipy 4096 Jul 15 2009 wow(2b)gold(2d2d)aggressor(2b)Ottawa drwxrwx--- 2 scipy scipy 4096 Jul 15 2009 (e89b8be9a5bce8a5bfe696bd) drwxrwx--- 3 scipy scipy 4096 Jul 15 2009 fluid(2d)restriction(2d)airlines(2d)62(2f)MoinEditorBackup I don't know much about MoinMoin - can I delete all directories with the word "Backup" ending them? Thanks, Ognen From lists at hilboll.de Wed Aug 8 11:14:16 2012 From: lists at hilboll.de (Andreas Hilboll) Date: Wed, 8 Aug 2012 17:14:16 +0200 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: References: <50211CF8.9020108@michaelclerx.com> <50222CBA.5070202@hilboll.de> Message-ID: > Hello, > > On Wed, Aug 8, 2012 at 4:09 AM, Andreas Hilboll wrote: >> I also get the "too many links" error. However, I doubt it's related to >> the page's contents, and therefore I don't think reducing the number of >> hyperlinks on the page will make the error go away. >> >> The stack trace my browser shows me says that the "too many links" is >> raised by a call to os.mkdir, so it must be a problem of the webserver's >> filesystem. >> >> Can the admins check how many files are in the directory >> /home/scipy/wiki/data/pages/? I suspect it's more than the file systems >> limitation (2^15 in case of ext2/3, IIRC). >> >> Maybe Moinmoin doesn't clean orphaned Backups from that directory >> automatically, and a cronjob could help? > > You are right, there are a LOT of files in there, mostly spam. Here is > a sampling: > > drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 > kingfisher(2d)red(2d)airline(2d)website(2d)161(2f)MoinEditorBackup > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > kingfisher(2d)red(2d)airline(2d)website(2d)161 > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > indigo(2d)airlines(2d)office(2d)in(2d)chennai(2d)188 > drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 > japan(2d)airlines(2d)ticket(2d)confirmation(2d)11(2f)MoinEditorBackup > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > japan(2d)airlines(2d)ticket(2d)confirmation(2d)11 > drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 > indian(2d)airlines(2d)economy(2d)fares(2d)18(2f)MoinEditorBackup > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > indian(2d)airlines(2d)economy(2d)fares(2d)18 > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > 97(e788b1)xxoo(2ce5b0b1e58ebbe788b1)97(2e)com(2b)www(2e)360jqsplts(2e)cn(2b)97(e5b0b1e58ebbe788b1e69c80e696b0e7bd91e59d80) > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > 97(e788b1e79a84e69c80e696b0e7bd91e59d80)www(2e)360jqsplts(2e)cn(e889b2)97(e788b12c)97(e788b1e7bd91e7ab99) > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > 97(e788b1e69c80e696b0e7bd91e59d80)www(2e)360jqsplts(2e)cn97(e788b1e7bd91e59d80) > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > 7(e788b1e69c80e696b0e7bd91e59d802c)97(e788b1e7bd91e59d80)www(2e)360jqsplts(2e)cn97(e788b1e79a84e69c80e696b0e7bd91e59d80) > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 knocked > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > (e7be8ee5a5b3e8a3b8e4bd93)www(2e)360jqsplts(2e)cn(e5a5b3e4b88be983a8e8a3b8e4bd93e585a8e8baabe785a7e59bbe) > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 Ningbo(2b)Tourism > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 > (e6bf80e68385e783ade8889e)www(2e)360jqsplts(2e)cn(e6bf80e68385e4baa4e58f8b2ce6bf80e68385e78987) > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 dgjingheng(2b)screw > drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 cement(2b)mixer > drwxrwx--- 2 scipy scipy 4096 Jul 15 2009 > wow(2b)gold(2d2d)aggressor(2b)Ottawa > drwxrwx--- 2 scipy scipy 4096 Jul 15 2009 (e89b8be9a5bce8a5bfe696bd) > drwxrwx--- 3 scipy scipy 4096 Jul 15 2009 > fluid(2d)restriction(2d)airlines(2d)62(2f)MoinEditorBackup > > I don't know much about MoinMoin - can I delete all directories with > the word "Backup" ending them? I don't really knot MoinMoin either. I would however assume that it's save to remove all files with ``MoinEditorBackup`` in their names, which are older than, asy, a day. How many would those be? If it's a significant amount, you should consider deleting those directories (maybe after adding them to a TAR backup). Cheers, A. From ognen at enthought.com Wed Aug 8 11:21:11 2012 From: ognen at enthought.com (Ognen Duzlevski) Date: Wed, 8 Aug 2012 10:21:11 -0500 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: References: <50211CF8.9020108@michaelclerx.com> <50222CBA.5070202@hilboll.de> Message-ID: On Wed, Aug 8, 2012 at 10:14 AM, Andreas Hilboll wrote: >> Hello, >> >> On Wed, Aug 8, 2012 at 4:09 AM, Andreas Hilboll wrote: >>> I also get the "too many links" error. However, I doubt it's related to >>> the page's contents, and therefore I don't think reducing the number of >>> hyperlinks on the page will make the error go away. >>> >>> The stack trace my browser shows me says that the "too many links" is >>> raised by a call to os.mkdir, so it must be a problem of the webserver's >>> filesystem. >>> >>> Can the admins check how many files are in the directory >>> /home/scipy/wiki/data/pages/? I suspect it's more than the file systems >>> limitation (2^15 in case of ext2/3, IIRC). >>> >>> Maybe Moinmoin doesn't clean orphaned Backups from that directory >>> automatically, and a cronjob could help? >> >> You are right, there are a LOT of files in there, mostly spam. Here is >> a sampling: >> >> drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 >> kingfisher(2d)red(2d)airline(2d)website(2d)161(2f)MoinEditorBackup >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> kingfisher(2d)red(2d)airline(2d)website(2d)161 >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> indigo(2d)airlines(2d)office(2d)in(2d)chennai(2d)188 >> drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 >> japan(2d)airlines(2d)ticket(2d)confirmation(2d)11(2f)MoinEditorBackup >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> japan(2d)airlines(2d)ticket(2d)confirmation(2d)11 >> drwxrwx--- 3 scipy scipy 4096 Jul 16 2009 >> indian(2d)airlines(2d)economy(2d)fares(2d)18(2f)MoinEditorBackup >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> indian(2d)airlines(2d)economy(2d)fares(2d)18 >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> 97(e788b1)xxoo(2ce5b0b1e58ebbe788b1)97(2e)com(2b)www(2e)360jqsplts(2e)cn(2b)97(e5b0b1e58ebbe788b1e69c80e696b0e7bd91e59d80) >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> 97(e788b1e79a84e69c80e696b0e7bd91e59d80)www(2e)360jqsplts(2e)cn(e889b2)97(e788b12c)97(e788b1e7bd91e7ab99) >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> 97(e788b1e69c80e696b0e7bd91e59d80)www(2e)360jqsplts(2e)cn97(e788b1e7bd91e59d80) >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> 7(e788b1e69c80e696b0e7bd91e59d802c)97(e788b1e7bd91e59d80)www(2e)360jqsplts(2e)cn97(e788b1e79a84e69c80e696b0e7bd91e59d80) >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 knocked >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> (e7be8ee5a5b3e8a3b8e4bd93)www(2e)360jqsplts(2e)cn(e5a5b3e4b88be983a8e8a3b8e4bd93e585a8e8baabe785a7e59bbe) >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 Ningbo(2b)Tourism >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 >> (e6bf80e68385e783ade8889e)www(2e)360jqsplts(2e)cn(e6bf80e68385e4baa4e58f8b2ce6bf80e68385e78987) >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 dgjingheng(2b)screw >> drwxrwx--- 2 scipy scipy 4096 Jul 16 2009 cement(2b)mixer >> drwxrwx--- 2 scipy scipy 4096 Jul 15 2009 >> wow(2b)gold(2d2d)aggressor(2b)Ottawa >> drwxrwx--- 2 scipy scipy 4096 Jul 15 2009 (e89b8be9a5bce8a5bfe696bd) >> drwxrwx--- 3 scipy scipy 4096 Jul 15 2009 >> fluid(2d)restriction(2d)airlines(2d)62(2f)MoinEditorBackup >> >> I don't know much about MoinMoin - can I delete all directories with >> the word "Backup" ending them? > > I don't really knot MoinMoin either. I would however assume that it's save > to remove all files with ``MoinEditorBackup`` in their names, which are > older than, asy, a day. How many would those be? If it's a significant > amount, you should consider deleting those directories (maybe after adding > them to a TAR backup). I am just tarring everything up now and will proceed to delete everything that is older than August. Ognen From ognen at enthought.com Wed Aug 8 11:33:29 2012 From: ognen at enthought.com (Ognen Duzlevski) Date: Wed, 8 Aug 2012 10:33:29 -0500 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: References: <50211CF8.9020108@michaelclerx.com> <50222CBA.5070202@hilboll.de> Message-ID: On Wed, Aug 8, 2012 at 10:21 AM, Ognen Duzlevski wrote: > I am just tarring everything up now and will proceed to delete > everything that is older than August. > Ognen OK - I have deleted the obvious suspects but there are many more. I will try and figure out a way to do this better. Ognen From robert.kern at gmail.com Wed Aug 8 11:43:06 2012 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 8 Aug 2012 16:43:06 +0100 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: References: <50211CF8.9020108@michaelclerx.com> <50222CBA.5070202@hilboll.de> Message-ID: On Wed, Aug 8, 2012 at 4:33 PM, Ognen Duzlevski wrote: > On Wed, Aug 8, 2012 at 10:21 AM, Ognen Duzlevski wrote: > >> I am just tarring everything up now and will proceed to delete >> everything that is older than August. >> Ognen > > OK - I have deleted the obvious suspects but there are many more. I > will try and figure out a way to do this better. Every page directory that doesn't have a file named "current" in it is considered deleted. It's likely that many of the spam pages have been deleted through the web interface, but still exist on disk. http://moinmo.in/MoinDev/Storage -- Robert Kern From ognen at enthought.com Wed Aug 8 13:36:05 2012 From: ognen at enthought.com (Ognen Duzlevski) Date: Wed, 8 Aug 2012 12:36:05 -0500 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: References: <50211CF8.9020108@michaelclerx.com> <50222CBA.5070202@hilboll.de> Message-ID: Robert, On Wed, Aug 8, 2012 at 10:43 AM, Robert Kern wrote: > Every page directory that doesn't have a file named "current" in it is > considered deleted. It's likely that many of the spam pages have been > deleted through the web interface, but still exist on disk. > > http://moinmo.in/MoinDev/Storage Thanks, that helps, somewhat. There are a bunch of spam pages that have the current file in them so I still have to figure out some way to whack what is to be whacked and keep what is to be kept without spending a week on it ;) Ognen From ognen at enthought.com Wed Aug 8 13:37:47 2012 From: ognen at enthought.com (Ognen Duzlevski) Date: Wed, 8 Aug 2012 12:37:47 -0500 Subject: [SciPy-Dev] Scipy.org is down + question about "topical software" In-Reply-To: References: <50211CF8.9020108@michaelclerx.com> <50222CBA.5070202@hilboll.de> Message-ID: On Wed, Aug 8, 2012 at 12:36 PM, Ognen Duzlevski wrote: > Thanks, that helps, somewhat. There are a bunch of spam pages that > have the current file in them so I still have to figure out some way > to whack what is to be whacked and keep what is to be kept without > spending a week on it ;) There are 22832 subdirectories in the /home/scipy/wiki/data/pages directory. Anyone has any experience fighting MoinMoin spam? :) Ognen From lists at onerussian.com Wed Aug 8 14:38:43 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Wed, 8 Aug 2012 14:38:43 -0400 Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 0.11.0 release candidate 1 In-Reply-To: References: Message-ID: <20120808183843.GE5866@onerussian.com> I thought it might be of interest for you -- I have ran nosetests scipy against current head on an s390x Debian porter box: http://www.onerussian.com/tmp/tests-scipy-v0.4.3-5984-gfd5ceda-s390x.log summary: FAILED (SKIP=31, errors=15, failures=6) Cheers, On Thu, 19 Jul 2012, Ralf Gommers wrote: > Hi, > I am pleased to announce the availability of the first release candidate > of SciPy 0.11.0. For this release many new features have been added, and > over 120 tickets and pull requests have been closed. Also noteworthy is > that the number of contributors for this release has risen to over 50. > Some of the highlights are: > ? - A new module, sparse.csgraph, has been added which provides a number > of common sparse graph algorithms. > ? - New unified interfaces to the existing optimization and root finding > functions have been added. > Sources and binaries can be found at > [1]https://sourceforge.net/projects/scipy/files/scipy/0.11.0rc1/, release > notes are copied below. > Please try this release candidate and report any problems on the scipy > mailing lists. > Cheers, > Ralf -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From cevans at evanslabs.org Wed Aug 8 14:38:04 2012 From: cevans at evanslabs.org (Constantine Evans) Date: Wed, 8 Aug 2012 11:38:04 -0700 Subject: [SciPy-Dev] Bootstrap confidence limits code Message-ID: Hello everyone, A few years ago I implemented a scikit for bootstrap confidence limits (https://github.com/cgevans/scikits-bootstrap). I didn?t think much about it after that until recently, when I realized that some people are actually using it, and that there?s apparently been some talk about implementing this functionality in either scipy.stats or statsmodels (I should thank Randal Olson for discussing this and bringing it to my attention). As such I?ve rewritten most of the code, and written up some docstrings. The current code can do confidence intervals with basic percentile interval, bias-corrected accelerated, and approximate bootstrap confidence methods, and can also provide bootstrap and jackknife indexes. Most of it is implemented from the descriptions in Efron and Tibshirani?s Introduction to the Bootstrap, but the ABC code at the moment is a port from the modified-BSD-licensed bootstrap package for R (not the boot package) as I?m not entirely confident in my understanding of the method. And so, I have a few questions for everyone: * Is there any interest in including this sort of code in either scipy.stats or statsmodels? If so, where do people think would be the better place? The code is relatively small; at the moment it is less than 200 lines, with docstrings probably making up 100 of those lines. * Also, if so, what would need to be changed, added, and improved beyond what is mentioned in the Contributing to Scipy part of the reference guide? I?m never a fan of my own code, and imagine quite a bit would need to be fixed; I know tests will need to be added too. In addition, I have a few questions about what would be better practice for the API, and I haven?t really found a guide on best practices for Scipy: * When I started writing the code, I wrote a single function ci for confidence intervals, with a method argument to choose the method. This is easy for users, especially so that they don?t have to look through documentation to realize that BCA is the most generally useful method (at least from everything I?ve read) and that there really isn?t any reason to use many of the simpler methods. However, ABC takes different paramenters, and needs a statistic function that takes weights, which makes this single-function organization trickier. At the moment, I have a separate function for ABC. Would it be better to split up all the methods to their own functions? * ABC requires a statistic function that takes weights. I?ve noticed that things like np.average takes a weights= argument. Would it be better to require input of a stat(data,weights) function, or input of a stat(data,weights=) with weights as a named argument? The latter would be nice in terms of allowing the same function to be used for all methods, but would make it impossible to use a lambda for the function. Is there some other method of doing this entirely? * Are there any missing features that anyone thinks should be added? I apologize if much of this is answered elsewhere, I just haven?t found any of it; I also apologize if this is far too long-winded and confusing! Regards, Constantine Evans From ralf.gommers at gmail.com Wed Aug 8 14:53:08 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 8 Aug 2012 20:53:08 +0200 Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 0.11.0 release candidate 1 In-Reply-To: <20120808183843.GE5866@onerussian.com> References: <20120808183843.GE5866@onerussian.com> Message-ID: On Wed, Aug 8, 2012 at 8:38 PM, Yaroslav Halchenko wrote: > I thought it might be of interest for you -- I have ran nosetests scipy > against current head on an s390x Debian porter box: > http://www.onerussian.com/tmp/tests-scipy-v0.4.3-5984-gfd5ceda-s390x.log > summary: > FAILED (SKIP=31, errors=15, failures=6) > > Thanks Yaroslav. Note that all the errors disappear if you run the tests with ">>> scipy.test('full', verbose=2)". The 6 failures are: ====================================================================== FAIL: test_basic.TestNorm.test_stable ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/linalg/tests/test_basic.py", line 585, in test_stable assert_almost_equal(norm(a) - 1e4, 0.5) File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 468, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal to 7 decimals ACTUAL: 0.0 DESIRED: 0.5 ====================================================================== FAIL: test_datatypes.test_uint64_max ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/ndimage/tests/test_datatypes.py", line 57, in test_uint64_max assert_true(x[1] > (2**63)) AssertionError: False is not true ====================================================================== FAIL: test_qhull.TestUtilities.test_degenerate_barycentric_transforms ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/pymodules/python2.7/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/spatial/tests/test_qhull.py", line 139, in test_degenerate_barycentric_transforms assert_(bad_count < 20, bad_count) File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 34, in assert_ raise AssertionError(msg) AssertionError: 20 ====================================================================== FAIL: test_qhull.TestUtilities.test_more_barycentric_transforms ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/pymodules/python2.7/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/spatial/tests/test_qhull.py", line 199, in test_more_barycentric_transforms unit_cube_tol=1.5e6*eps) File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/spatial/tests/test_qhull.py", line 124, in _check_barycentric_transforms assert_(ok.all(), "%s %s" % (err_msg, np.where(~ok))) File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 34, in assert_ raise AssertionError(msg) AssertionError: ndim=4 (array([ 8071, 10512, 10513]),) ====================================================================== FAIL: test_iv_cephes_vs_amos_mass_test (test_basic.TestBessel) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 1659, in test_iv_cephes_vs_amos_mass_test assert_(dc[k] < 1e-9, (v[k], x[k], special.iv(v[k], x[k]), special.iv(v[k], x[k]+0j))) File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 34, in assert_ raise AssertionError(msg) AssertionError: (189.2947429454936, 3.0238805556481037, 4.089165443940765e-317, 0j) ====================================================================== FAIL: test_data.test_boost(,) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/special/tests/test_data.py", line 218, in _test_factory test.check(dtype=dtype) File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/special/_testutils.py", line 224, in check assert_(False, "\n".join(msg)) File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 34, in assert_ raise AssertionError(msg) AssertionError: Max |adiff|: 5.56451e-80 Max |rdiff|: 6.01399e-12 Bad results for the following points (in output 0): -55.25 => 1.2813426521432485e-73 != 1.2813426521356121e-73 (rdiff 5.959647207094304e-12) -55.0625 => 9.867326074925447e-73 != 9.86732607487198e-73 (rdiff 5.4185128296701245e-12) -55.015625 => 4.736069454765531e-72 != 4.736069454740001e-72 (rdiff 5.390477071035947e-12) -55.001953125 => 4.001152702605484e-71 != 4.0011527025839184e-71 (rdiff 5.3899101047365405e-12) -55.0009765625 => 8.03371657917631e-71 != 8.033716579133006e-71 (rdiff 5.390260882973932e-12) -55.00006103515625 => 1.2901278999535244e-69 != 1.2901278999465708e-69 (rdiff 5.389836286790528e-12) -55.00001525878906 => 5.161460448793591e-69 != 5.161460448765773e-69 (rdiff 5.389643299825182e-12) -55.00000762939453 => 1.0323237221382923e-68 != 1.0323237221327282e-68 (rdiff 5.3898770611534905e-12) -54.99999237060547 => -1.0323869903952338e-68 != -1.0323869903896693e-68 (rdiff 5.389945636678977e-12) -54.999969482421875 => -2.5812047538146166e-69 != -2.581204753800704e-69 (rdiff 5.390048438554985e-12) -54.999755859375 => -3.229275765714629e-70 != -3.229275765697224e-70 (rdiff 5.38980884948699e-12) -54.99951171875 => -1.6162223904478387e-70 != -1.6162223904391274e-70 (rdiff 5.389899375642087e-12) -54.998046875 => -4.0644220032500644e-71 != -4.064422003228156e-71 (rdiff 5.390308306297719e-12) -54.9921875 => -1.0403990765960148e-71 != -1.040399076590406e-71 (rdiff 5.391034204122906e-12) -54.984375 => -5.369420317853762e-72 != -5.369420317824802e-72 (rdiff 5.393513012257176e-12) -54.9375 => -1.6301847489550236e-72 != -1.6301847489461702e-72 (rdiff 5.430916285207302e-12) -54.875 => -1.0680846658730133e-72 != -1.0680846658670925e-72 (rdiff 5.5434016349406124e-12) -54.875 => -1.0680846658730133e-72 != -1.0680846658670925e-72 (rdiff 5.5434016349406124e-12) -54.75 => -9.545836185682586e-73 != -9.545836185625178e-73 (rdiff 6.013992626968188e-12) -54.625 => -1.206186475654961e-72 != -1.2061864756493961e-72 (rdiff 4.6135414163673135e-12) ---------------------------------------------------------------------- Ran 6217 tests in 500.388s -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsseabold at gmail.com Wed Aug 8 14:57:20 2012 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 8 Aug 2012 14:57:20 -0400 Subject: [SciPy-Dev] Bootstrap confidence limits code In-Reply-To: References: Message-ID: On Wed, Aug 8, 2012 at 2:38 PM, Constantine Evans wrote: > Hello everyone, > > Hi, > A few years ago I implemented a scikit for bootstrap confidence limits > (https://github.com/cgevans/scikits-bootstrap). I didn?t think much > about it after that until recently, when I realized that some people > are actually using it, and that there?s apparently been some talk > about implementing this functionality in either scipy.stats or > statsmodels (I should thank Randal Olson for discussing this and > bringing it to my attention). > > As such I?ve rewritten most of the code, and written up some > docstrings. The current code can do confidence intervals with basic > percentile interval, bias-corrected accelerated, and approximate > bootstrap confidence methods, and can also provide bootstrap and > jackknife indexes. Most of it is implemented from the descriptions in > Efron and Tibshirani?s Introduction to the Bootstrap, but the ABC code > at the moment is a port from the modified-BSD-licensed bootstrap > package for R (not the boot package) as I?m not entirely confident in > my understanding of the method. > > And so, I have a few questions for everyone: > > * Is there any interest in including this sort of code in either > scipy.stats or statsmodels? If so, where do people think would be the > better place? The code is relatively small; at the moment it is less > than 200 lines, with docstrings probably making up 100 of those lines. > I think it would be great to have this in statsmodels. I filed an enhancement ticket about it this morning (also brought to my attention by Randy's blog post). https://github.com/statsmodels/statsmodels/issues/420 > * Also, if so, what would need to be changed, added, and improved > beyond what is mentioned in the Contributing to Scipy part of the > reference guide? I?m never a fan of my own code, and imagine quite a > bit would need to be fixed; I know tests will need to be added too. > > We can discuss further on the statsmodels mailing list (cc'd) unless someone feels strongly that this should go into scipy. I'm not sure about API yet so that it can be general and used across all the models in statsmodels. It's one of the reasons I've put off incorporating code like this for so long. > In addition, I have a few questions about what would be better > practice for the API, and I haven?t really found a guide on best > practices for Scipy: > > * When I started writing the code, I wrote a single function ci for > confidence intervals, with a method argument to choose the method. > This is easy for users, especially so that they don?t have to look > through documentation to realize that BCA is the most generally useful > method (at least from everything I?ve read) and that there really > isn?t any reason to use many of the simpler methods. However, ABC > takes different paramenters, and needs a statistic function that takes > weights, which makes this single-function organization trickier. At > the moment, I have a separate function for ABC. Would it be better to > split up all the methods to their own functions? > I think this might be preferable. > * ABC requires a statistic function that takes weights. I?ve noticed > that things like np.average takes a weights= argument. Would it be > better to require input of a stat(data,weights) function, or input of > a stat(data,weights=) with weights as a named argument? The latter > would be nice in terms of allowing the same function to be used for > all methods, but would make it impossible to use a lambda for the > function. Is there some other method of doing this entirely? > * Are there any missing features that anyone thinks should be added? > > I apologize if much of this is answered elsewhere, I just haven?t > found any of it; I also apologize if this is far too long-winded and > confusing! > > Regards, > Constantine Evans > _______________________________________________ > 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 Wed Aug 8 15:13:52 2012 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 8 Aug 2012 15:13:52 -0400 Subject: [SciPy-Dev] test_qz_double_sort seg fault - upgrade mingw for binaries? Message-ID: Hi, There is a failure that's holding up the release reported here. projects.scipy.org/scipy/ticket/1717 AFAIK, this test seg faults only on the official SSE2/SSE3 windows 32-bit binaries that are built using mingw 3.14 with gcc 3.4. It's only the double precision test that has a callback function that break. https://github.com/numpy/vendor The suspicion is that it's a compiler issue since the tests pass on other architectures and with msvc/mkl on windows as reported by Christoph. I didn't see anything in the LAPACK change sets to suggest it's an issue with the ATLAS/LAPACK, though I suppose this is still possible. How difficult would it be for someone to upgrade mingw/gcc and see if the seg fault goes away? I could try though I'm not set up for this and am not that familiar with cygwin/mingw. Are there any other mingw issues on windows to be aware of that prevents using a newer compiler? Any other way to resolve this? Skipper -------------- next part -------------- An HTML attachment was scrubbed... URL: From nerduno.list at gmail.com Wed Aug 8 16:32:03 2012 From: nerduno.list at gmail.com (Aaron Andalman) Date: Wed, 8 Aug 2012 13:32:03 -0700 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails In-Reply-To: References: Message-ID: Dear scipy-dev list, Scipy is failing to build on Mountain Lion, despite my using the latest fixes on github. I'm using pip install -e git+ https://github.com/scipy/scipy#egg=scipy-dev The installation crashes on the line: /usr/bin/llvm-gcc -fno-strict-aliasing -fno-common -dynamic -arch i386 -arch x86_64 -O3 -w -pipe -march=core2 -msse4 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iscipy/sparse/linalg/eigen/arpack/ARPACK/SRC -I/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include -c scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.c -o build/temp.macosx-10.5-intel-2.7/scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.o" failed with exit status 1 With the error: In file included from /System/Library/Frameworks/vecLib.framework/Headers/vecLib.h:43, from /System/Library/Frameworks/Accelerate.framework/Headers/Accelerate.h:20, from scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.c:2: /System/Library/Frameworks/vecLib.framework/Headers/vfp.h:51:23: error: immintrin.h: No such file or directory In file included from /System/Library/Frameworks/vecLib.framework/Headers/vecLib.h:43, from /System/Library/Frameworks/Accelerate.framework/Headers/Accelerate.h:20, from scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.c:2: /System/Library/Frameworks/vecLib.framework/Headers/vfp.h: In function ?vceilf?: /System/Library/Frameworks/vecLib.framework/Headers/vfp.h:53: error: incompatible types in return ... I can compile veclib_cabi.c.c, if I change the -msse4 compilation flag to -msse3 (or if I use clang, but this causes other errors). Thus my questions are: 1) how can I change the compilations flags used by python setup.py to include -msse3 instead of -msse4? 2) why is -msse4 being selected by python setup.py in the first place? 3) is this a bug with setup.py on mountain lion, or is this a problem with my installation? Below is the information requested by the scipy installation readme. python -c 'from numpy.f2py.diagnose import run; run()' ------ os.name='posix' ------ sys.platform='darwin' ------ sys.version: 2.7.2 (default, Jan 14 2012, 15:51:45) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] ------ sys.prefix: /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/.. ------ sys.path=':/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/site-packages/pip-1.1-py2.7.egg:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python27.zip:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/plat-darwin:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/plat-mac:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/plat-mac/lib-scriptpackages:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/lib-tk:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/lib-old:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/lib-dynload:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/site-packages:/Users/andalman/.local/lib/python2.7/site-packages:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info' ------ Found new numpy version '1.6.2' in /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.pyc Found f2py2e version '2' in /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/f2py2e.pyc Found numpy.distutils version '0.4.0' in '/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/distutils/__init__.pyc' ------ Importing numpy.distutils.fcompiler ... ok ------ Checking availability of supported Fortran compilers: Gnu95FCompiler instance properties: archiver = ['/usr/local/bin/gfortran', '-cr'] compile_switch = '-c' compiler_f77 = ['/usr/local/bin/gfortran', '-Wall', '-ffixed-form', '- fno-second-underscore', '-arch', 'i686', '-arch', 'x86_64', '-fPIC', '-O3', '-funroll-loops'] compiler_f90 = ['/usr/local/bin/gfortran', '-Wall', '-fno-second- underscore', '-arch', 'i686', '-arch', 'x86_64', '-fPIC', '-O3', '-funroll-loops'] compiler_fix = ['/usr/local/bin/gfortran', '-Wall', '-ffixed-form', '- fno-second-underscore', '-Wall', '-fno-second-underscore', '-arch', 'i686', '-arch', 'x86_64', '-fPIC', '-O3', '- funroll-loops'] libraries = ['gfortran'] library_dirs = [] linker_exe = ['/usr/local/bin/gfortran', '-Wall', '-Wall'] linker_so = ['/usr/local/bin/gfortran', '-Wall', '-arch', 'i686', '- arch', 'x86_64', '-Wall', '-undefined', 'dynamic_lookup', '-bundle'] object_switch = '-o ' ranlib = ['/usr/local/bin/gfortran'] version = LooseVersion ('4.2.1') version_cmd = ['/usr/local/bin/gfortran', '--version'] Fortran compilers found: --fcompiler=gnu95 GNU Fortran 95 compiler (4.2.1) Compilers available for this platform, but not found: --fcompiler=absoft Absoft Corp Fortran Compiler --fcompiler=g95 G95 Fortran Compiler --fcompiler=gnu GNU Fortran 77 compiler --fcompiler=ibm IBM XL Fortran Compiler --fcompiler=intel Intel Fortran Compiler for 32-bit apps --fcompiler=nag NAGWare Fortran 95 Compiler --fcompiler=pg Portland Group Fortran Compiler Compilers not available on this platform: --fcompiler=compaq Compaq Fortran Compiler --fcompiler=hpux HP Fortran 90 Compiler --fcompiler=intele Intel Fortran Compiler for Itanium apps --fcompiler=intelem Intel Fortran Compiler for 64-bit apps --fcompiler=intelev Intel Visual Fortran Compiler for Itanium apps --fcompiler=intelv Intel Visual Fortran Compiler for 32-bit apps --fcompiler=intelvem Intel Visual Fortran Compiler for 64-bit apps --fcompiler=lahey Lahey/Fujitsu Fortran 95 Compiler --fcompiler=mips MIPSpro Fortran Compiler --fcompiler=none Fake Fortran compiler --fcompiler=pathf95 PathScale Fortran Compiler --fcompiler=sun Sun or Forte Fortran 95 Compiler --fcompiler=vast Pacific-Sierra Research Fortran 90 Compiler For compiler details, run 'config_fc --verbose' setup command. ------ Importing numpy.distutils.cpuinfo ... ok ------ CPU information: CPUInfoBase__get_nbits getNCPUs is_64bit is_i386 ------ (main_projects)Aaron-Andalmans-MacBook-Pro:scipy andalman$ #################################### ython /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py lapack_info: libraries lapack not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries lapack not found in /usr/local/lib FOUND: libraries = ['lapack'] library_dirs = ['/usr/lib'] language = f77 lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-msse3'] wx_info: Could not locate executable wx-config File not found: None. Cannot determine wx info. NOT AVAILABLE lapack_atlas_info: libraries lapack_atlas,f77blas,cblas,atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries lapack_atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries lapack_atlas,f77blas,cblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries lapack_atlas,f77blas,cblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib __main__.lapack_atlas_info NOT AVAILABLE umfpack_info: libraries umfpack not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib amd_info: libraries amd not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib FOUND: libraries = ['amd'] library_dirs = ['/usr/local/lib'] swig_opts = ['-I/usr/local/include'] define_macros = [('SCIPY_AMD_H', None)] include_dirs = ['/usr/local/include'] FOUND: libraries = ['umfpack', 'amd'] library_dirs = ['/usr/local/lib'] swig_opts = ['-I/usr/local/include', '-I/usr/local/include'] define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)] include_dirs = ['/usr/local/include'] _pkg_config_info: Found executable /usr/local/bin/pkg-config NOT AVAILABLE lapack_atlas_threads_info: Setting PTATLAS=ATLAS libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries lapack_atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib __main__.lapack_atlas_threads_info NOT AVAILABLE x11_info: /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: UserWarning: Specified path /usr/X11R6/lib64 is invalid. warnings.warn('Specified path %s is invalid.' % d) /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: UserWarning: Specified path /usr/X11/lib64 is invalid. warnings.warn('Specified path %s is invalid.' % d) /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: UserWarning: Specified path /usr/lib64 is invalid. warnings.warn('Specified path %s is invalid.' % d) FOUND: libraries = ['X11'] library_dirs = ['/usr/X11R6/lib'] include_dirs = ['/usr/X11R6/include'] blas_info: libraries blas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries blas not found in /usr/local/lib FOUND: libraries = ['blas'] library_dirs = ['/usr/lib'] language = f77 fftw_info: libraries fftw3 not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries fftw3 not found in /usr/local/lib libraries fftw3 not found in /usr/lib fftw3 not found libraries rfftw,fftw not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries rfftw,fftw not found in /usr/local/lib libraries rfftw,fftw not found in /usr/lib fftw2 not found NOT AVAILABLE atlas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries lapack_atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib __main__.atlas_threads_info NOT AVAILABLE f2py_info: FOUND: sources = ['/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/src/fortranobject.c'] include_dirs = ['/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/src'] gdk_pixbuf_xlib_2_info: NOT AVAILABLE dfftw_threads_info: libraries drfftw_threads,dfftw_threads not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries drfftw_threads,dfftw_threads not found in /usr/local/lib libraries drfftw_threads,dfftw_threads not found in /usr/lib dfftw threads not found NOT AVAILABLE atlas_blas_info: libraries f77blas,cblas,atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries f77blas,cblas,atlas not found in /usr/local/lib libraries f77blas,cblas,atlas not found in /usr/lib NOT AVAILABLE fftw3_info: libraries fftw3 not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries fftw3 not found in /usr/local/lib libraries fftw3 not found in /usr/lib fftw3 not found NOT AVAILABLE blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers'] sfftw_info: libraries srfftw,sfftw not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries srfftw,sfftw not found in /usr/local/lib libraries srfftw,sfftw not found in /usr/lib sfftw not found NOT AVAILABLE xft_info: NOT AVAILABLE fft_opt_info: fftw2_info: libraries rfftw,fftw not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries rfftw,fftw not found in /usr/local/lib libraries rfftw,fftw not found in /usr/lib fftw2 not found NOT AVAILABLE dfftw_info: libraries drfftw,dfftw not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries drfftw,dfftw not found in /usr/local/lib libraries drfftw,dfftw not found in /usr/lib dfftw not found NOT AVAILABLE djbfft_info: NOT AVAILABLE NOT AVAILABLE gdk_x11_2_info: NOT AVAILABLE agg2_info: NOT AVAILABLE numarray_info: NOT AVAILABLE blas_src_info: NOT AVAILABLE fftw_threads_info: libraries rfftw_threads,fftw_threads not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries rfftw_threads,fftw_threads not found in /usr/local/lib libraries rfftw_threads,fftw_threads not found in /usr/lib fftw threads not found NOT AVAILABLE _numpy_info: NOT AVAILABLE gdk_info: NOT AVAILABLE gtkp_x11_2_info: NOT AVAILABLE sfftw_threads_info: libraries srfftw_threads,sfftw_threads not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries srfftw_threads,sfftw_threads not found in /usr/local/lib libraries srfftw_threads,sfftw_threads not found in /usr/lib sfftw threads not found NOT AVAILABLE boost_python_info: NOT AVAILABLE freetype2_info: NOT AVAILABLE gdk_2_info: NOT AVAILABLE lapack_src_info: NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib NOT AVAILABLE gtkp_2_info: NOT AVAILABLE gdk_pixbuf_2_info: NOT AVAILABLE blas_mkl_info: libraries mkl,vml,guide not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE atlas_info: libraries f77blas,cblas,atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries lapack_atlas not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries f77blas,cblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries f77blas,cblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib __main__.atlas_info NOT AVAILABLE Numeric_info: NOT AVAILABLE numerix_info: numpy_info: /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: UserWarning: Specified path /usr/local/include/python2.7 is invalid. warnings.warn('Specified path %s is invalid.' % d) /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: UserWarning: Specified path is invalid. warnings.warn('Specified path %s is invalid.' % d) FOUND: define_macros = [('NUMPY_VERSION', '"\\"1.6.2\\""'), ('NUMPY', None)] include_dirs = ['/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include'] FOUND: define_macros = [('NUMPY_VERSION', '"\\"1.6.2\\""'), ('NUMPY', None)] include_dirs = ['/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include'] lapack_mkl_info: mkl_info: libraries mkl,vml,guide not found in /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE NOT AVAILABLE -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Aug 8 17:28:22 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 8 Aug 2012 23:28:22 +0200 Subject: [SciPy-Dev] test_qz_double_sort seg fault - upgrade mingw for binaries? In-Reply-To: References: Message-ID: On Wed, Aug 8, 2012 at 9:13 PM, Skipper Seabold wrote: > Hi, > > There is a failure that's holding up the release reported here. > > projects.scipy.org/scipy/ticket/1717 > > AFAIK, this test seg faults only on the official SSE2/SSE3 windows 32-bit > binaries that are built using mingw 3.14 with gcc 3.4. It's only the double > precision test that has a callback function that break. > > https://github.com/numpy/vendor > > The suspicion is that it's a compiler issue since the tests pass on other > architectures and with msvc/mkl on windows as reported by Christoph. I > didn't see anything in the LAPACK change sets to suggest it's an issue with > the ATLAS/LAPACK, though I suppose this is still possible. > > How difficult would it be for someone to upgrade mingw/gcc and see if the > seg fault goes away? I could try though I'm not set up for this and am not > that familiar with cygwin/mingw. > > Are there any other mingw issues on windows to be aware of that prevents > using a newer compiler? > We can't use gcc 4.x for binaries we want to distribute, see http://thread.gmane.org/gmane.comp.python.numeric.general/46536/focus=47813 > > Any other way to resolve this? > Disabling either the test or the sort keyword of qz() until it's resolved is one possibility. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsseabold at gmail.com Wed Aug 8 18:06:09 2012 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 8 Aug 2012 18:06:09 -0400 Subject: [SciPy-Dev] test_qz_double_sort seg fault - upgrade mingw for binaries? In-Reply-To: References: Message-ID: On Wed, Aug 8, 2012 at 3:13 PM, Skipper Seabold wrote: > Hi, > > There is a failure that's holding up the release reported here. > > projects.scipy.org/scipy/ticket/1717 > > AFAIK, this test seg faults only on the official SSE2/SSE3 windows 32-bit > binaries that are built using mingw 3.14 with gcc 3.4. It's only the double > precision test that has a callback function that break. > This is also python version dependent and only fails on Python <= 2.6 as well. > > https://github.com/numpy/vendor > > The suspicion is that it's a compiler issue since the tests pass on other > architectures and with msvc/mkl on windows as reported by Christoph. I > didn't see anything in the LAPACK change sets to suggest it's an issue with > the ATLAS/LAPACK, though I suppose this is still possible. > > How difficult would it be for someone to upgrade mingw/gcc and see if the > seg fault goes away? I could try though I'm not set up for this and am not > that familiar with cygwin/mingw. > > Are there any other mingw issues on windows to be aware of that prevents > using a newer compiler? > > Any other way to resolve this? > > Skipper > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Aug 9 03:08:14 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 9 Aug 2012 09:08:14 +0200 Subject: [SciPy-Dev] test_qz_double_sort seg fault - upgrade mingw for binaries? In-Reply-To: References: Message-ID: On Thu, Aug 9, 2012 at 12:06 AM, Skipper Seabold wrote: > On Wed, Aug 8, 2012 at 3:13 PM, Skipper Seabold wrote: > >> Hi, >> >> There is a failure that's holding up the release reported here. >> >> projects.scipy.org/scipy/ticket/1717 >> >> AFAIK, this test seg faults only on the official SSE2/SSE3 windows 32-bit >> binaries that are built using mingw 3.14 with gcc 3.4. It's only the double >> precision test that has a callback function that break. >> > > This is also python version dependent and only fails on Python <= 2.6 as > well. > It fails on 3.2 as well, (reported by several people). Ralf > >> >> https://github.com/numpy/vendor >> >> The suspicion is that it's a compiler issue since the tests pass on other >> architectures and with msvc/mkl on windows as reported by Christoph. I >> didn't see anything in the LAPACK change sets to suggest it's an issue with >> the ATLAS/LAPACK, though I suppose this is still possible. >> >> How difficult would it be for someone to upgrade mingw/gcc and see if the >> seg fault goes away? I could try though I'm not set up for this and am not >> that familiar with cygwin/mingw. >> >> Are there any other mingw issues on windows to be aware of that prevents >> using a newer compiler? >> >> Any other way to resolve this? >> >> 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 ralf.gommers at gmail.com Thu Aug 9 03:28:47 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 9 Aug 2012 09:28:47 +0200 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails In-Reply-To: References: Message-ID: On Wed, Aug 8, 2012 at 10:32 PM, Aaron Andalman wrote: > Dear scipy-dev list, > > Scipy is failing to build on Mountain Lion, despite my using the latest > fixes on github. I'm using pip install -e git+ > https://github.com/scipy/scipy#egg=scipy-dev > > The installation crashes on the line: > > /usr/bin/llvm-gcc -fno-strict-aliasing -fno-common -dynamic -arch i386 > -arch x86_64 -O3 -w -pipe -march=core2 -msse4 -DNDEBUG -g -fwrapv -O3 -Wall > -Wstrict-prototypes -Iscipy/sparse/linalg/eigen/arpack/ARPACK/SRC > -I/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include > -c scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.c -o > build/temp.macosx-10.5-intel-2.7/scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.o" > failed with exit status 1 > > > With the error: > > In file included from > /System/Library/Frameworks/vecLib.framework/Headers/vecLib.h:43, > from > /System/Library/Frameworks/Accelerate.framework/Headers/Accelerate.h:20, > from > scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.c:2: > /System/Library/Frameworks/vecLib.framework/Headers/vfp.h:51:23: error: > immintrin.h: No such file or directory > In file included from > /System/Library/Frameworks/vecLib.framework/Headers/vecLib.h:43, > from > /System/Library/Frameworks/Accelerate.framework/Headers/Accelerate.h:20, > from > scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.c:2: > /System/Library/Frameworks/vecLib.framework/Headers/vfp.h: In function > ?vceilf?: > /System/Library/Frameworks/vecLib.framework/Headers/vfp.h:53: error: > incompatible types in return > ... > > I can compile veclib_cabi.c.c, if I change the -msse4 compilation flag to > -msse3 (or if I use clang, but this causes other errors). > > Thus my questions are: > > 1) how can I change the compilations flags used by python setup.py to > include -msse3 instead of -msse4? > 2) why is -msse4 being selected by python setup.py in the first place? > 3) is this a bug with setup.py on mountain lion, or is this a problem with > my installation? > The -msse4 flag must have come from Python. Numpy.distutils should have added -msse3 (-msse4 isn't present anywhere). Relevant code from numpy/distutils/system_info.py: if sys.platform == 'darwin' and not os.environ.get('ATLAS', None): args = [] link_args = [] if get_platform()[-4:] == 'i386' or 'intel' in get_platform() or \ 'i386' in platform.platform(): intel = 1 else: intel = 0 if os.path.exists('/System/Library/Frameworks' '/Accelerate.framework/'): if intel: args.extend(['-msse3']) else: args.extend(['-faltivec']) Since you're using Homebrew, Python is likely also the Homebrew installed one? Ralf > Below is the information requested by the scipy installation readme. > > python -c 'from numpy.f2py.diagnose import run; run()' > ------ > os.name='posix' > ------ > sys.platform='darwin' > ------ > sys.version: > 2.7.2 (default, Jan 14 2012, 15:51:45) > [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] > ------ > sys.prefix: > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/.. > ------ > > sys.path=':/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/site-packages/pip-1.1-py2.7.egg:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python27.zip:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/plat-darwin:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/plat-mac:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/plat-mac/lib-scriptpackages:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/lib-tk:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/lib-old:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/lib-dynload:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages:/Users/andalman/Documents/Code/_virtualenvs/main_projects/lib/python2.7/site-packages:/Users/andalman/.local/lib/python2.7/site-packages:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages:/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info' > ------ > Found new numpy version '1.6.2' in > /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.pyc > Found f2py2e version '2' in > /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/f2py2e.pyc > Found numpy.distutils version '0.4.0' in > '/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/distutils/__init__.pyc' > ------ > Importing numpy.distutils.fcompiler ... ok > ------ > Checking availability of supported Fortran compilers: > Gnu95FCompiler instance properties: > archiver = ['/usr/local/bin/gfortran', '-cr'] > compile_switch = '-c' > compiler_f77 = ['/usr/local/bin/gfortran', '-Wall', '-ffixed-form', '- > fno-second-underscore', '-arch', 'i686', '-arch', > 'x86_64', '-fPIC', '-O3', '-funroll-loops'] > compiler_f90 = ['/usr/local/bin/gfortran', '-Wall', '-fno-second- > underscore', '-arch', 'i686', '-arch', 'x86_64', > '-fPIC', > '-O3', '-funroll-loops'] > compiler_fix = ['/usr/local/bin/gfortran', '-Wall', '-ffixed-form', '- > fno-second-underscore', '-Wall', > '-fno-second-underscore', > '-arch', 'i686', '-arch', 'x86_64', '-fPIC', '-O3', '- > funroll-loops'] > libraries = ['gfortran'] > library_dirs = [] > linker_exe = ['/usr/local/bin/gfortran', '-Wall', '-Wall'] > linker_so = ['/usr/local/bin/gfortran', '-Wall', '-arch', 'i686', > '- > arch', 'x86_64', '-Wall', '-undefined', > 'dynamic_lookup', > '-bundle'] > object_switch = '-o ' > ranlib = ['/usr/local/bin/gfortran'] > version = LooseVersion ('4.2.1') > version_cmd = ['/usr/local/bin/gfortran', '--version'] > Fortran compilers found: > --fcompiler=gnu95 GNU Fortran 95 compiler (4.2.1) > Compilers available for this platform, but not found: > --fcompiler=absoft Absoft Corp Fortran Compiler > --fcompiler=g95 G95 Fortran Compiler > --fcompiler=gnu GNU Fortran 77 compiler > --fcompiler=ibm IBM XL Fortran Compiler > --fcompiler=intel Intel Fortran Compiler for 32-bit apps > --fcompiler=nag NAGWare Fortran 95 Compiler > --fcompiler=pg Portland Group Fortran Compiler > Compilers not available on this platform: > --fcompiler=compaq Compaq Fortran Compiler > --fcompiler=hpux HP Fortran 90 Compiler > --fcompiler=intele Intel Fortran Compiler for Itanium apps > --fcompiler=intelem Intel Fortran Compiler for 64-bit apps > --fcompiler=intelev Intel Visual Fortran Compiler for Itanium apps > --fcompiler=intelv Intel Visual Fortran Compiler for 32-bit apps > --fcompiler=intelvem Intel Visual Fortran Compiler for 64-bit apps > --fcompiler=lahey Lahey/Fujitsu Fortran 95 Compiler > --fcompiler=mips MIPSpro Fortran Compiler > --fcompiler=none Fake Fortran compiler > --fcompiler=pathf95 PathScale Fortran Compiler > --fcompiler=sun Sun or Forte Fortran 95 Compiler > --fcompiler=vast Pacific-Sierra Research Fortran 90 Compiler > For compiler details, run 'config_fc --verbose' setup command. > ------ > Importing numpy.distutils.cpuinfo ... ok > ------ > CPU information: CPUInfoBase__get_nbits getNCPUs is_64bit is_i386 ------ > (main_projects)Aaron-Andalmans-MacBook-Pro:scipy andalman$ > > #################################### > > ython > /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py > lapack_info: > libraries lapack not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries lapack not found in /usr/local/lib > FOUND: > libraries = ['lapack'] > library_dirs = ['/usr/lib'] > language = f77 > > lapack_opt_info: > FOUND: > extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] > define_macros = [('NO_ATLAS_INFO', 3)] > extra_compile_args = ['-msse3'] > > wx_info: > Could not locate executable wx-config > File not found: None. Cannot determine wx info. > NOT AVAILABLE > > lapack_atlas_info: > libraries lapack_atlas,f77blas,cblas,atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries lapack_atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries lapack_atlas,f77blas,cblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries lapack_atlas,f77blas,cblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > __main__.lapack_atlas_info > NOT AVAILABLE > > umfpack_info: > libraries umfpack not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > amd_info: > libraries amd not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > FOUND: > libraries = ['amd'] > library_dirs = ['/usr/local/lib'] > swig_opts = ['-I/usr/local/include'] > define_macros = [('SCIPY_AMD_H', None)] > include_dirs = ['/usr/local/include'] > > FOUND: > libraries = ['umfpack', 'amd'] > library_dirs = ['/usr/local/lib'] > swig_opts = ['-I/usr/local/include', '-I/usr/local/include'] > define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)] > include_dirs = ['/usr/local/include'] > > _pkg_config_info: > Found executable /usr/local/bin/pkg-config > NOT AVAILABLE > > lapack_atlas_threads_info: > Setting PTATLAS=ATLAS > libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries lapack_atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in > /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries lapack_atlas,ptf77blas,ptcblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > __main__.lapack_atlas_threads_info > NOT AVAILABLE > > x11_info: > /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: > UserWarning: Specified path /usr/X11R6/lib64 is invalid. > warnings.warn('Specified path %s is invalid.' % d) > /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: > UserWarning: Specified path /usr/X11/lib64 is invalid. > warnings.warn('Specified path %s is invalid.' % d) > /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: > UserWarning: Specified path /usr/lib64 is invalid. > warnings.warn('Specified path %s is invalid.' % d) > FOUND: > libraries = ['X11'] > library_dirs = ['/usr/X11R6/lib'] > include_dirs = ['/usr/X11R6/include'] > > blas_info: > libraries blas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries blas not found in /usr/local/lib > FOUND: > libraries = ['blas'] > library_dirs = ['/usr/lib'] > language = f77 > > fftw_info: > libraries fftw3 not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries fftw3 not found in /usr/local/lib > libraries fftw3 not found in /usr/lib > fftw3 not found > libraries rfftw,fftw not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries rfftw,fftw not found in /usr/local/lib > libraries rfftw,fftw not found in /usr/lib > fftw2 not found > NOT AVAILABLE > > atlas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries lapack_atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > __main__.atlas_threads_info > NOT AVAILABLE > > f2py_info: > FOUND: > sources = > ['/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/src/fortranobject.c'] > include_dirs = > ['/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/src'] > > gdk_pixbuf_xlib_2_info: > NOT AVAILABLE > > dfftw_threads_info: > libraries drfftw_threads,dfftw_threads not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries drfftw_threads,dfftw_threads not found in /usr/local/lib > libraries drfftw_threads,dfftw_threads not found in /usr/lib > dfftw threads not found > NOT AVAILABLE > > atlas_blas_info: > libraries f77blas,cblas,atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries f77blas,cblas,atlas not found in /usr/local/lib > libraries f77blas,cblas,atlas not found in /usr/lib > NOT AVAILABLE > > fftw3_info: > libraries fftw3 not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries fftw3 not found in /usr/local/lib > libraries fftw3 not found in /usr/lib > fftw3 not found > NOT AVAILABLE > > blas_opt_info: > FOUND: > extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] > define_macros = [('NO_ATLAS_INFO', 3)] > extra_compile_args = ['-msse3', > '-I/System/Library/Frameworks/vecLib.framework/Headers'] > > sfftw_info: > libraries srfftw,sfftw not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries srfftw,sfftw not found in /usr/local/lib > libraries srfftw,sfftw not found in /usr/lib > sfftw not found > NOT AVAILABLE > > xft_info: > NOT AVAILABLE > > fft_opt_info: > fftw2_info: > libraries rfftw,fftw not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries rfftw,fftw not found in /usr/local/lib > libraries rfftw,fftw not found in /usr/lib > fftw2 not found > NOT AVAILABLE > > dfftw_info: > libraries drfftw,dfftw not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries drfftw,dfftw not found in /usr/local/lib > libraries drfftw,dfftw not found in /usr/lib > dfftw not found > NOT AVAILABLE > > djbfft_info: > NOT AVAILABLE > > NOT AVAILABLE > > gdk_x11_2_info: > NOT AVAILABLE > > agg2_info: > NOT AVAILABLE > > numarray_info: > NOT AVAILABLE > > blas_src_info: > NOT AVAILABLE > > fftw_threads_info: > libraries rfftw_threads,fftw_threads not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries rfftw_threads,fftw_threads not found in /usr/local/lib > libraries rfftw_threads,fftw_threads not found in /usr/lib > fftw threads not found > NOT AVAILABLE > > _numpy_info: > NOT AVAILABLE > > gdk_info: > NOT AVAILABLE > > gtkp_x11_2_info: > NOT AVAILABLE > > sfftw_threads_info: > libraries srfftw_threads,sfftw_threads not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries srfftw_threads,sfftw_threads not found in /usr/local/lib > libraries srfftw_threads,sfftw_threads not found in /usr/lib > sfftw threads not found > NOT AVAILABLE > > boost_python_info: > NOT AVAILABLE > > freetype2_info: > NOT AVAILABLE > > gdk_2_info: > NOT AVAILABLE > > lapack_src_info: > NOT AVAILABLE > > atlas_blas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/lib > NOT AVAILABLE > > gtkp_2_info: > NOT AVAILABLE > > gdk_pixbuf_2_info: > NOT AVAILABLE > > blas_mkl_info: > libraries mkl,vml,guide not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries mkl,vml,guide not found in /usr/local/lib > libraries mkl,vml,guide not found in /usr/lib > NOT AVAILABLE > > atlas_info: > libraries f77blas,cblas,atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries lapack_atlas not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries f77blas,cblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries f77blas,cblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > __main__.atlas_info > NOT AVAILABLE > > Numeric_info: > NOT AVAILABLE > > numerix_info: > numpy_info: > /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: > UserWarning: Specified path /usr/local/include/python2.7 is invalid. > warnings.warn('Specified path %s is invalid.' % d) > /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages//numpy/distutils/system_info.py:538: > UserWarning: Specified path is invalid. > warnings.warn('Specified path %s is invalid.' % d) > FOUND: > define_macros = [('NUMPY_VERSION', '"\\"1.6.2\\""'), ('NUMPY', None)] > include_dirs = > ['/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include'] > > FOUND: > define_macros = [('NUMPY_VERSION', '"\\"1.6.2\\""'), ('NUMPY', None)] > include_dirs = > ['/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include'] > > lapack_mkl_info: > mkl_info: > libraries mkl,vml,guide not found in > /Users/andalman/Documents/Code/_virtualenvs/main_projects/bin/../lib > libraries mkl,vml,guide not found in /usr/local/lib > libraries mkl,vml,guide not found in /usr/lib > NOT AVAILABLE > > NOT AVAILABLE > > > > > > _______________________________________________ > 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 brianhone at gmail.com Thu Aug 9 11:08:01 2012 From: brianhone at gmail.com (Brian Hone) Date: Thu, 09 Aug 2012 11:08:01 -0400 Subject: [SciPy-Dev] Suggested Change to io.wavfile Message-ID: <5023D251.9090205@gmail.com> Hi folks, I'm running into a wavfile read error which appears to be caused by slight problems in wavfile meta-data. (Specifically, the meta-data mis-reports the number of frames). Unfortunately, 2/3 of the wav files I've randomly sampled have this problem, and most audio packages just deal with it. I notice from a search that a lot of people have this problem with io.wavfile.read: /usr/lib/python2.7/site-packages/scipy/io/wavfile.pyc in read(file) 125 else: 126 fmt = ' 127 size = struct.unpack(fmt, data)[0] 128 fid.seek(size, 1) 129 fid.close() Here's a fix - just calculate the actual file length and use the minimum or the file length and the meta-data reported length. 113,121c113 < < ## Calculate the actual file length in case meta-data is incorrect < current_pos = fid.tell() < fid.seek(0,2) < actual_file_length = fid.tell() < fid.seek( current_pos ) < total_length = min( fsize, actual_file_length ) < < while (fid.tell() < total_length): --- > while (fid.tell() < fsize): From pmhobson at gmail.com Thu Aug 9 15:32:28 2012 From: pmhobson at gmail.com (Paul Hobson) Date: Thu, 9 Aug 2012 12:32:28 -0700 Subject: [SciPy-Dev] Bootstrap confidence limits code In-Reply-To: References: Message-ID: Replying to Skipper's message to get the Statsmodels folks... > On Wed, Aug 8, 2012 at 2:38 PM, Constantine Evans > wrote: >> >> Hello everyone, On Wed, Aug 8, 2012 at 11:57 AM, Skipper Seabold wrote: > Hi, > >> >> A few years ago I implemented a scikit for bootstrap confidence limits >> (https://github.com/cgevans/scikits-bootstrap). I didn?t think much >> about it after that until recently, when I realized that some people >> are actually using it, and that there?s apparently been some talk >> about implementing this functionality in either scipy.stats or >> statsmodels (I should thank Randal Olson for discussing this and >> bringing it to my attention). >> >> As such I?ve rewritten most of the code, and written up some >> docstrings. The current code can do confidence intervals with basic >> percentile interval, bias-corrected accelerated, and approximate >> bootstrap confidence methods, and can also provide bootstrap and >> jackknife indexes. Most of it is implemented from the descriptions in >> Efron and Tibshirani?s Introduction to the Bootstrap, but the ABC code >> at the moment is a port from the modified-BSD-licensed bootstrap >> package for R (not the boot package) as I?m not entirely confident in >> my understanding of the method. I can't comment on the ABC method, but your BCA method appears to be consistent with my own implementation. >> And so, I have a few questions for everyone: >> >> * Is there any interest in including this sort of code in either >> scipy.stats or statsmodels? If so, where do people think would be the >> better place? The code is relatively small; at the moment it is less >> than 200 lines, with docstrings probably making up 100 of those lines. > > > I think it would be great to have this in statsmodels. I filed an > enhancement ticket about it this morning (also brought to my attention by > Randy's blog post). > > https://github.com/statsmodels/statsmodels/issues/420 > As a user, I would also love to see this in statsmodels >> >> * Also, if so, what would need to be changed, added, and improved >> beyond what is mentioned in the Contributing to Scipy part of the >> reference guide? I?m never a fan of my own code, and imagine quite a >> bit would need to be fixed; I know tests will need to be added too. I can only speak to the BCA method, but I propose the following when you compute the acceleration: https://gist.github.com/3307341 Everyone's data is different and probably 99.99% of the time, SCD won't turn out to be 0 and raise a ZeroDivision error, but it happened to me and that's how I fixed it. Just a thought. Cheers, -paul From ralf.gommers at gmail.com Thu Aug 9 17:54:58 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 9 Aug 2012 23:54:58 +0200 Subject: [SciPy-Dev] test_qz_double_sort seg fault - upgrade mingw for binaries? In-Reply-To: References: Message-ID: On Wed, Aug 8, 2012 at 11:28 PM, Ralf Gommers wrote: > > > On Wed, Aug 8, 2012 at 9:13 PM, Skipper Seabold wrote: > >> Hi, >> >> There is a failure that's holding up the release reported here. >> >> projects.scipy.org/scipy/ticket/1717 >> >> AFAIK, this test seg faults only on the official SSE2/SSE3 windows 32-bit >> binaries that are built using mingw 3.14 with gcc 3.4. It's only the double >> precision test that has a callback function that break. >> >> https://github.com/numpy/vendor >> >> The suspicion is that it's a compiler issue since the tests pass on other >> architectures and with msvc/mkl on windows as reported by Christoph. I >> didn't see anything in the LAPACK change sets to suggest it's an issue with >> the ATLAS/LAPACK, though I suppose this is still possible. >> >> How difficult would it be for someone to upgrade mingw/gcc and see if the >> seg fault goes away? I could try though I'm not set up for this and am not >> that familiar with cygwin/mingw. >> >> Are there any other mingw issues on windows to be aware of that prevents >> using a newer compiler? >> > > We can't use gcc 4.x for binaries we want to distribute, see > http://thread.gmane.org/gmane.comp.python.numeric.general/46536/focus=47813 > > >> >> Any other way to resolve this? >> > > Disabling either the test or the sort keyword of qz() until it's resolved > is one possibility. > Skipper has updated the test so it doesn't crash: https://github.com/scipy/scipy/pull/285. There may still be a problem for some combinations of inputs and sort functions, but I think this shouldn't hold up the 0.11.0 release any longer. So unless someone has a better idea or a fix, I intend to merge that PR and prepare 0.11.0 RC2 in the next few days. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From nerduno.list at gmail.com Thu Aug 9 22:08:28 2012 From: nerduno.list at gmail.com (Aaron Andalman) Date: Thu, 9 Aug 2012 19:08:28 -0700 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) Message-ID: Ralf, Thanks for the information. You were correct; the -msse4 flag does appear to be coming from the brew installation of python. Grep reveals the flag in a Makefile, and editing the makefile altered the results of scipy python setup.py configure. Thus scipy now compiles! Thank you. However, I'm hoping to understand how and why scipy gets the -msse4 flag from the Makefile? Should this be modified? Or should the brew python formula be modified somehow? Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Aug 10 02:56:29 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 10 Aug 2012 08:56:29 +0200 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: References: Message-ID: On Fri, Aug 10, 2012 at 4:08 AM, Aaron Andalman wrote: > Ralf, > > Thanks for the information. You were correct; the -msse4 flag does appear > to be coming from the brew installation of python. Grep reveals the flag > in a Makefile, and editing the makefile altered the results of scipy python > setup.py configure. Thus scipy now compiles! Thank you. > > However, I'm hoping to understand how and why scipy gets the -msse4 flag > from the Makefile? Should this be modified? Or should the brew python > formula be modified somehow? > The flags with which Python itself is compiled are passed from Python distutils to numpy.distutils. In principle that's what we want. Only scipy doesn't compile with it; numpy does apparently. So we could try to filter out that flag in numpy.distutils, but the easier solution is to remove it from the homebrew Makefile. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Aug 10 07:53:03 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 10 Aug 2012 13:53:03 +0200 Subject: [SciPy-Dev] ANN: SciPy 0.11.0 release candidate 1 In-Reply-To: References: <3fb4522421d3b87335b5d040a0e6cd4b.squirrel@srv2.s4y.tournesol-consulting.eu> <5009ACC3.5090701@iki.fi> <477862d6d96a2d4b41ad524711d02fe9.squirrel@srv2.s4y.tournesol-consulting.eu> Message-ID: On Tue, Jul 24, 2012 at 6:07 PM, R?diger Kessel wrote: > R?diger Kessel gmail.com> writes: > > PS: With test_stable() one can tell implementations apart. If snrm2() is > implemented completely in single precision then the result of norm(a) will > be > 10000.0. If internally a double precision implementation is used but the > result > is rounded to single precision then the result of norm(a) is 10000.5. Both > implementations are possible and probably present in different libs. > Therefore > the test should allow for both results. It might produce some printed > comment > about the implementation. > Thanks Rudiger, that explanation was helpful. https://github.com/scipy/scipy/pull/286 allows for both results in the test. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Aug 10 07:56:33 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 10 Aug 2012 13:56:33 +0200 Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 0.11.0 release candidate 1 In-Reply-To: References: <20120808183843.GE5866@onerussian.com> Message-ID: On Wed, Aug 8, 2012 at 8:53 PM, Ralf Gommers wrote: > > > On Wed, Aug 8, 2012 at 8:38 PM, Yaroslav Halchenko wrote: > >> I thought it might be of interest for you -- I have ran nosetests scipy >> against current head on an s390x Debian porter box: >> http://www.onerussian.com/tmp/tests-scipy-v0.4.3-5984-gfd5ceda-s390x.log >> summary: >> FAILED (SKIP=31, errors=15, failures=6) >> >> Thanks Yaroslav. > > Note that all the errors disappear if you run the tests with ">>> > scipy.test('full', verbose=2)". > > The 6 failures are: > 3 of these should disappear with https://github.com/scipy/scipy/pull/286. Not sure about the test_iv_cephes.. one, can you try? Otherwise we can mark it as knownfail for s390x; to do so it would be helpful if you provide a good way to detect that platform (output of platform.machine() perhaps?). No idea about the Qhull ones. Ralf > > ====================================================================== > FAIL: test_basic.TestNorm.test_stable > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/linalg/tests/test_basic.py", line 585, in test_stable > assert_almost_equal(norm(a) - 1e4, 0.5) > File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 468, in assert_almost_equal > raise AssertionError(msg) > AssertionError: > Arrays are not almost equal to 7 decimals > ACTUAL: 0.0 > DESIRED: 0.5 > > ====================================================================== > FAIL: test_datatypes.test_uint64_max > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/ndimage/tests/test_datatypes.py", line 57, in test_uint64_max > assert_true(x[1] > (2**63)) > AssertionError: False is not true > > ====================================================================== > FAIL: test_qhull.TestUtilities.test_degenerate_barycentric_transforms > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/usr/lib/pymodules/python2.7/numpy/testing/decorators.py", line 146, in skipper_func > return f(*args, **kwargs) > File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/spatial/tests/test_qhull.py", line 139, in test_degenerate_barycentric_transforms > assert_(bad_count < 20, bad_count) > File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 34, in assert_ > raise AssertionError(msg) > AssertionError: 20 > > ====================================================================== > FAIL: test_qhull.TestUtilities.test_more_barycentric_transforms > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/usr/lib/pymodules/python2.7/numpy/testing/decorators.py", line 146, in skipper_func > return f(*args, **kwargs) > File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/spatial/tests/test_qhull.py", line 199, in test_more_barycentric_transforms > unit_cube_tol=1.5e6*eps) > File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/spatial/tests/test_qhull.py", line 124, in _check_barycentric_transforms > assert_(ok.all(), "%s %s" % (err_msg, np.where(~ok))) > File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 34, in assert_ > raise AssertionError(msg) > AssertionError: ndim=4 (array([ 8071, 10512, 10513]),) > > ====================================================================== > FAIL: test_iv_cephes_vs_amos_mass_test (test_basic.TestBessel) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 1659, in test_iv_cephes_vs_amos_mass_test > assert_(dc[k] < 1e-9, (v[k], x[k], special.iv(v[k], x[k]), special.iv(v[k], x[k]+0j))) > File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 34, in assert_ > raise AssertionError(msg) > AssertionError: (189.2947429454936, 3.0238805556481037, 4.089165443940765e-317, 0j) > > ====================================================================== > FAIL: test_data.test_boost(,) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/special/tests/test_data.py", line 218, in _test_factory > test.check(dtype=dtype) > File "/home/yoh/scipy/scipy/install/lib/python2.7/site-packages/scipy/special/_testutils.py", line 224, in check > assert_(False, "\n".join(msg)) > File "/usr/lib/pymodules/python2.7/numpy/testing/utils.py", line 34, in assert_ > raise AssertionError(msg) > AssertionError: > Max |adiff|: 5.56451e-80 > Max |rdiff|: 6.01399e-12 > Bad results for the following points (in output 0): > -55.25 => 1.2813426521432485e-73 != 1.2813426521356121e-73 (rdiff 5.959647207094304e-12) > -55.0625 => 9.867326074925447e-73 != 9.86732607487198e-73 (rdiff 5.4185128296701245e-12) > -55.015625 => 4.736069454765531e-72 != 4.736069454740001e-72 (rdiff 5.390477071035947e-12) > -55.001953125 => 4.001152702605484e-71 != 4.0011527025839184e-71 (rdiff 5.3899101047365405e-12) > -55.0009765625 => 8.03371657917631e-71 != 8.033716579133006e-71 (rdiff 5.390260882973932e-12) > -55.00006103515625 => 1.2901278999535244e-69 != 1.2901278999465708e-69 (rdiff 5.389836286790528e-12) > -55.00001525878906 => 5.161460448793591e-69 != 5.161460448765773e-69 (rdiff 5.389643299825182e-12) > -55.00000762939453 => 1.0323237221382923e-68 != 1.0323237221327282e-68 (rdiff 5.3898770611534905e-12) > -54.99999237060547 => -1.0323869903952338e-68 != -1.0323869903896693e-68 (rdiff 5.389945636678977e-12) > -54.999969482421875 => -2.5812047538146166e-69 != -2.581204753800704e-69 (rdiff 5.390048438554985e-12) > -54.999755859375 => -3.229275765714629e-70 != -3.229275765697224e-70 (rdiff 5.38980884948699e-12) > -54.99951171875 => -1.6162223904478387e-70 != -1.6162223904391274e-70 (rdiff 5.389899375642087e-12) > -54.998046875 => -4.0644220032500644e-71 != -4.064422003228156e-71 (rdiff 5.390308306297719e-12) > -54.9921875 => -1.0403990765960148e-71 != -1.040399076590406e-71 (rdiff 5.391034204122906e-12) > -54.984375 => -5.369420317853762e-72 != -5.369420317824802e-72 (rdiff 5.393513012257176e-12) > -54.9375 => -1.6301847489550236e-72 != -1.6301847489461702e-72 (rdiff 5.430916285207302e-12) > -54.875 => -1.0680846658730133e-72 != -1.0680846658670925e-72 (rdiff 5.5434016349406124e-12) > -54.875 => -1.0680846658730133e-72 != -1.0680846658670925e-72 (rdiff 5.5434016349406124e-12) > -54.75 => -9.545836185682586e-73 != -9.545836185625178e-73 (rdiff 6.013992626968188e-12) > -54.625 => -1.206186475654961e-72 != -1.2061864756493961e-72 (rdiff 4.6135414163673135e-12) > > ---------------------------------------------------------------------- > Ran 6217 tests in 500.388s > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Fri Aug 10 15:51:04 2012 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 10 Aug 2012 12:51:04 -0700 Subject: [SciPy-Dev] Suggested Change to io.wavfile In-Reply-To: <5023D251.9090205@gmail.com> References: <5023D251.9090205@gmail.com> Message-ID: Hi, On Thu, Aug 9, 2012 at 8:08 AM, Brian Hone wrote: > Hi folks, > > I'm running into a wavfile read error which appears to be caused by > slight problems in wavfile meta-data. (Specifically, the meta-data > mis-reports the number of frames). Unfortunately, 2/3 of the wav files > I've randomly sampled have this problem, and most audio packages just > deal with it. > > I notice from a search that a lot of people have this problem with > io.wavfile.read: > > /usr/lib/python2.7/site-packages/scipy/io/wavfile.pyc in read(file) > 125 else: > 126 fmt = ' --> 127 size = struct.unpack(fmt, data)[0] > 128 fid.seek(size, 1) > 129 fid.close() > > > Here's a fix - just calculate the actual file length and use the minimum > or the file length and the meta-data reported length. > > 113,121c113 > < > < ## Calculate the actual file length in case meta-data is incorrect > < current_pos = fid.tell() > < fid.seek(0,2) > < actual_file_length = fid.tell() > < fid.seek( current_pos ) > < total_length = min( fsize, actual_file_length ) > < > < while (fid.tell() < total_length): > --- > > while (fid.tell() < fsize): Thanks for posting. I see we don't have a nominated maintainer for io.wavfile - Ralf - is that right? https://github.com/scipy/scipy/blob/master/doc/MAINTAINERS.rst.txt Does anyone who uses wav files feel able to comment here? Brian - please consider a test and a pull request? Please do email again if that's hard to do. Do you think we should omit a warning or make this fix optional, perhaps with the fix set as the default behavior? Thanks again, Matthew From ralf.gommers at gmail.com Fri Aug 10 16:02:07 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 10 Aug 2012 22:02:07 +0200 Subject: [SciPy-Dev] Suggested Change to io.wavfile In-Reply-To: References: <5023D251.9090205@gmail.com> Message-ID: On Fri, Aug 10, 2012 at 9:51 PM, Matthew Brett wrote: > Hi, > > On Thu, Aug 9, 2012 at 8:08 AM, Brian Hone wrote: > > Hi folks, > > > > I'm running into a wavfile read error which appears to be caused by > > slight problems in wavfile meta-data. (Specifically, the meta-data > > mis-reports the number of frames). Unfortunately, 2/3 of the wav files > > I've randomly sampled have this problem, and most audio packages just > > deal with it. > > > > I notice from a search that a lot of people have this problem with > > io.wavfile.read: > > > > /usr/lib/python2.7/site-packages/scipy/io/wavfile.pyc in read(file) > > 125 else: > > 126 fmt = ' > --> 127 size = struct.unpack(fmt, data)[0] > > 128 fid.seek(size, 1) > > 129 fid.close() > > > > > > Here's a fix - just calculate the actual file length and use the minimum > > or the file length and the meta-data reported length. > > > > 113,121c113 > > < > > < ## Calculate the actual file length in case meta-data is incorrect > > < current_pos = fid.tell() > > < fid.seek(0,2) > > < actual_file_length = fid.tell() > > < fid.seek( current_pos ) > > < total_length = min( fsize, actual_file_length ) > > < > > < while (fid.tell() < total_length): > > --- > > > while (fid.tell() < fsize): > > Thanks for posting. I see we don't have a nominated maintainer for > io.wavfile - Ralf - is that right? > Yes, unfortunately. I count 7 open tickets for wavfile, some of which are quite old. Wavfile is <200 lines of Python code, so fixing most of these probably won't be very difficult. If there's someone who is interested in this code and would be willing to put in some time, that would be great. Ralf > > https://github.com/scipy/scipy/blob/master/doc/MAINTAINERS.rst.txt > > Does anyone who uses wav files feel able to comment here? > > Brian - please consider a test and a pull request? Please do email > again if that's hard to do. Do you think we should omit a warning or > make this fix optional, perhaps with the fix set as the default > behavior? > > Thanks again, > > Matthew > _______________________________________________ > 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 scipy at samueljohn.de Sun Aug 12 07:03:55 2012 From: scipy at samueljohn.de (Samuel John) Date: Sun, 12 Aug 2012 13:03:55 +0200 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: References: Message-ID: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> Hi, I contributed to the homebrew python formula (i.e. the build script) recently and I heavily use numpy/scipy. In homebrew, it depends on the compiler and machine, which flags are added by default. We could change that, if we have a good reason to do so. But I got the feeling that python does fine with these flag and with clang. Perhaps numpy.distutils is the right place to tune? bests, Samuel On 10.08.2012, at 08:56, Ralf Gommers wrote: > > > On Fri, Aug 10, 2012 at 4:08 AM, Aaron Andalman wrote: > Ralf, > > Thanks for the information. You were correct; the -msse4 flag does appear to be coming from the brew installation of python. Grep reveals the flag in a Makefile, and editing the makefile altered the results of scipy python setup.py configure. Thus scipy now compiles! Thank you. > > However, I'm hoping to understand how and why scipy gets the -msse4 flag from the Makefile? Should this be modified? Or should the brew python formula be modified somehow? > > The flags with which Python itself is compiled are passed from Python distutils to numpy.distutils. In principle that's what we want. Only scipy doesn't compile with it; numpy does apparently. So we could try to filter out that flag in numpy.distutils, but the easier solution is to remove it from the homebrew Makefile. > > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From brianhone at gmail.com Mon Aug 13 08:25:05 2012 From: brianhone at gmail.com (Brian Hone) Date: Mon, 13 Aug 2012 08:25:05 -0400 Subject: [SciPy-Dev] Suggested Change to io.wavfile In-Reply-To: References: Message-ID: <5028F221.1070209@gmail.com> I'm in the process of spinning up a technical team that is using scipy for audio signal processing, so I expect that we'll be finding lots of issues with wavfile. I'll take a look at the bug list and see if we knock off a few of them as we go. Happy to do the test and pull request. Stupid question though - I haven't yet made the jump from good old svn to git. Can anyone give me the right sequence of commands so I don't mess it up? Brian On 8/11/2012 1:00 PM, scipy-dev-request at scipy.org wrote: > > Thanks for posting. I see we don't have a nominated maintainer for > io.wavfile - Ralf - is that right? > > https://github.com/scipy/scipy/blob/master/doc/MAINTAINERS.rst.txt > > Does anyone who uses wav files feel able to comment here? > > Brian - please consider a test and a pull request? Please do email > again if that's hard to do. Do you think we should omit a warning or > make this fix optional, perhaps with the fix set as the default > behavior? > > Thanks again, > > Matthew > > > ------------------------------ > > Message: 2 > Date: Fri, 10 Aug 2012 22:02:07 +0200 > From: Ralf Gommers > Subject: Re: [SciPy-Dev] Suggested Change to io.wavfile > To: SciPy Developers List > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Aug 10, 2012 at 9:51 PM, Matthew Brettwrote: > >> Hi, >> >> On Thu, Aug 9, 2012 at 8:08 AM, Brian Hone wrote: >>> Hi folks, >>> >>> I'm running into a wavfile read error which appears to be caused by >>> slight problems in wavfile meta-data. (Specifically, the meta-data >>> mis-reports the number of frames). Unfortunately, 2/3 of the wav files >>> I've randomly sampled have this problem, and most audio packages just >>> deal with it. >>> >>> I notice from a search that a lot of people have this problem with >>> io.wavfile.read: >>> >>> /usr/lib/python2.7/site-packages/scipy/io/wavfile.pyc in read(file) >>> 125 else: >>> 126 fmt = '>> --> 127 size = struct.unpack(fmt, data)[0] >>> 128 fid.seek(size, 1) >>> 129 fid.close() >>> >>> >>> Here's a fix - just calculate the actual file length and use the minimum >>> or the file length and the meta-data reported length. >>> >>> 113,121c113 >>> < >>> < ## Calculate the actual file length in case meta-data is incorrect >>> < current_pos = fid.tell() >>> < fid.seek(0,2) >>> < actual_file_length = fid.tell() >>> < fid.seek( current_pos ) >>> < total_length = min( fsize, actual_file_length ) >>> < >>> < while (fid.tell()< total_length): >>> --- >>> > while (fid.tell()< fsize): >> Thanks for posting. I see we don't have a nominated maintainer for >> io.wavfile - Ralf - is that right? >> > Yes, unfortunately. I count 7 open tickets for wavfile, some of which are > quite old. Wavfile is<200 lines of Python code, so fixing most of these > probably won't be very difficult. If there's someone who is interested in > this code and would be willing to put in some time, that would be great. > > Ralf > > >> https://github.com/scipy/scipy/blob/master/doc/MAINTAINERS.rst.txt >> >> Does anyone who uses wav files feel able to comment here? >> >> Brian - please consider a test and a pull request? Please do email >> again if that's hard to do. Do you think we should omit a warning or >> make this fix optional, perhaps with the fix set as the default >> behavior? >> >> Thanks again, >> >> Matthew >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> From matthew.brett at gmail.com Mon Aug 13 13:06:16 2012 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 13 Aug 2012 10:06:16 -0700 Subject: [SciPy-Dev] Suggested Change to io.wavfile In-Reply-To: <5028F221.1070209@gmail.com> References: <5028F221.1070209@gmail.com> Message-ID: Hi, On Mon, Aug 13, 2012 at 5:25 AM, Brian Hone wrote: > I'm in the process of spinning up a technical team that is using scipy > for audio signal processing, so I expect that we'll be finding lots of > issues with wavfile. I'll take a look at the bug list and see if we > knock off a few of them as we go. That would be very good indeed. Please do ask here if you have any questions, we're very happy to help (and grateful for your contribution). > Happy to do the test and pull request. Stupid question though - I > haven't yet made the jump from good old svn to git. Can anyone give me > the right sequence of commands so I don't mess it up? Aha - you have a little journey ahead of you :) There's a step-by-step guide here: http://docs.scipy.org/doc/numpy/dev/gitwash/index.html In essence, what you'll be doing is: Making a github account Forking the numpy repository to your own account Cloning your copy of numpy to your own computer with git Making a feature branch like 'wavfile-length-fix' Making the fix (with a test that tests the effect of the fix) Committing the fix Pushing your new branch back to your copy of numpy on github Making a pull request. These steps should be covered in the document(s) above, but please let us know if anything is not clear. Cheers, Matthew From ralf.gommers at gmail.com Mon Aug 13 14:30:44 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 13 Aug 2012 20:30:44 +0200 Subject: [SciPy-Dev] ANN: SciPy 0.11.0 release candidate 2 Message-ID: Hi, I am pleased to announce the availability of the second release candidate of SciPy 0.11.0. For this release many new features have been added, and over 120 tickets and pull requests have been closed. Also noteworthy is that the number of contributors for this release has risen to over 50. Some of the highlights are: - A new module, sparse.csgraph, has been added which provides a number of common sparse graph algorithms. - New unified interfaces to the existing optimization and root finding functions have been added. Sources and binaries can be found at http://sourceforge.net/projects/scipy/files/scipy/0.11.0rc2/, release notes are copied below. For this release candidate all known issues (with the exception of one Qhull issue on Debian, s390x platform) have been solved. In the meantime also OS X 10.8 was released, this RC contains a few build fixes for that platform. If no more serious issues are reported, the final release will be in one week. Cheers, Ralf ========================== SciPy 0.11.0 Release Notes ========================== .. note:: Scipy 0.11.0 is not released yet! .. contents:: SciPy 0.11.0 is the culmination of 8 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. Highlights of this release are: - A new module has been added which provides a number of common sparse graph algorithms. - New unified interfaces to the existing optimization and root finding functions have been added. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Our development attention will now shift to bug-fix releases on the 0.11.x branch, and on adding new features on the master branch. This release requires Python 2.4-2.7 or 3.1-3.2 and NumPy 1.5.1 or greater. New features ============ Sparse Graph Submodule ---------------------- The new submodule :mod:`scipy.sparse.csgraph` implements a number of efficient graph algorithms for graphs stored as sparse adjacency matrices. Available routines are: - :func:`connected_components` - determine connected components of a graph - :func:`laplacian` - compute the laplacian of a graph - :func:`shortest_path` - compute the shortest path between points on a positive graph - :func:`dijkstra` - use Dijkstra's algorithm for shortest path - :func:`floyd_warshall` - use the Floyd-Warshall algorithm for shortest path - :func:`breadth_first_order` - compute a breadth-first order of nodes - :func:`depth_first_order` - compute a depth-first order of nodes - :func:`breadth_first_tree` - construct the breadth-first tree from a given node - :func:`depth_first_tree` - construct a depth-first tree from a given node - :func:`minimum_spanning_tree` - construct the minimum spanning tree of a graph ``scipy.optimize`` improvements ------------------------------- The optimize module has received a lot of attention this release. In addition to added tests, documentation improvements, bug fixes and code clean-up, the following improvements were made: - A unified interface to minimizers of univariate and multivariate functions has been added. - A unified interface to root finding algorithms for multivariate functions has been added. - The L-BFGS-B algorithm has been updated to version 3.0. Unified interfaces to minimizers ```````````````````````````````` Two new functions ``scipy.optimize.minimize`` and ``scipy.optimize.minimize_scalar`` were added to provide a common interface to minimizers of multivariate and univariate functions respectively. For multivariate functions, ``scipy.optimize.minimize`` provides an interface to methods for unconstrained optimization (`fmin`, `fmin_powell`, `fmin_cg`, `fmin_ncg`, `fmin_bfgs` and `anneal`) or constrained optimization (`fmin_l_bfgs_b`, `fmin_tnc`, `fmin_cobyla` and `fmin_slsqp`). For univariate functions, ``scipy.optimize.minimize_scalar`` provides an interface to methods for unconstrained and bounded optimization (`brent`, `golden`, `fminbound`). This allows for easier comparing and switching between solvers. Unified interface to root finding algorithms ```````````````````````````````````````````` The new function ``scipy.optimize.root`` provides a common interface to root finding algorithms for multivariate functions, embeding `fsolve`, `leastsq` and `nonlin` solvers. ``scipy.linalg`` improvements ----------------------------- New matrix equation solvers ``````````````````````````` Solvers for the Sylvester equation (``scipy.linalg.solve_sylvester``, discrete and continuous Lyapunov equations (``scipy.linalg.solve_lyapunov``, ``scipy.linalg.solve_discrete_lyapunov``) and discrete and continuous algebraic Riccati equations (``scipy.linalg.solve_continuous_are``, ``scipy.linalg.solve_discrete_are``) have been added to ``scipy.linalg``. These solvers are often used in the field of linear control theory. QZ and QR Decomposition ```````````````````````` It is now possible to calculate the QZ, or Generalized Schur, decomposition using ``scipy.linalg.qz``. This function wraps the LAPACK routines sgges, dgges, cgges, and zgges. The function ``scipy.linalg.qr_multiply``, which allows efficient computation of the matrix product of Q (from a QR decompostion) and a vector, has been added. Pascal matrices ``````````````` A function for creating Pascal matrices, ``scipy.linalg.pascal``, was added. Sparse matrix construction and operations ----------------------------------------- Two new functions, ``scipy.sparse.diags`` and ``scipy.sparse.block_diag``, were added to easily construct diagonal and block-diagonal sparse matrices respectively. ``scipy.sparse.csc_matrix`` and ``csr_matrix`` now support the operations ``sin``, ``tan``, ``arcsin``, ``arctan``, ``sinh``, ``tanh``, ``arcsinh``, ``arctanh``, ``rint``, ``sign``, ``expm1``, ``log1p``, ``deg2rad``, ``rad2deg``, ``floor``, ``ceil`` and ``trunc``. Previously, these operations had to be performed by operating on the matrices' ``data`` attribute. LSMR iterative solver --------------------- LSMR, an iterative method for solving (sparse) linear and linear least-squares systems, was added as ``scipy.sparse.linalg.lsmr``. Discrete Sine Transform ----------------------- Bindings for the discrete sine transform functions have been added to ``scipy.fftpack``. ``scipy.interpolate`` improvements ---------------------------------- For interpolation in spherical coordinates, the three classes ``scipy.interpolate.SmoothSphereBivariateSpline``, ``scipy.interpolate.LSQSphereBivariateSpline``, and ``scipy.interpolate.RectSphereBivariateSpline`` have been added. Binned statistics (``scipy.stats``) ----------------------------------- The stats module has gained functions to do binned statistics, which are a generalization of histograms, in 1-D, 2-D and multiple dimensions: ``scipy.stats.binned_statistic``, ``scipy.stats.binned_statistic_2d`` and ``scipy.stats.binned_statistic_dd``. Deprecated features =================== ``scipy.sparse.cs_graph_components`` has been made a part of the sparse graph submodule, and renamed to ``scipy.sparse.csgraph.connected_components``. Calling the former routine will result in a deprecation warning. ``scipy.misc.radon`` has been deprecated. A more full-featured radon transform can be found in scikits-image. ``scipy.io.save_as_module`` has been deprecated. A better way to save multiple Numpy arrays is the ``numpy.savez`` function. The `xa` and `xb` parameters for all distributions in ``scipy.stats.distributions`` already weren't used; they have now been deprecated. Backwards incompatible changes ============================== Removal of ``scipy.maxentropy`` ------------------------------- The ``scipy.maxentropy`` module, which was deprecated in the 0.10.0 release, has been removed. Logistic regression in scikits.learn is a good and modern alternative for this functionality. Minor change in behavior of ``splev`` ------------------------------------- The spline evaluation function now behaves similarly to ``interp1d`` for size-1 arrays. Previous behavior:: >>> from scipy.interpolate import splev, splrep, interp1d >>> x = [1,2,3,4,5] >>> y = [4,5,6,7,8] >>> tck = splrep(x, y) >>> splev([1], tck) 4. >>> splev(1, tck) 4. Corrected behavior:: >>> splev([1], tck) array([ 4.]) >>> splev(1, tck) array(4.) This affects also the ``UnivariateSpline`` classes. Behavior of ``scipy.integrate.complex_ode`` ------------------------------------------- The behavior of the ``y`` attribute of ``complex_ode`` is changed. Previously, it expressed the complex-valued solution in the form:: z = ode.y[::2] + 1j * ode.y[1::2] Now, it is directly the complex-valued solution:: z = ode.y Minor change in behavior of T-tests ----------------------------------- The T-tests ``scipy.stats.ttest_ind``, ``scipy.stats.ttest_rel`` and ``scipy.stats.ttest_1samp`` have been changed so that 0 / 0 now returns NaN instead of 1. Other changes ============= The SuperLU sources in ``scipy.sparse.linalg`` have been updated to version 4.3 from upstream. The function ``scipy.signal.bode``, which calculates magnitude and phase data for a continuous-time system, has been added. The two-sample T-test ``scipy.stats.ttest_ind`` gained an option to compare samples with unequal variances, i.e. Welch's T-test. ``scipy.misc.logsumexp`` now takes an optional ``axis`` keyword argument. Authors ======= This release contains work by the following people (contributed at least one patch to this release, names in alphabetical order): * Jeff Armstrong * Chad Baker * Brandon Beacher + * behrisch + * borishim + * Matthew Brett * Lars Buitinck * Luis Pedro Coelho + * Johann Cohen-Tanugi * David Cournapeau * dougal + * Ali Ebrahim + * endolith + * Bj?rn Forsman + * Robert Gantner + * Sebastian Gassner + * Christoph Gohlke * Ralf Gommers * Yaroslav Halchenko * Charles Harris * Jonathan Helmus + * Andreas Hilboll + * Marc Honnorat + * Jonathan Hunt + * Maxim Ivanov + * Thouis (Ray) Jones * Christopher Kuster + * Josh Lawrence + * Denis Laxalde + * Travis Oliphant * Joonas Paalasmaa + * Fabian Pedregosa * Josef Perktold * Gavin Price + * Jim Radford + * Andrew Schein + * Skipper Seabold * Jacob Silterra + * Scott Sinclair * Alexis Tabary + * Martin Teichmann * Matt Terry + * Nicky van Foreest + * Jacob Vanderplas * Patrick Varilly + * Pauli Virtanen * Nils Wagner + * Darryl Wally + * Stefan van der Walt * Liming Wang + * David Warde-Farley + * Warren Weckesser * Sebastian Werk + * Mike Wimmer + * Tony S Yu + A total of 55 people contributed to this release. People with a "+" by their names contributed a patch for the first time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scipy at samueljohn.de Tue Aug 14 10:53:14 2012 From: scipy at samueljohn.de (Samuel John) Date: Tue, 14 Aug 2012 16:53:14 +0200 Subject: [SciPy-Dev] ANN: SciPy 0.11.0 release candidate 2 In-Reply-To: References: Message-ID: <55FCB433-349E-468C-B59D-315C24A36BBA@samueljohn.de> Great work so far, really looking forward to this release! FAILED (KNOWNFAIL=12, SKIP=27, failures=66) On 13.08.2012, at 20:30, Ralf Gommers wrote: [...] > release candidate of SciPy 0.11.0. On OS X 10.8 here with `brew install python` and using gfortran 4.7.0 built from source with gfortran. I compiled python and numpy with clang using latest Xcode. Numpy tests all pass. For scipy, I get quite a lot of these arpack symmetric_modes precision failures: FAIL: test_arpack.test_symmetric_modes(True, , 'd', 2, 'SA', None, 0.5, , None, 'buckling') ---------------------------------------------------------------------- [snip ] AssertionError: Not equal to tolerance rtol=4.44089e-13, atol=4.44089e-13 error for eigsh:general, typ=d, which=SA, sigma=0.5, mattype=asarray, OPpart=None, mode=buckling (mismatch 100.0%) x: array([[ 15.86892331, 0.0549568 ], [ 14.15864153, 0.31381369], [ 10.99691307, 0.37543458],... y: array([[ 3.19549052, 0.0549568 ], [ 2.79856422, 0.31381369], [ 1.67526354, 0.37543458],... Not sure how severe that is. Note: I had to add '-mno-avx' to numpy's extra_flags because '-march=native' lead gcc to spit out avx assembly code, which is not understood by Apple's assembler. But that does not seem to be related, to the arpack mismatch issues. The remaining 3 failues: ====================================================================== FAIL: test_qz_double_sort (test_decomp.TestQZ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/linalg/tests/test_decomp.py", line 1728, in test_qz_double_sort [ 0. , 0. , 0. , -12.8217]]), 4) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 800, in assert_array_almost_equal header=('Arrays are not almost equal to %d decimals' % decimal)) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 636, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 4 decimals (mismatch 18.75%) x: array([[ 3.57864105e+01, 8.09060561e+01, -1.20629018e+01, -9.49804357e+00], [ 0.00000000e+00, 2.76377218e+00, 2.35052177e+00,... y: array([[ 3.57864000e+01, -8.09061000e+01, -1.20629000e+01, -9.49800000e+00], [ 0.00000000e+00, 2.76380000e+00, -2.35050000e+00,... ====================================================================== FAIL: test_stats.test_ttest_ind ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/stats/tests/test_stats.py", line 1556, in test_ttest_ind assert_array_almost_equal([t,p],(tr,pr)) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 800, in assert_array_almost_equal header=('Arrays are not almost equal to %d decimals' % decimal)) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 636, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 6 decimals (mismatch 50.0%) x: array([ 1.09127469, 0.4998416 ]) y: array([ 1.09127469, 0.27647819]) ====================================================================== FAIL: test_stats.test_ttest_ind_with_uneq_var ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/stats/tests/test_stats.py", line 1596, in test_ttest_ind_with_uneq_var assert_array_almost_equal([t,p], [tr, pr]) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 800, in assert_array_almost_equal header=('Arrays are not almost equal to %d decimals' % decimal)) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 636, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 6 decimals (mismatch 50.0%) x: array([-0.68649513, 0.81407518]) y: array([-0.68649513, 0.53619491]) From ralf.gommers at gmail.com Tue Aug 14 13:12:01 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 14 Aug 2012 19:12:01 +0200 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.11.0 release candidate 2 In-Reply-To: <50297AFE.3020806@uci.edu> References: <50297AFE.3020806@uci.edu> Message-ID: On Tue, Aug 14, 2012 at 12:09 AM, Christoph Gohlke wrote: > On 8/13/2012 11:30 AM, Ralf Gommers wrote: > > Hi, > > > > I am pleased to announce the availability of the second release > > candidate of SciPy 0.11.0. For this release many new features have been > > added, and over 120 tickets and pull requests have been closed. Also > > noteworthy is that the number of contributors for this release has risen > > to over 50. Some of the highlights are: > > > > - A new module, sparse.csgraph, has been added which provides a > > number of common sparse graph algorithms. > > - New unified interfaces to the existing optimization and root > > finding functions have been added. > > > > Sources and binaries can be found at > > http://sourceforge.net/projects/scipy/files/scipy/0.11.0rc2/, release > > notes are copied below. > > > > For this release candidate all known issues (with the exception of one > > Qhull issue on Debian, s390x platform) have been solved. In the meantime > > also OS X 10.8 was released, this RC contains a few build fixes for that > > platform. > > > > If no more serious issues are reported, the final release will be in one > > week. > > > > Cheers, > > Ralf > > > Hi Ralf, > > test_qz_double_sort is now failing in all msvc9/MKL builds (Python 2.6 > to 3.2, 32 and 64 bit): > Hmm, I think that that excludes anything compiler or ATLAS specific. This is the only test which really checks the results are correct for float input, almost all the other test only check that the output of qz is self-consistent (no hard-coded expected output). It seems that a couple more tests would be helpful. This issue has held up the release for too long already, so unless someone has time to get it resolved this week, I propose the following: 1. Figure out if the problem is the sort function or something else. 2. If it's sort, disable it. Otherwise remove the qz function from the 0.11.x branch. Ralf > > FAIL: test_qz_double_sort (test_decomp.TestQZ) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "X:\Python32\lib\site-packages\scipy\linalg\tests\test_decomp.py", line > 1728, in test_qz_double_sort > [ 0. , 0. , 0. , -12.8217]]), 4) > File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line > 800, in assert_array_almost_equal > header=('Arrays are not almost equal to %d decimals' % decimal)) > File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line > 636, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Arrays are not almost equal to 4 decimals > > (mismatch 62.5%) > x: array([[-14.66007968, -27.25220511, -31.55732717, -29.0823765 ], > [ 0. , 30.23027809, 42.47668118, 52.55438253], > [ 0. , 0. , 0.71600413, -2.77147791], > [ 0. , 0. , 0. , 2.50096525]]) > y: array([[ 3.57864000e+01, -8.09061000e+01, -1.20629000e+01, > -9.49800000e+00], > [ 0.00000000e+00, 2.76380000e+00, -2.35050000e+00,... > > > Christoph > > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Aug 14 17:47:19 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 14 Aug 2012 23:47:19 +0200 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> References: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> Message-ID: On Sun, Aug 12, 2012 at 1:03 PM, Samuel John wrote: > Hi, > > I contributed to the homebrew python formula (i.e. the build script) > recently and I heavily use numpy/scipy. > > In homebrew, it depends on the compiler and machine, which flags are added > by default. > We could change that, if we have a good reason to do so. But I got the > feeling that python does fine with these flag and with clang. > I downloaded a tarball with Python sources from python.org and searched through it (also the generated makefile), but couldn't find so quickly where this flag is added. Do you happen to know? Ralf > Perhaps numpy.distutils is the right place to tune? > > bests, > Samuel > > > > On 10.08.2012, at 08:56, Ralf Gommers wrote: > > > > > > > On Fri, Aug 10, 2012 at 4:08 AM, Aaron Andalman > wrote: > > Ralf, > > > > Thanks for the information. You were correct; the -msse4 flag does > appear to be coming from the brew installation of python. Grep reveals the > flag in a Makefile, and editing the makefile altered the results of scipy > python setup.py configure. Thus scipy now compiles! Thank you. > > > > However, I'm hoping to understand how and why scipy gets the -msse4 flag > from the Makefile? Should this be modified? Or should the brew python > formula be modified somehow? > > > > The flags with which Python itself is compiled are passed from Python > distutils to numpy.distutils. In principle that's what we want. Only scipy > doesn't compile with it; numpy does apparently. So we could try to filter > out that flag in numpy.distutils, but the easier solution is to remove it > from the homebrew Makefile. > > > > Ralf > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aron at ahmadia.net Tue Aug 14 17:56:53 2012 From: aron at ahmadia.net (Aron Ahmadia) Date: Wed, 15 Aug 2012 00:56:53 +0300 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: References: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> Message-ID: Ralf, I'm not sure how much you enjoy reading Ruby, but here are the details on where things are happening in brew. Here's the Python formula for actually downloading/configuring/building (no flags added here): https://github.com/mxcl/homebrew/blob/master/Library/Formula/python.rb Compiler flags are picked up here: https://github.com/mxcl/homebrew/blob/master/Library/Homebrew/extend/ENV.rb A -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Aug 15 02:37:05 2012 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 15 Aug 2012 08:37:05 +0200 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: References: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> Message-ID: On Tue, Aug 14, 2012 at 11:56 PM, Aron Ahmadia wrote: > Ralf, > > I'm not sure how much you enjoy reading Ruby, but here are the details on > where things are happening in brew. > > Here's the Python formula for actually downloading/configuring/building > (no flags added here): > https://github.com/mxcl/homebrew/blob/master/Library/Formula/python.rb > Compiler flags are picked up here: > https://github.com/mxcl/homebrew/blob/master/Library/Homebrew/extend/ENV.rb > Thanks Aron. Ruby reads pretty much like Python, with a few : and => mixed in, so no problem. So they do add all possible sse flags, like: def gcc .... set_cpu_cflags 'core2 -msse4', :penryn => 'core2 -msse4.1' If you do a regular Framework build with configure/make steps, this doesn't happen (I think). So the question is what to do now. Perhaps this can be fixed in scipy, does anyone know? And are other projects using distutils likely affected by this? If so, it should be fixed in Homebrew anyway. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From scipy at samueljohn.de Wed Aug 15 17:30:38 2012 From: scipy at samueljohn.de (Samuel John) Date: Wed, 15 Aug 2012 23:30:38 +0200 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: References: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> Message-ID: <919D7CB8-5BA0-41C9-AE31-4A006B8A11AB@samueljohn.de> Thanks Ralf and Aron! Homebrews default is: Python is compiled with clang. I have not run into problems so far. I wonder what the problems were, Aaron A. had with clang. I even have prepared a numpy and scipy formula (homebrew speak for install script) that builds with clang (and gfortran-4.7). It's not in the main repository, yet. Builds without problems. However, you can `brew install python --use-llvm` which is a bad name for "please use llvm-gcc instead of clang" and that adds the "-msse4" flag, depending on the cpu type. Aaron Andalman has done this, otherwise clang would have been used, with the flag `-march=native` in CFLAGS and CXXFLAGS. Python's distutils remembers the build-time flags. This is how they end up being re-used for scipy. Very hard to fix (speak remove) things from there later on. Distutils you damn bastard! Hoping for distutils2 :-) I got the feeling that llvm-gcc (4.2) is a dead-end since Apple is not updating it to be compatible with newer gcc versions. Clang is developing fast. Getting numpy/scipy to work nicely with clang is IMHO the way to go. Samuel On 15.08.2012, at 08:37, Ralf Gommers wrote: > > > On Tue, Aug 14, 2012 at 11:56 PM, Aron Ahmadia wrote: > Ralf, > > I'm not sure how much you enjoy reading Ruby, but here are the details on where things are happening in brew. > > Here's the Python formula for actually downloading/configuring/building (no flags added here): https://github.com/mxcl/homebrew/blob/master/Library/Formula/python.rb > Compiler flags are picked up here: https://github.com/mxcl/homebrew/blob/master/Library/Homebrew/extend/ENV.rb > > Thanks Aron. Ruby reads pretty much like Python, with a few : and => mixed in, so no problem. > > So they do add all possible sse flags, like: > > def gcc > .... > set_cpu_cflags 'core2 -msse4', :penryn => 'core2 -msse4.1' > > If you do a regular Framework build with configure/make steps, this doesn't happen (I think). So the question is what to do now. Perhaps this can be fixed in scipy, does anyone know? And are other projects using distutils likely affected by this? If so, it should be fixed in Homebrew anyway. > > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From santosh.singh at ansys.com Thu Aug 16 09:38:38 2012 From: santosh.singh at ansys.com (Santosh Pratap Singh) Date: Thu, 16 Aug 2012 19:08:38 +0530 Subject: [SciPy-Dev] scipy-0.10.1 compilation on 64 bit windows in debug mode Message-ID: Hi All, I am trying to compile a debug version of the scipy-0.10.1 extension on 64 bit windows. I have also compiled the python-2.7.3 and numpy-1.6.2 in debug mode. When I am building scipy, I ran into the problem C:\cpython\Debug\scipy\0_10_1\scipy-0.10.1>python_d setup.py config --compiler=msvc --fcompiler=intelvem build --debug compile options: '-g -IC:\cpython\Debug\CPython\2_7_3\winx64\Debug\python\lib\site-packages\numpy\core\include -c' ifort.exe:f77: scipy\fftpack\src\dfftpack\dcosqb.f ifort: command line warning #10131: extension 'M' not supported ignored in optio n '/Qax' *ifort: command line error: option '/g' is ambiguous* error: Command "C:\Program Files (x86)\Intel\Compiler\11.1\060\Bin\intel64\ifort.exe -FI -w90 -w95 /nologo /MD /nbs /Qlowercase /us /O1 /QaxM -g -IC:\cpython\Debug\CPython\2_7_3\winx64\Debug\python\lib\site-packages\numpy\core\include -c /c scipy\fftpack\src\dfftpack\dcosqb.f /Fobuild\temp.win-amd64-2.7\scipy\fftpack\src\dfftpack\dcosqb.o" failed with exit status 1 Can some one help me in this? Am I missing something? Thanks. Santosh -------------- next part -------------- An HTML attachment was scrubbed... URL: From scipy at samueljohn.de Fri Aug 17 05:46:17 2012 From: scipy at samueljohn.de (Samuel John) Date: Fri, 17 Aug 2012 11:46:17 +0200 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: <919D7CB8-5BA0-41C9-AE31-4A006B8A11AB@samueljohn.de> References: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> <919D7CB8-5BA0-41C9-AE31-4A006B8A11AB@samueljohn.de> Message-ID: <9CE6404A-BB7C-428D-B900-0215F334C49D@samueljohn.de> I will update the python and python3 formula in homebrew and remove `-march=X` and other optimization flags and also compiler specific flags. But still I think python/distutils is the root. Then the `-msse4` issue should be resolved. Sorry, homebrew caused you trouble here. Samuel From tom.grydeland at gmail.com Thu Aug 23 10:28:39 2012 From: tom.grydeland at gmail.com (Tom Grydeland) Date: Thu, 23 Aug 2012 16:28:39 +0200 Subject: [SciPy-Dev] extended functionality of max/min ufuncs Message-ID: Hi all, I'm working on a system to translate (EXELIS/ITTVIS/RSI) IDL to Python/Numpy. The results are close to usable for many purposes, but some simple constructs are causing snags I was hoping you could help me with. IDL's MAX function supports a second (output) argument which will contain the index of the maximum value. One can write PRINT, MAX(x, id), id to get the value and index of the maximum element. In Numpy, I could do id = np.argmax(x); print x[id], id to get the same results in two statements. However, I can give MAX an extra keyword /NAN to tell it to ignore NaN and infinities. In Numpy, I have np.nanmax, but no np.nanargmax. In addition, MAX has the output keywords MIN=value and SUBSCRIPT_MIN=index to return the minimum value and its index from the same function call. Similarly, MIN has output keywords MAX=value and SUBSCRIPT_MAX=index, so I can get max/min values and their indices (ignoring NaNs) in a single call -- in Numpy I would need two calls, two indexing operations, one temporary array of values and one of indices. Would it be hard to add similar functionality to Numpy's min() and max() functions? Is it desirable? Regards, -- Tom Grydeland From scipy at samueljohn.de Fri Aug 24 03:42:33 2012 From: scipy at samueljohn.de (Samuel John) Date: Fri, 24 Aug 2012 09:42:33 +0200 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: <9CE6404A-BB7C-428D-B900-0215F334C49D@samueljohn.de> References: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> <919D7CB8-5BA0-41C9-AE31-4A006B8A11AB@samueljohn.de> <9CE6404A-BB7C-428D-B900-0215F334C49D@samueljohn.de> Message-ID: <2FB1A728-A9DA-41CE-86AC-6A7E3B880FBD@samueljohn.de> Homebrew's Python (and Python 3) has been updated to remove the cpu specific optimization flags. On 17.08.2012, at 11:46, Samuel John wrote: > I will update the python and python3 formula in homebrew and remove `-march=X` and other optimization flags and also compiler specific flags. > But still I think python/distutils is the root. > > Then the `-msse4` issue should be resolved. > Sorry, homebrew caused you trouble here. > > Samuel From aron at ahmadia.net Fri Aug 24 04:54:13 2012 From: aron at ahmadia.net (Aron Ahmadia) Date: Fri, 24 Aug 2012 09:54:13 +0100 Subject: [SciPy-Dev] Mountain Lion Scipy-dev build fails (Ralf Gommers) In-Reply-To: <2FB1A728-A9DA-41CE-86AC-6A7E3B880FBD@samueljohn.de> References: <34F8A319-A742-491E-B544-814FF2CAF686@samueljohn.de> <919D7CB8-5BA0-41C9-AE31-4A006B8A11AB@samueljohn.de> <9CE6404A-BB7C-428D-B900-0215F334C49D@samueljohn.de> <2FB1A728-A9DA-41CE-86AC-6A7E3B880FBD@samueljohn.de> Message-ID: Thanks Samuel. -Aron On Fri, Aug 24, 2012 at 8:42 AM, Samuel John wrote: > Homebrew's Python (and Python 3) has been updated to remove the cpu > specific optimization flags. > > On 17.08.2012, at 11:46, Samuel John wrote: > > > I will update the python and python3 formula in homebrew and remove > `-march=X` and other optimization flags and also compiler specific flags. > > But still I think python/distutils is the root. > > > > Then the `-msse4` issue should be resolved. > > Sorry, homebrew caused you trouble here. > > > > Samuel > > _______________________________________________ > 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 stefan at sun.ac.za Fri Aug 24 09:12:34 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 24 Aug 2012 06:12:34 -0700 Subject: [SciPy-Dev] SciPy.org Website Move and Redesign In-Reply-To: References: Message-ID: On Fri, Jul 27, 2012 at 11:35 AM, Fernando Perez wrote: > And precisely having the site moved over to a system where: > > - it's trivial to delegate website work to a separate team who can > collaborate with the regular github flow (branches, PRs, etc) to > manage the web content. > > - form and content are separated, with templates and CSS for all formal display Is this transition still on track? We should push it through, even if it means living with a slightly outdated website for a week or two. (I'm sure we'll all feel much more comfortable updating the web site using PRs than whatever the current mechanism might be.) St?fan From mount.sarah at gmail.com Sat Aug 25 17:23:08 2012 From: mount.sarah at gmail.com (Sarah Mount) Date: Sat, 25 Aug 2012 22:23:08 +0100 Subject: [SciPy-Dev] scipy.ndimage.measurements.label Message-ID: Hi there, sorry if this is a bit of a daft and random question, but I couldn't figure it out from reading the source. What algorithm does scipy.ndimage.measurements.label implement? Many thanks, Sarah -- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2 From kevin.dunn at mcmaster.ca Sun Aug 26 14:54:12 2012 From: kevin.dunn at mcmaster.ca (Kevin Dunn) Date: Sun, 26 Aug 2012 14:54:12 -0400 Subject: [SciPy-Dev] SciPy.org Website Move and Redesign In-Reply-To: References: Message-ID: On Wed, Jul 25, 2012 at 5:59 PM, Pauli Virtanen wrote: > Kyle Mandli gmail.com> writes: > [clip] > > 1) Mailing lists - Leave these as there's a lot of content there > > and we are worried about losing history and users if we even > > attempted to move this (plus we don't have a good alternative). > > Mailing lists are going to be needed. They don't necessarily need to > be hosted on the current scipy.org machine, but it's probably best not to > touch what has been working reliably. > > > 2) Scipy.org (and numpy.org) - Move the content to a repository under > the > > Scipy organization on github that would contain a sphinx representation > > of the content that people can make pull requests to. There would be > > another repository that the built content would then be pushed to and > > that github would show as the website. David Warde-Farley has made > > an attempt at converting many of the scipy pages over to sphinx but it > > was never used (https://github.com/dwf/scipy-website). I noticed there > > were a few attempts at this a while ago (> 2 years). > > Note that the scipy.github.com site is up with a Git repo set up at > https://github.com/scipy/scipy.org-new/ > Similarly, numpy.scipy.org site has already moved to Github. > > I would see these repos as the central point for any further work. > David's work is not merged there, but it could be merged (where > applicable --- some of the content in scipy.org is outdated). > > > 3) Trac Projects - Numpy is in the process (or so we thought) > [clip] > > I think the trac projects are a separate issue --- web site redesign > can either precede or come after what is done with Trac. > > IMO, one of the first steps to do is to design a website layout > skeleton that can be used appropriately on scipy.org, and daughter > sites, docs.scipy.org, scipy-central.org, etc. This does not have > to be in Sphinx format at first, just plain HTML+whatever, it's easy > to hack in later. It also doesn't have to be great, but it does have > to exist, and one has to think a bit about how and where to put the > navigation tools. > > The amount of relevant "official" content on scipy.org is actually > not very big, I think. > > The main issue is more on what to do with the Cookbook/Topical software > sections, which in my opinion are not very well-suited to a > Sphinx-generated static site. Why this hasn't moved forwards is > probably largely due to not reaching a decision on what actually > to do with this material. > > The current best bet as a replacement (apart from keeping these in Moin) > would probably be scipy-central.org --- which I'm sure would also benefit > greatly from additional love. Enthusiastic Django-capable people might be > interested to take a look at improving it. > > -- > Pauli Virtanen Hi everyone, the scipy-central.org "maintainer" here; in inverted commas, because I've been doing no maintenance over the past 12 to 18 months. I'd like to offer all the scipy-central.org material over to the community to keep going with it and improve it. I expected to have time to do it myself, but new jobs and a different career path have prevented me from implementing improvements that Pauli and several others have proposed in the past. This might be a good time to consider the issue, even just from a branding perspective, to get it all looking coherent. If anyone wants to get back to me on this, I can pass over 1. Some/all of the domain names (those not transferred I will let lapse on the next renewal in June 2013) scipy-central.org(DNS) scpyce.org(DNS) scipy-central.com(MX) Forward ( http://scipy-central.org ) scipy-central.net(MX) Forward ( http://scipy-central.org ) scipycentral.com(MX) Forward ( http://scipy-central.org ) scipycentral.net(MX) Forward ( http://scipy-central.org ) scipycentral.org(MX) Forward ( http://scipy-central.org ) scpyce.com(MX) Forward ( http://scpyce.org ) scpyce.net(MX) Forward ( http://scpyce.org ) 2. all Django code, media files, templates, CSS and HTML, including detailed instructions on how to install and use it are already at https://github.com/kgdunn/SciPyCentral Please take a look at this to judge the complexity of the move. 3. backup scripts: local and off-site 4. the PostgreSQL database [23Mb] 5. monthly backup snapshots going back to July 2011, when the site started [450Mb] 6. the Google Analytics account (not sure how to transfer this) 7. the original artwork files for the media There are some interesting page hit and search analytics in raw data (item 5) and from Google (item 6) that someone might want to look at. I currently host the site on Webfaction. The new owner(s) will require a similar unix-type server with: * Python and Django, * webserver (e.g. Apache, or nginx), * ability to email for account creation, password resets and submission confirmation * rsync for remote backup, * and other miscellaneous utilities: South, Pygments, Sphinx, Haystack search with Xapian, PIL, etc The new owner(s) will also inherit 2 pull requests and 45 issues on the above-mentioned Github site. Other proposals made in the Scipy-Dev mailing lists over the past year also exist. I'm in no rush to hand it over; just putting it out there that someone or some group more capable and with more time can definitely do a better job of it than me. Let me know how the community wants to proceed: please let's keep the discussion public so everyone can contribute. Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.mandli at gmail.com Mon Aug 27 13:57:01 2012 From: kyle.mandli at gmail.com (Kyle Mandli) Date: Mon, 27 Aug 2012 10:57:01 -0700 Subject: [SciPy-Dev] SciPy.org Website Move and Redesign In-Reply-To: References: Message-ID: <3C6CC713CBD949D2A51AB3C9859B493F@gmail.com> I kind of dropped the ball on this as I have been traveling for the past month. I think we are ready to move forward on this and at least get the pieces in place. I am still not clear exactly what the current status of the scipy.org-new and scipy.github.com repos on github are. Can anyone speak to this? On a related topic, I have been searching out someone who may be able to do some redesign work on the site but was not successful (at least a free option). Any suggestions for someone with some design experience that could update the look of the site a bit please let us know. Kyle On Friday, August 24, 2012 at 10:00 AM, scipy-dev-request at scipy.org wrote: > On Fri, Jul 27, 2012 at 11:35 AM, Fernando Perez wrote: > > And precisely having the site moved over to a system where: > > > > - it's trivial to delegate website work to a separate team who can > > collaborate with the regular github flow (branches, PRs, etc) to > > manage the web content. > > > > - form and content are separated, with templates and CSS for all formal display > > Is this transition still on track? We should push it through, even if > it means living with a slightly outdated website for a week or two. > (I'm sure we'll all feel much more comfortable updating the web site > using PRs than whatever the current mechanism might be.) > > St?fan From josef.pktd at gmail.com Mon Aug 27 16:33:30 2012 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 27 Aug 2012 16:33:30 -0400 Subject: [SciPy-Dev] pull chatter are not updating Message-ID: Is there a new alternative to the feeds http://new.scipy.org/scipy-pull.xml http://new.scipy.org/scipy-chatter.xml They didn't update for a month. Thanks, Josef From jason-sage at creativetrax.com Mon Aug 27 18:09:57 2012 From: jason-sage at creativetrax.com (Jason Grout) Date: Mon, 27 Aug 2012 17:09:57 -0500 Subject: [SciPy-Dev] pull chatter are not updating In-Reply-To: References: Message-ID: <503BF035.2010200@creativetrax.com> On 8/27/12 3:33 PM, josef.pktd at gmail.com wrote: > Is there a new alternative to the feeds > > http://new.scipy.org/scipy-pull.xml > http://new.scipy.org/scipy-chatter.xml > > They didn't update for a month. That sounds like about the time period for the new notification system. Just taking a wild guess: I wonder if that somehow broke things? https://github.com/blog/1204-notifications-stars Thanks, Jason From josef.pktd at gmail.com Tue Aug 28 22:09:45 2012 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 28 Aug 2012 22:09:45 -0400 Subject: [SciPy-Dev] pull chatter are not updating In-Reply-To: <503BF035.2010200@creativetrax.com> References: <503BF035.2010200@creativetrax.com> Message-ID: On Mon, Aug 27, 2012 at 6:09 PM, Jason Grout wrote: > On 8/27/12 3:33 PM, josef.pktd at gmail.com wrote: >> Is there a new alternative to the feeds >> >> http://new.scipy.org/scipy-pull.xml >> http://new.scipy.org/scipy-chatter.xml >> >> They didn't update for a month. > > That sounds like about the time period for the new notification system. > Just taking a wild guess: I wonder if that somehow broke things? > > https://github.com/blog/1204-notifications-stars Thanks for the reminder. I had also lost some other notifications because I didn't "Watch" It looks like I'm getting now regular emails for the Pull Requests. Josef > > Thanks, > > Jason > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From pav at iki.fi Wed Aug 29 14:58:51 2012 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 29 Aug 2012 18:58:51 +0000 (UTC) Subject: [SciPy-Dev] SciPy.org Website Move and Redesign References: <3C6CC713CBD949D2A51AB3C9859B493F@gmail.com> Message-ID: Kyle Mandli gmail.com> writes: > I kind of dropped the ball on this as I have been traveling > for the past month. I think we are ready to move > forward on this and at least get the pieces in place. > I am still not clear exactly what the current status of > the scipy.org-new and scipy.github.com repos on github are. > Can anyone speak to this? The status of scipy.org-new repository is that it is incomplete, but future work should build on it, as it has some basic infrastructure in place. (The conference/ directory in that repo can be ignored/removed, as I believe it is outdated.) The scipy.github.com contains the HTML output built from scipy.org-new. > On a related topic, I have been searching out someone who may be > able to do some redesign work on the site but > was not successful (at least a free option). Any suggestions > for someone with some design experience that > could update the look of the site a bit please let us know. Well, the only requirement is that it should look better and more organized than the current scipy.org page. That probably does not require 1337 design chops, just some CSS/HTML skills :) Also, somehow the typography on scipy.github.com is off, the text looks ugly and is difficult to read. The main point IMO is just to come up with some visual consistency and navigation scheme between the main site, the documentation, etc. This doesn't have to be perfect, the main thing is just to think up some sort of a consistent framework. The second thing related to content would be to think what to do with the different Scipys: - "Scipy the community site" - "Scipy the library" Well, anyway, the above is just my suggestion on what could be done. If you can think of some other ways to improve the situation, please don't let this hold you up. -- Pauli Virtanen From pav at iki.fi Wed Aug 29 15:02:22 2012 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 29 Aug 2012 19:02:22 +0000 (UTC) Subject: [SciPy-Dev] pull chatter are not updating References: <503BF035.2010200@creativetrax.com> Message-ID: Jason Grout creativetrax.com> writes: > On 8/27/12 3:33 PM, josef.pktd gmail.com wrote: > > Is there a new alternative to the feeds > > > > http://new.scipy.org/scipy-pull.xml > > http://new.scipy.org/scipy-chatter.xml > > > > They didn't update for a month. > > That sounds like about the time period for the new notification system. > Just taking a wild guess: I wonder if that somehow broke things? Yep, that seems likely. The github json api has been in flux lately, so that keeps breaking things. I don't have time to fix this immediately, so it'll have to wait for some time. If someone else wants to take a look, look here: https://github.com/pv/github-pull-request-fwd From fperez.net at gmail.com Wed Aug 29 22:59:47 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 29 Aug 2012 19:59:47 -0700 Subject: [SciPy-Dev] A sad day for our community. John Hunter: 1968-2012. Message-ID: Dear friends and colleagues, [please excuse a possible double-post of this message, in-flight internet glitches] I am terribly saddened to report that yesterday, August 28 2012 at 10am, John D. Hunter died from complications arising from cancer treatment at the University of Chicago hospital, after a brief but intense battle with this terrible illness. John is survived by his wife Miriam, his three daughters Rahel, Ava and Clara, his sisters Layne and Mary, and his mother Sarah. Note: If you decide not to read any further (I know this is a long message), please go to this page for some important information about how you can thank John for everything he gave in a decade of generous contributions to the Python and scientific communities: http://numfocus.org/johnhunter. Just a few weeks ago, John delivered his keynote address at the SciPy 2012 conference in Austin centered around the evolution of matplotlib: http://www.youtube.com/watch?v=e3lTby5RI54 but tragically, shortly after his return home he was diagnosed with advanced colon cancer. This diagnosis was a terrible discovery to us all, but John took it with his usual combination of calm and resolve, and initiated treatment procedures. Unfortunately, the first round of chemotherapy treatments led to severe complications that sent him to the intensive care unit, and despite the best efforts of the University of Chicago medical center staff, he never fully recovered from these. Yesterday morning, he died peacefully at the hospital with his loved ones at his bedside. John fought with grace and courage, enduring every necessary procedure with a smile on his face and a kind word for all of his caretakers and becoming a loved patient of the many teams that ended up involved with his case. This was no surprise for those of us who knew him, but he clearly left a deep and lasting mark even amongst staff hardened by the rigors of oncology floors and intensive care units. I don't need to explain to this community the impact of John's work, but allow me to briefly recap, in case this is read by some who don't know the whole story. In 2002, John was a postdoc at the University of Chicago hospital working on the analysis of epilepsy seizure data in children. Frustrated with the state of the existing proprietary solutions for this class of problems, he started using Python for his work, back when the scientific Python ecosystem was much, much smaller than it is today and this could have been seen as a crazy risk. Furthermore, he found that there were many half-baked solutions for data visualization in Python at the time, but none that truly met his needs. Undeterred, he went on to create matplotlib (http://matplotlib.org) and thus overcome one of the key obstacles for Python to become the best solution for open source scientific and technical computing. Matplotlib is both an amazing technical achievement and a shining example of open source community building, as John not only created its backbone but also fostered the development of a very strong development team, ensuring that the talent of many others could also contribute to this project. The value and importance of this are now painfully clear: despite having lost John, matplotlib continues to thrive thanks to the leadership of Michael Droetboom, the support of Perry Greenfield at the Hubble Telescope Science Institute, and the daily work of the rest of the team. I want to thank Perry and Michael for putting their resources and talent once more behind matplotlib, securing the future of the project. It is difficult to overstate the value and importance of matplotlib, and therefore of John's contributions (which do not end in matplotlib, by the way; but a biography will have to wait for another day...). Python has become a major force in the technical and scientific computing world, leading the open source offers and challenging expensive proprietary platforms with large teams and millions of dollars of resources behind them. But this would be impossible without a solid data visualization tool that would allow both ad-hoc data exploration and the production of complex, fine-tuned figures for papers, reports or websites. John had the vision to make matplotlib easy to use, but powerful and flexible enough to work in graphical user interfaces and as a server-side library, enabling a myriad use cases beyond his personal needs. This means that now, matplotlib powers everything from plots in dissertations and journal articles to custom data analysis projects and websites. And despite having left his academic career a few years ago for a job in industry, he remained engaged enough that as of today, he is still the top committer to matplotlib; this is the git shortlog of those with more than 1000 commits to the project: 2145 John Hunter 2130 Michael Droettboom 1060 Eric Firing All of this was done by a man who had three children to raise and who still always found the time to help those on the mailing lists, solve difficult technical problems in matplotlib, teach courses and seminars about scientific Python, and more recently help create the NumFOCUS foundation project. Despite the challenges that raising three children in an expensive city like Chicago presented, he never once wavered from his commitment to open source. But unfortunately now he is not here anymore to continue providing for their well-being, and I hope that all those who have so far benefited from his generosity, will thank this wonderful man who always gave far more than he received. Thanks to the rapid action of Travis Oliphant, the NumFOCUS foundation is now acting as an escrow agent to accept donations that will go into a fund to support the education and care of his wonderful girls Rahel, Ava and Clara. If you have benefited from John's many contributions, please say thanks in the way that would matter most to him, by helping Miriam continue the task of caring for and educating Rahel, Ava and Clara. You will find all the information necessary to make a donation here: http://numfocus.org/johnhunter Remember that even a small donation helps! If all those who ever use matplotlib give just a little bit, in the long run I am sure that we can make a difference. If you are a company that benefits in a serious way from matplotlib, remember that John was a staunch advocate of keeping all scientific Python projects under the BSD license so that commercial users could benefit from them without worry. Please say thanks to John in a way commensurate with your resources (and check how much a yearly matlab license would cost you in case you have any doubts about the value you are getting...). John's family is planning a private burial in Tennessee, but (most likely in September) there will also be a memorial service in Chicago that friends and members of the community can attend. We don't have the final scheduling details at this point, but I will post them once we know. I would like to again express my gratitude to Travis Oliphant for moving quickly with the setup of the donation support, and to Eric Jones (the founder of Enthought and another one of the central figures in our community) who immediately upon learning of John's plight contributed resources to support the family with everyday logistics while John was facing treatment as well as my travel to Chicago to assist. This kind of immediate urge to come to the help of others that Eric and Travis displayed is a hallmark of our community. Before closing, I want to take a moment to publicly thank the incredible staff of the University of Chicago medical center. The last two weeks were an intense and brutal ordeal for John and his loved ones, but the hospital staff offered a sometimes hard to believe, unending supply of generosity, care and humanity in addition to their technical competence. The latter is something we expect from a first-rate hospital at a top university, where the attending physicians can be world-renowned specialists in their field. But the former is often forgotten in a world often ruled by a combination of science and concerns about regulations and liability. Instead, we found generous and tireless staff who did everything in their power to ease the pain, always putting our well being ahead of any mindless adherence to protocol, patiently tending to every need we had and working far beyond their stated responsibilities to support us. To name only one person (and many others are equally deserving), I want to thank Dr. Carla Moreira, chief surgical resident, who spent the last few hours of John's life with us despite having just completed a solid night shift of surgical work. Instead of resting she came to the ICU and worked to ensure that those last hours were as comfortable as possible for John; her generous actions helped us through a very difficult moment. It is now time to close this already too long message... John, thanks for everything you gave all of us, and for the privilege of knowing you. Fernando. ps - I have sent this with my 'mailing lists' email. If you need to contact me directly for anything regarding the above, please write to my regular address at Fernando.Perez at berkeley.edu, where I do my best to reply more promptly. From fperez.net at gmail.com Wed Aug 29 22:32:23 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 29 Aug 2012 19:32:23 -0700 Subject: [SciPy-Dev] A sad day for our community. John Hunter: 1968-2012. Message-ID: Dear friends and colleagues, I am terribly saddened to report that yesterday, August 28 2012 at 10am, John D. Hunter died from complications arising from cancer treatment at the University of Chicago hospital, after a brief but intense battle with this terrible illness. John is survived by his wife Miriam, his three daughters Rahel, Ava and Clara, his sisters Layne and Mary, and his mother Sarah. Note: If you decide not to read any further (I know this is a long message), please go to this page for some important information about how you can thank John for everything he gave in a decade of generous contributions to the Python and scientific communities: http://numfocus.org/johnhunter. Just a few weeks ago, John delivered his keynote address at the SciPy 2012 conference in Austin centered around the evolution of matplotlib: http://www.youtube.com/watch?v=e3lTby5RI54 but tragically, shortly after his return home he was diagnosed with advanced colon cancer. This diagnosis was a terrible discovery to us all, but John took it with his usual combination of calm and resolve, and initiated treatment procedures. Unfortunately, the first round of chemotherapy treatments led to severe complications that sent him to the intensive care unit, and despite the best efforts of the University of Chicago medical center staff, he never fully recovered from these. Yesterday morning, he died peacefully at the hospital with his loved ones at his bedside. John fought with grace and courage, enduring every necessary procedure with a smile on his face and a kind word for all of his caretakers and becoming a loved patient of the many teams that ended up involved with his case. This was no surprise for those of us who knew him, but he clearly left a deep and lasting mark even amongst staff hardened by the rigors of oncology floors and intensive care units. I don't need to explain to this community the impact of John's work, but allow me to briefly recap, in case this is read by some who don't know the whole story. In 2002, John was a postdoc at the University of Chicago hospital working on the analysis of epilepsy seizure data in children. Frustrated with the state of the existing proprietary solutions for this class of problems, he started using Python for his work, back when the scientific Python ecosystem was much, much smaller than it is today and this could have been seen as a crazy risk. Furthermore, he found that there were many half-baked solutions for data visualization in Python at the time, but none that truly met his needs. Undeterred, he went on to create matplotlib (http://matplotlib.org) and thus overcome one of the key obstacles for Python to become the best solution for open source scientific and technical computing. Matplotlib is both an amazing technical achievement and a shining example of open source community building, as John not only created its backbone but also fostered the development of a very strong development team, ensuring that the talent of many others could also contribute to this project. The value and importance of this are now painfully clear: despite having lost John, matplotlib continues to thrive thanks to the leadership of Michael Droetboom, the support of Perry Greenfield at the Hubble Telescope Science Institute, and the daily work of the rest of the team. I want to thank Perry and Michael for putting their resources and talent once more behind matplotlib, securing the future of the project. It is difficult to overstate the value and importance of matplotlib, and therefore of John's contributions (which do not end in matplotlib, by the way; but a biography will have to wait for another day...). Python has become a major force in the technical and scientific computing world, leading the open source offers and challenging expensive proprietary platforms with large teams and millions of dollars of resources behind them. But this would be impossible without a solid data visualization tool that would allow both ad-hoc data exploration and the production of complex, fine-tuned figures for papers, reports or websites. John had the vision to make matplotlib easy to use, but powerful and flexible enough to work in graphical user interfaces and as a server-side library, enabling a myriad use cases beyond his personal needs. This means that now, matplotlib powers everything from plots in dissertations and journal articles to custom data analysis projects and websites. And despite having left his academic career a few years ago for a job in industry, he remained engaged enough that as of today, he is still the top committer to matplotlib; this is the git shortlog of those with more than 1000 commits to the project: 2145 John Hunter 2130 Michael Droettboom 1060 Eric Firing All of this was done by a man who had three children to raise and who still always found the time to help those on the mailing lists, solve difficult technical problems in matplotlib, teach courses and seminars about scientific Python, and more recently help create the NumFOCUS foundation project. Despite the challenges that raising three children in an expensive city like Chicago presented, he never once wavered from his commitment to open source. But unfortunately now he is not here anymore to continue providing for their well-being, and I hope that all those who have so far benefited from his generosity, will thank this wonderful man who always gave far more than he received. Thanks to the rapid action of Travis Oliphant, the NumFOCUS foundation is now acting as an escrow agent to accept donations that will go into a fund to support the education and care of his wonderful girls Rahel, Ava and Clara. If you have benefited from John's many contributions, please say thanks in the way that would matter most to him, by helping Miriam continue the task of caring for and educating Rahel, Ava and Clara. You will find all the information necessary to make a donation here: http://numfocus.org/johnhunter Remember that even a small donation helps! If all those who ever use matplotlib give just a little bit, in the long run I am sure that we can make a difference. If you are a company that benefits in a serious way from matplotlib, remember that John was a staunch advocate of keeping all scientific Python projects under the BSD license so that commercial users could benefit from them without worry. Please say thanks to John in a way commensurate with your resources (and check how much a yearly matlab license would cost you in case you have any doubts about the value you are getting...). John's family is planning a private burial in Tennessee, but (most likely in September) there will also be a memorial service in Chicago that friends and members of the community can attend. We don't have the final scheduling details at this point, but I will post them once we know. I would like to again express my gratitude to Travis Oliphant for moving quickly with the setup of the donation support, and to Eric Jones (the founder of Enthought and another one of the central figures in our community) who immediately upon learning of John's plight contributed resources to support the family with everyday logistics while John was facing treatment as well as my travel to Chicago to assist. This kind of immediate urge to come to the help of others that Eric and Travis displayed is a hallmark of our community. Before closing, I want to take a moment to publicly thank the incredible staff of the University of Chicago medical center. The last two weeks were an intense and brutal ordeal for John and his loved ones, but the hospital staff offered a sometimes hard to believe, unending supply of generosity, care and humanity in addition to their technical competence. The latter is something we expect from a first-rate hospital at a top university, where the attending physicians can be world-renowned specialists in their field. But the former is often forgotten in a world often ruled by a combination of science and concerns about regulations and liability. Instead, we found generous and tireless staff who did everything in their power to ease the pain, always putting our well being ahead of any mindless adherence to protocol, patiently tending to every need we had and working far beyond their stated responsibilities to support us. To name only one person (and many others are equally deserving), I want to thank Dr. Carla Moreira, chief surgical resident, who spent the last few hours of John's life with us despite having just completed a solid night shift of surgical work. Instead of resting she came to the ICU and worked to ensure that those last hours were as comfortable as possible for John; her generous actions helped us through a very difficult moment. It is now time to close this already too long message... John, thanks for everything you gave all of us, and for the privilege of knowing you. Fernando. ps - I have sent this with my 'mailing lists' email. If you need to contact me directly for anything regarding the above, please write to my regular address at Fernando.Perez at berkeley.edu, where I do my best to reply more promptly. From Nicolas.Rougier at inria.fr Fri Aug 31 04:09:45 2012 From: Nicolas.Rougier at inria.fr (Nicolas Rougier) Date: Fri, 31 Aug 2012 10:09:45 +0200 Subject: [SciPy-Dev] SciPy.org Website Move and Redesign In-Reply-To: References: <3C6CC713CBD949D2A51AB3C9859B493F@gmail.com> Message-ID: If that may help, here are some tentative images/logos: http://www.loria.fr/~rougier/tmp/scipy.png http://www.loria.fr/~rougier/tmp/scipy.svg Nicolas On Aug 29, 2012, at 20:58 , Pauli Virtanen wrote: > Kyle Mandli gmail.com> writes: >> I kind of dropped the ball on this as I have been traveling >> for the past month. I think we are ready to move >> forward on this and at least get the pieces in place. >> I am still not clear exactly what the current status of >> the scipy.org-new and scipy.github.com repos on github are. >> Can anyone speak to this? > > The status of scipy.org-new repository is that it is incomplete, but > future work should build on it, as it has some basic infrastructure > in place. (The conference/ directory in that repo can be ignored/removed, > as I believe it is outdated.) > > The scipy.github.com contains the HTML output built from scipy.org-new. > >> On a related topic, I have been searching out someone who may be >> able to do some redesign work on the site but >> was not successful (at least a free option). Any suggestions >> for someone with some design experience that >> could update the look of the site a bit please let us know. > > Well, the only requirement is that it should look better and more > organized than the current scipy.org page. That probably does not > require 1337 design chops, just some CSS/HTML skills :) > > Also, somehow the typography on scipy.github.com is off, the text > looks ugly and is difficult to read. > > The main point IMO is just to come up with some visual consistency > and navigation scheme between the main site, the documentation, etc. > This doesn't have to be perfect, the main thing is just to think up > some sort of a consistent framework. > > The second thing related to content would be to think what to > do with the different Scipys: > > - "Scipy the community site" > - "Scipy the library" > > Well, anyway, the above is just my suggestion on what could be done. > If you can think of some other ways to improve the situation, > please don't let this hold you up. > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From fperez.net at gmail.com Fri Aug 31 15:21:53 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 31 Aug 2012 12:21:53 -0700 Subject: [SciPy-Dev] SciPy.org Website Move and Redesign In-Reply-To: References: <3C6CC713CBD949D2A51AB3C9859B493F@gmail.com> Message-ID: On Fri, Aug 31, 2012 at 1:09 AM, Nicolas Rougier wrote: > If that may help, here are some tentative images/logos: > > http://www.loria.fr/~rougier/tmp/scipy.png > http://www.loria.fr/~rougier/tmp/scipy.svg FWIW, I like a lot the two central ones in the bottom row, thanks! From gael.varoquaux at normalesup.org Fri Aug 31 15:48:25 2012 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 31 Aug 2012 22:48:25 +0300 Subject: [SciPy-Dev] SciPy.org Website Move and Redesign In-Reply-To: References: <3C6CC713CBD949D2A51AB3C9859B493F@gmail.com> Message-ID: <20120831194825.GL24647@phare.normalesup.org> On Fri, Aug 31, 2012 at 12:21:53PM -0700, Fernando Perez wrote: > > http://www.loria.fr/~rougier/tmp/scipy.png > > http://www.loria.fr/~rougier/tmp/scipy.svg > FWIW, I like a lot the two central ones in the bottom row, thanks! My favorite one is the second one from the left on the bottom row. Thanks, Nicolas, you are our artist! Gael