Mailman 3 September 2010 - SciPy-Dev

[ANN] SciPy India 2009 Call for Presentations
by Jarrod Millman Sept. 21, 2010

Sept. 21, 2010

========================== SciPy 2010 Call for Papers ========================== The second `SciPy India Conference <http://scipy.in>`_ will be held from December 13th to 18th, 2010 at `IIIT-Hyderabad <http://www.iiit.ac.in/>`_. At this conference, novel applications and breakthroughs made in the pursuit of science using Python are presented. Attended by leading figures from both academia and industry, it is an excellent opportunity to experience the cutting edge of scientific software development. The conference is followed by two days of tutorials and a code sprint, during which community experts provide training on several scientific Python packages. We invite you to take part by submitting a talk abstract on the conference website at: http://scipy.in Talk/Paper Submission ========================== We solicit talks and accompanying papers (either formal academic or magazine-style articles) that discuss topics regarding scientific computing using Python, including applications, teaching, development and research. Papers are included in the peer-reviewed conference proceedings, published online. Please note that submissions primarily aimed at the promotion of a commercial product or service will not be considered. Important Dates ========================== Monday, Oct. 11: Abstracts Due Saturday, Oct. 30: Schedule announced Tuesday, Nov. 30: Proceedings paper submission due Monday-Tuesday, Dec. 13-14: Conference Wednesday-Friday, Dec. 15-17: Tutorials/Sprints Saturday, Dec. 18: Sprints Organizers ========================== * Jarrod Millman, Neuroscience Institute, UC Berkeley, USA (Conference Co-Chair) * Prabhu Ramachandran, Department of Aerospace Engineering, IIT Bombay, India (Conference Co-Chair) * FOSSEE Team

1 0

utility for composing sparse matrices
by Robert Cimrman Sept. 21, 2010

Sept. 21, 2010

FYI: I have created a function that creates a sparse matrix from sparse (or dense) blocks, somewhat in the spirit of np.r_ and friends, see the example below. Shall we add it to scipy.sparse? It may help to go around some of the fancy-indexing limitations. r. In [1]: from compose_sparse import compose_sparse In [2]: %doctest_mode *** Pasting of code with ">>>" or "..." has been enabled. Exception reporting mode: Plain Doctest mode is: ON >>> >>> import scipy.sparse as sps >>> >>> A = sps.csr_matrix([[1, 0], [0, 1]]) >>> >>> B = sps.coo_matrix([[1, 1]]) >>> >>> K = compose_sparse([[A, B.T], [B, 0]]) >>> >>> print K.todense() --> print(K.todense()) [[1 0 1] [0 1 1] [1 1 0]]

3 4

PATCH: enhancing fmin_bfgs to handle functions that are not defined everywhere
by Enrico Avventi Sept. 20, 2010

Sept. 20, 2010

hello, i would like to propose a patch for enhancing the optimization module. the svn diff output is attached. let me know what do you think about it. *Rationale:* Convergence theory for a large class of uncostrained optimization algorithms (descent methods) does not require the function to be defined everywhere. In fact you just need a function that is defined in an open convex set and whose sublevel set: {x: f(x) <= f(x0) } is compact where x0 is the starting point. It would be helpful to let the optimization routines to handle the most general case for which they converge. *Assumptions:* I assumed that the function tends to (plus) infinity as it approaches its domain boundary. This is reasonable in the sense that if not true the function either tends to minus infinity or can be extended to a larger set. The function is assumed to be infinite ouside its domain with derivative, if any, non defined (None). *Implementation:* The line search methods is the only block of the optimization routine(s) that needs to be changed significantly in order to handle such functions. In particular i modified the line search method (line_search_wolfe2) to call a new zoom algorith (_barrier_zoom) whenever one of the bracketing points leads to an unfeasible point. _barrier_zoom uses linear-logarithmic and quadratic-logarithmic interpolants instead of quadratic and cubic ones in order to generate new candidates steps. Note that the interpolation strategy may not be ideal and could be certainly improved. All descent algorithms can be easily adapted to use such a line search, here i started with fmin_bfgs. In order to adapt it i added a new exception (DomainError) and modified phi and derphi in line_search_wolfe1 to raise it when they are evaluated outside the domain. Whenever that happens fmin_bfgs catches the exception and calls line_search_wolfe2. Additionally line_search_wolfe2 will call the original _zoom method if the bracketing phase leads to finite-valued points. this ensures that for problems that are defined everywhere the old code-path is always taken. * Testing:* I added two functions for testing the scalar_search_wolfe2 phi1(x) = -100 x - log(1-x) and phi2(x) = -100 x + (1-x)^-k. All old and new tests pass. regards, Enrico

2 1

Error in scipy.ndimage documentation
by Matthieu Brucher Sept. 20, 2010

Sept. 20, 2010

Hi, The following function is referenced on the scipy.ndimage page (http://docs.scipy.org/doc/scipy/reference/tutorial/ndimage.html#ndimage-cca…) : static int _shift_function(int *output_coordinates, double* input_coordinates, int output_rank, int input_rank, void *callback_data) { int ii; /* get the shift from the callback data pointer: */ double shift = *(double*)callback_data; /* calculate the coordinates: */ for(ii = 0; ii < irank; ii++) icoor[ii] = ocoor[ii] - shift; /* return OK status: */ return 1; } It obviously cannot be compiled (irank -> input_rank, icoor -> input_coordinates, ocoor -> output_coordinates) Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher

2 2

dopri ODE integrator solout integration constraints
by Janick Martinez Esturo Sept. 17, 2010

Sept. 17, 2010

Hi, I need to be able to observe and possibly stop an ODE integration using the scipy.integrate.ode dopri5 and dopri853 integrators. However, the supporting call of the _solout method is completely disabled as the fortran iout parameter is set to zero inside the wrapper code. I therefore attached a patch that does not break the existing interface and enables the usage of a costum _solout method by overwriting the method in a derived class as follows: from scipy.integrate.ode import ode, dopri5, IntegratorBase class mydopri5(dopri5): name = 'mydopri5' def _solout(self, nr,xold,x,y,nd,icomp,con): print("Costum solout with variable access ", x, y) return(1) #Note: return -1 to break def reset(self,n,has_jac): super(mydopri5, self).reset(n, has_jac) self._iout = 1 self.call_args = [self.rtol,self.atol,self._solout,self._iout,self.work,self.iwork] if mydopri5.runner: IntegratorBase.integrator_classes.append(mydopri5) y0, t0 = [1.0, 2.0], 0 def f(t, y): return [y[0] + y[1], -y[1]**2] r = ode(f).set_integrator('mydopri5') r.set_initial_value(y0, t0) r.integrate(10) print r.t, r.y Here I derived from dopri5 overwrote the reset method to be called with iout=1 and implemented a simple _solout callback. I'm using this code in a productive environment and just wanted to know if there is a chance that the patch might get included in a future release of scipy or what would be necessary to to so? I'm not experienced with Fortran libs, but it might be interesting to make the Fortran CONTD5 function also avaible to be called from the _solout method in order to interpolate intermediate values correctly, but that would require a little bit more efford i guess. Any comments about this would be nice. Greets Janick

2 1

Scipy on Python 3
by Pauli Virtanen Sept. 16, 2010

Sept. 16, 2010

Hi, I flushed the Python 3 branch containing work from me and David to SVN trunk. Scipy now builds with Python 3, and all tests pass, except for scipy.weave which still needs to be ported. More testing is welcome. I suspect Scipy's test suite does not cover all of the code, so there might be some work left to do. You'll probably need the latest 1.5.x branch Numpy to build, due to some fixes in Numpy's distutils that are not in 1.5.0. Pauli

8 16

Re: [SciPy-Dev] Scipy.org down, again
by Jonathan Stickel Sept. 15, 2010

Sept. 15, 2010

I notice this happens a lot, too. Interestingly, and fortunately for me, the docs seems to be much less affected: http://docs.scipy.org/ So I at least can reach the documentation. Jonathan On 9/15/10 11:00 , scipy-dev-request(a)scipy.org wrote: > Date: Tue, 14 Sep 2010 16:40:31 -0700 > From: Fernando Perez<fperez.net(a)gmail.com> > Subject: [SciPy-Dev] Scipy.org down, again > To: SciPy Developers List<scipy-dev(a)scipy.net>

1 0

Scipy.org down, again
by Fernando Perez Sept. 14, 2010

Sept. 14, 2010

f

1 0

spatial.test() failure
by Nils Wagner Sept. 13, 2010

Sept. 13, 2010

>>> from scipy import spatial >>> spatial.test() Running unit tests for scipy.spatial NumPy version 2.0.0.dev8714 NumPy is installed in /home/nwagner/local/lib64/python2.6/site-packages/numpy SciPy version 0.9.0.dev6803 SciPy is installed in /home/nwagner/local/lib64/python2.6/site-packages/scipy Python version 2.6.5 (r265:79063, Jul 5 2010, 11:46:13) [GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] nose version 0.11.2 ............................................................................................................................F.................................................................................................................................................. ====================================================================== FAIL: Tests pdist(X, 'minkowski') on iris data. (float32) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.6/site-packages/scipy/spatial/tests/test_distance.py", line 837, in test_pdist_minkowski_3_2_iris_float32 self.failUnless(within_tol(Y_test1, Y_right, eps)) AssertionError ---------------------------------------------------------------------- Ran 271 tests in 38.005s FAILED (failures=1) <nose.result.TextTestResult run=271 errors=0 failures=1>

2 1

problem building scipy with qhull
by Martin Hofsäß Sept. 9, 2010

Sept. 9, 2010

Hi all together, I had the newest scipy version 0.9 from the svn trunk and I get one error by building scipy under windows with the intel mkl and the MSVC & IFORT compiler. Who can me help? Executing scons command (pkg is scipy.spatial): C:\Python26\python.exe "C:\Python26\lib\site-packages\numscons\scons-local\scons.py" -f scipy\spatial\SConstruct -I. scons_tool_path="" src_dir="scipy\spatial" pkg_path="scipy\spatial" pkg_name="scipy.spatial" log_level=0 distutils_libdir="..\..\..\..\build\lib.win32-2.6" distutils_clibdir="..\..\..\..\build\temp.win32-2.6" distutils_install_prefix="C:\Python26\Lib\site-packages\scipy\spatial" cc_opt=msvc cc_opt=msvc debug=0 f77_opt=ifort cxx_opt=msvc include_bootstrap=C:\Python26\lib\site-packages\numpy\core\include bypass=1 import_env=0 silent=0 bootstrapping=0 scons: Reading SConscript files ... Mkdir("build\scons\scipy\spatial") C:\Programme\Intel\Compiler\11.0\074\fortran\bin\ifortvars.bat scons: done reading SConscript files. scons: Building targets ... cl /Fobuild\scons\scipy\spatial\ckdtree.obj /c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo /IC:\Python26\lib\site-packages\numpy\core\include /IC:\Python26\include build\scons\scipy\spatial\ckdtree.c ckdtree.c link /nologo /dll /OUT:build\scons\scipy\spatial\ckdtree.pyd /LIBPATH:C:\Python26\libs build\scons\scipy\spatial\ckdtree.obj Bibliothek "build\scons\scipy\spatial\ckdtree.lib" und Objekt "build\scons\scipy\spatial\ckdtree.exp" werden erstellt. Install file: "build\scons\scipy\spatial\ckdtree.pyd" as "build\lib.win32-2.6\scipy\spatial\ckdtree.pyd" cl /Fobuild\scons\scipy\spatial\qhull.obj /c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo /IC:\Python26\lib\site-packages\numpy\core\include /IC:\Python26\include build\scons\scipy\spatial\qhull.c qhull.c build\scons\scipy\spatial\qhull.c(1143) : warning C4133: '=': Inkompatible Typen - von 'PyObject *' zu 'PyArrayObject *' build\scons\scipy\spatial\qhull.c(1768) : warning C4018: '>=': Konflikt zwischen 'signed' und 'unsigned' build\scons\scipy\spatial\qhull.c(2057) : warning C4018: '>=': Konflikt zwischen 'signed' und 'unsigned' build\scons\scipy\spatial\qhull.c(2777) : warning C4013: 'dgesv_' undefiniert; Annahme: extern mit Rckgabetyp int cl /Fobuild\scons\scipy\spatial\qhull\src\geom.obj /c build\scons\scipy\spatial\qhull\src\geom.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo geom.c cl /Fobuild\scons\scipy\spatial\qhull\src\geom2.obj /c build\scons\scipy\spatial\qhull\src\geom2.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo geom2.c cl /Fobuild\scons\scipy\spatial\qhull\src\global.obj /c build\scons\scipy\spatial\qhull\src\global.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo global.c cl /Fobuild\scons\scipy\spatial\qhull\src\io.obj /c build\scons\scipy\spatial\qhull\src\io.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo io.c cl /Fobuild\scons\scipy\spatial\qhull\src\mem.obj /c build\scons\scipy\spatial\qhull\src\mem.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo mem.c cl /Fobuild\scons\scipy\spatial\qhull\src\merge.obj /c build\scons\scipy\spatial\qhull\src\merge.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo merge.c cl /Fobuild\scons\scipy\spatial\qhull\src\poly.obj /c build\scons\scipy\spatial\qhull\src\poly.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo poly.c cl /Fobuild\scons\scipy\spatial\qhull\src\poly2.obj /c build\scons\scipy\spatial\qhull\src\poly2.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo poly2.c cl /Fobuild\scons\scipy\spatial\qhull\src\qset.obj /c build\scons\scipy\spatial\qhull\src\qset.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo qset.c cl /Fobuild\scons\scipy\spatial\qhull\src\user.obj /c build\scons\scipy\spatial\qhull\src\user.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo user.c cl /Fobuild\scons\scipy\spatial\qhull\src\stat.obj /c build\scons\scipy\spatial\qhull\src\stat.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo stat.c cl /Fobuild\scons\scipy\spatial\qhull\src\qhull.obj /c build\scons\scipy\spatial\qhull\src\qhull.c /MD /nologo /GS- /D_CRT_SECURE_NO_WARNINGS /openmp /Ox /DNDEBUG /W3 /nologo qhull.c lib /nologo /OUT:build\scons\scipy\spatial\qhullsrc.lib build\scons\scipy\spatial\qhull\src\geom.obj build\scons\scipy\spatial\qhull\src\geom2.obj build\scons\scipy\spatial\qhull\src\global.obj build\scons\scipy\spatial\qhull\src\io.obj build\scons\scipy\spatial\qhull\src\mem.obj build\scons\scipy\spatial\qhull\src\merge.obj build\scons\scipy\spatial\qhull\src\poly.obj build\scons\scipy\spatial\qhull\src\poly2.obj build\scons\scipy\spatial\qhull\src\qset.obj build\scons\scipy\spatial\qhull\src\user.obj build\scons\scipy\spatial\qhull\src\stat.obj build\scons\scipy\spatial\qhull\src\qhull.obj Install file: "build\scons\scipy\spatial\qhullsrc.lib" as "build\temp.win32-2.6\qhullsrc.lib" link /nologo /dll /OUT:build\scons\scipy\spatial\qhull.pyd /LIBPATH:C:\Python26\libs build\scons\scipy\spatial\qhullsrc.lib build\temp.win32-2.6\qhullsrc.lib build\scons\scipy\spatial\qhull.obj Bibliothek "build\scons\scipy\spatial\qhull.lib" und Objekt "build\scons\scipy\spatial\qhull.exp" werden erstellt. qhull.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_dgesv_" in Funktion "___pyx_pf_5scipy_7spatial_5qhull__get_barycentric_transforms". build\scons\scipy\spatial\qhull.pyd : fatal error LNK1120: 1 nicht aufgelöste externe Verweise. scons: building terminated because of errors.

2 1