Mailman 3 December 2014 - SciPy-User

How to display a RGB image (MFISH)?
by jp 02 Apr '23

02 Apr '23

Hi, I have written a script to try to combine five images into a three channels RGB images<http://dip4fish.blogspot.com/2011/05/trying-to-combine-mfish-images-into-rg…> . The resulting RGB image looks like a grey scale image instead of a color one. I have three np.array Rnorm, Gnorm, Bnorm which are copied into a rgb array: *rgb = np.zeros((shape[0],shape[1],3),dtype=float) mxr=np.max(R) mxg=np.max(G) mxb=np.max(B) Rnorm=np.uint8((255*(R/mxr)))Gnorm=np.uint8((255*(R/mxg)))Bnorm=np.uint8((255*(R/mxb)))#copy each RGB component in an RGB array rgb[:,:,0]=Rnorm rgb[:,:,1]=Gnorm rgb[:,:,2]=Bnorm* *pylab.subplot(224, aspect='equal',frameon=False, xticks=[], yticks=[]) pylab.imshow(rgb) pylab.show()* Any advice? Thank you Jean-Patrick

3 4

Invitation to connect on LinkedIn
by Jelle Feringa via LinkedIn 28 Jul '22

28 Jul '22

LinkedIn ------------ Jelle Feringa requested to add you as a connection on LinkedIn: ------------------------------------------ Jose, I'd like to add you to my professional network on LinkedIn. - Jelle Accept invitation from Jelle Feringa http://www.linkedin.com/e/-3wy1w2-gpkzwpgn-5n/Q6WKH0LACopGJkAw_6fSqajo6R7VM… View invitation from Jelle Feringa http://www.linkedin.com/e/-3wy1w2-gpkzwpgn-5n/Q6WKH0LACopGJkAw_6fSqajo6R7VM… ------------------------------------------ DID YOU KNOW your LinkedIn profile helps you control your public image when people search for you? Setting your profile as public means your LinkedIn profile will come up when people enter your name in leading search engines. Take control of your image! http://www.linkedin.com/e/-3wy1w2-gpkzwpgn-5n/ewp/inv-22/ -- (c) 2011, LinkedIn Corporation

2 1

Help required regding Eigenvectors
by Sudheer Phani 14 Mar '22

14 Mar '22

Hello All, I have been encountering some strange problems with the calculation of eigen vectors using python. The problem is with the sign of the eigen vectors calculated. On Very few occasions the eigen vectors calculated using python have an opposite sign than the actual eigenvectors, though the magnitude is correct. Can any one of you plz help me in this regard and suggest me some solution if you have encoutered similar problems . Any help in this regd is appreciated Thanks in Advace regds Sudheer

5 5

Normalization for optimization in python
by Yuxiang Wang 27 Apr '15

27 Apr '15

Dear all, During optimization, it is often helpful to normalize the input parameters to make them on the same order of magnitude, so the convergence can be much better. For example, if we want to minimize f(x), while a reasonable approximation is x0=[1e3, 1e-4], it might be helpful to normalize x0[0] and x0[1] to about the same order of magnitude (often O(1)). My question is, I have been using scipy.optimize and specifically, the L-BFGS-B algorithm. I was wondering that, do I need to normalize that manually by writing a function, or the algorithm already did it for me? Thank you! -Shawn -- Yuxiang "Shawn" Wang Gerling Research Lab University of Virginia yw5aj(a)virginia.edu +1 (434) 284-0836 https://sites.google.com/a/virginia.edu/yw5aj/

4 8

Novice scipy user: having some efficiency issues with using scipy.integrate.odeint for my research project, and not sure how to proceed...
by Brian Merchant 13 Jan '15

13 Jan '15

Just to give you a bit regarding my background: I am a math undergraduate working on biology modelling problems. I have a strong background in Python, but it is only over the last few months that I have begun to dabble in scientific computation using scipy, numpy and most recently, Cython. This semester, I am taking my first proper course on numerical methods. Currently, in my research work, I am writing a program that solves a large number of non-linear ODEs. I use `scipy.integrate.odeint` as my workhorse, although I have dabbled with using `pyDSTool` as well, but found that the limited capacity I had in understanding advanced methods didn't allow me to use `pyDSTool` so that I had better performance than vanilla `scipy.integrate.odeint`. My supervisor recently pointed out a fairly major error in my previous implementation of the program: I was "breaking up" `scipy.integrate.odeint`'s flow. So if I had to solve a problem between times 0 and 10, I would make `odeint` work between `t in [0, 1]`, take the result at `t=1`, use it to update (non-linear) parameters for the next interval (`[1, 2]`) and then finally run the next interval using `t=1` results as the initial conditions. I thought it would be a good idea to do this in order to temporarily reduce the complexity of the problem by having some of the coefficients be constant over each sub-interval (something like a "quasi-equilibrium" condition?), and it also allowed me to straightforwardly implement non-DE rules to update parameters, if I needed to. However, problems with doing this include introducing errors, and causing loss of speed due to the breaking/restarting of `odeint`'s internals. So, I changed the implementation so that everything was done in "one-shot" (luckily the only non-DE rule I had so far was easily converted to a DE rule, although there is one coming up which I don't see any easy conversion for...[that is the subject of this question]( http://scicomp.stackexchange.com/questions/14765/scipy-integrate-odeint-how…) ). However, I am finding that the "one-shot" method is *slower* than the "broken up" method! For a single cell (the number of ODEs increases linearly with increasing number of cells), solving for the interval between `[0, 1]` takes about 3 times longer than the "broken up method" (where I was breaking up the problem into intervals `[0, 0.5]` and `[0.5, 1]` for the same `rtol` and `atol`. Solving for the behaviour of a single cell over `[0, 10]` takes roughly 3 times longer than `[0, 1]` (hey! not bad!). Solving between `[0, 1000]` takes roughly 1500 times longer (weird :( ). Solving 2 cells (and solving between `[0,1]`) takes about 3 times longer than the single cell case, and solving 10 cells over the same time interval takes 60 times longer! So the times aren't growing linearly...whether I am increasing the length of the time interval, or increasing the number of cells. Alright, part of the problem can be explained by the fact that even though the number of ODEs grows linearly with the number of cells, the work done to calculate the Jacobian doesn't grow quite grow linearly -- still, in all cases, the "one shot" method is significantly slower than the "broken up" method (and the greater than linear effort required in calculating the Jacobian also affected the "broken up" method). Also, the Jacobian doesn't become harder to calculate when increasing the time interval...so shouldn't the time taken to solve the ODE grow linearly there at least? Alright, that's about all the certain information I have. My guess as to the number one culprit is that in the "one shot" method, the function used to calculate the Jacobian is doing a *lot* more work: recall, non-linear ODEs, so some internal iteration is required, and basically every iteration, all the coefficients are calculated again, while in the "broken up" method, I could choose which ones were held constant for a small time period, before recalculation. I thought reimplementing by making significant use of Cython (I used "annotation profiling" (`cython -a my_file.pyx`) to make sure I am cutting down on C lines wherever possible...so I am pretty sure I have not done a horribly ugly Python to C conversion. Still, even Cythonizing doesn't help with the fact that a lot more work is being done. I'm at a bit of a loss right now as to how to proceed - what questions should I begin asking myself in order to get a handle on things?

2 2

ANN: Scipy 0.14.1 release
by Pauli Virtanen 30 Dec '14

30 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We are pleased to announce the Scipy 0.14.1 release. The 0.14.1 release is a bugfix-only release, addressing the following issues: - - gh-3630 NetCDF reading results in a segfault - - gh-3631 SuperLU object not working as expected for complex matrices - - gh-3733 Segfault from map_coordinates - - gh-3780 Segfault when using CSR/CSC matrix and uint32/uint64 - - gh-3781 Fix omitted types in sparsetools typemaps - - gh-3802 0.14.0 API breakage: _gen generators are missing from scipy.stats.distributions API - - gh-3805 Ndimge test failures with numpy 1.10 - - gh-3812 == sometimes wrong on csr_matrix - - gh-3853 Many scipy.sparse test errors/failures with numpy 1.9.0b2 - - gh-4084 Fix exception declarations for Cython 0.21.1 compatibility - - gh-4093 Avoid a memory error in splev(x, tck, der=k) - - gh-4104 Workaround SGEMV segfault in Accelerate (maintenance 0.14.x) - - gh-4143 Fix ndimage functions for large data - - gh-4149 Bug in expm for integer arrays - - gh-4154 Ensure that the 'size' argument of PIL's 'resize' method is a tuple - - gh-4163 ZeroDivisionError in scipy.sparse.linalg.lsqr - - gh-4164 Remove use of deprecated numpy API in lib/lapack/ f2py wrapper - - gh-4180 PIL resize support tuple fix - - gh-4168 Address arpack test failures on windows 32 bits with numpy 1.9.1 - - gh-4203 Sparse matrix multiplication in 0.14.x slower compared to 0.13.x - - gh-4218 Make ndimage interpolation compatible with numpy relaxed strides - - gh-4225 Off-by-one error in PPoly shape checks - - gh-4248 Fix issue with incorrect use of closure for slsqp Source tarballs and binaries are available at https://sourceforge.net/projects/scipy/files/SciPy/0.14.1/ Best regards, Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlSjCcYACgkQ6BQxb7O0pWBxcwCfcnd4uva5hzMHQlHmWxlfbja3 T0AAn2QQmhcotDRB2c2p41Xzjb4MJ13f =yBxH -----END PGP SIGNATURE-----

1 0

Re: [SciPy-User] SciPy-User Digest, Vol 136, Issue 2
by Denis Akhiyarov 30 Dec '14

30 Dec '14

You can get numpy linked with MKL here: http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy On Dec 3, 2014 12:00 PM, <scipy-user-request(a)scipy.org> wrote: > Send SciPy-User mailing list submissions to > scipy-user(a)scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/scipy-user > or, via email, send a message with subject or body 'help' to > scipy-user-request(a)scipy.org > > You can reach the person managing the list at > scipy-user-owner(a)scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-User digest..." > > > Today's Topics: > > 1. Re: NumPy/SciPy compilation VC10/Intel Fortran/MKL > (David Cournapeau) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 Dec 2014 15:58:07 +0000 > From: David Cournapeau <cournape(a)gmail.com> > Subject: Re: [SciPy-User] NumPy/SciPy compilation VC10/Intel > Fortran/MKL > To: SciPy Users List <scipy-user(a)scipy.org> > Message-ID: > <CAGY4rcVXxcUqP9CegqXSBBnLN8-i= > 1i-XoHyEpXysPfmE3zOcQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Wed, Dec 3, 2014 at 2:15 PM, Relja Ljubobratovic < > relja.ljubobratovic(a)3lateral.com> wrote: > > > Hello, > > > > I need to compile NumPy and SciPy in Windows 7 x64, with Microsoft Visual > > Compiler 2010, and Intel Fortran compiler 2015, using Intel MKL. I'm > > compiling against Python 2.7.6 x64, which is compiled using same C/C++ > > compiler (I've downloaded compiled version from > > http://p-nand-q.com/python/building-python-27-with-vs2010.html). I need > > these packages for Autodesk Maya 2014, which has integrated Python 2.7.3 > > x64, compiled with VC10. > > > > Here is my NumPy site.cfg: > > [DEFAULT] > > library_dirs = C:\Program Files (x86)\Microsoft Visual Studio > > 10.0\VC\lib\amd64 > > include_dirs = C:\Program Files (x86)\Microsoft Visual Studio > > 10.0\VC\include > > > > [mkl] > > library_dirs = C:\Program Files (x86)\Intel\Composer XE > > 2015\mkl\lib\intel64 > > include_dirs = C:\Program Files (x86)\Intel\Composer XE 2015\mkl\include > > mkl_libs = mkl_rt,mkl_intel_lp64,mkl_intel_thread,mkl_core > > lapack_libs = mkl_lapack95_lp64 > > blas_libs = mkl_blas95_lp64 > > > > ---------------------------------------------- > > > > NumPy compilation shows strange linking errors and failures on > > _configtests - linking errors are evident in the numpy build log that > I've > > provided. It seems that linker has no access to stdc++ libs? (unresolved > > external symbol strtoull, strtoll etc.) But at the end it compiles fine, > > and the installation and nose tests pass with no errors. I cannot > > understand if so much testing failures could be normal during the > > compilation? > > > > Those are configuration tests. You should ignore those > > > > > > But during the SciPy compilation fatal linking errors occur while linking > > compiled .lib files to .pyd. I'm not completely sure to which package > these > > unresolved externals belong ? I've tried examining libs for externals > that > > are not found, but I'm failing to figure this out. I'm not so familiar > with > > MKL, and I can't figure out if I'm missing some linking in NumPy > site.cfg? > > Linking error is at the end of the scipy build log. > > > > The first thing I would look at is ensureing all the .lib/.obj linked > together in the failed linking step are at the same architecture. It seems > that you are using the correct ifort and cl compilers, but you never know. > > THe missing symbols are supposed to be in the fftpack.lib being linked, so > I would check the symbols in fftpack.lib as well. > > David > > > > > > I'm using msvccompiler.py configuration from the downloaded Python's > > distutils. I have inspected it, and it seems ok to me - could the reason > > for numpy linking errors come from here? And visual fortran configuration > > is present in numpy's distutils. Command I'm using for setup.py is: > > python setup.py config --compiler=msvc --fcompiler=intelvem > > build_clib --compiler=msvc --fcompiler=intelvem build_ext --compiler=msvc > > --fcompiler=intelvem install > > > > > > I'm trying to compile numpy-1.9.1 with scipy-0.14.0, but I've also tried > > with few older versions of both, and had the same outcome. I've also > tried > > with git master versions, but again the same errors occur. > > > > Complete build logs are added as attachments. I'd be grateful if anyone > > can point out the solution to the errors I'm having. > > > > Thanks, > > Relja Ljubobratovic > > > > > > > > _______________________________________________ > > SciPy-User mailing list > > SciPy-User(a)scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-user > > > > >

1 0

Re: [SciPy-User] [SciPy-Dev] ANN: Scipy 0.14.1 release candidate 1
by David Cournapeau 19 Dec '14

19 Dec '14

I built that rc on top of numpy 1.8.1 and MKL, and it worked on every platform we support @ Enthought. I saw a few test failures on linux and windows 64 bits, but those were there before or are precisions issues. I also tested when run on top of numpy 1.9.1 (but still built against 1.8.1), w/ similar results. Thanks for all the hard work, David On Sun, Dec 14, 2014 at 10:29 PM, Pauli Virtanen <pav(a)iki.fi> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > We have finished preparing the Scipy 0.14.1 release candidate 1. > If no regressions turn up, the final release is planned within the > following weeks. > > The 0.14.1 release will be a bugfix-only release, addressing the > following issues: > > - - gh-3630 NetCDF reading results in a segfault > - - gh-3631 SuperLU object not working as expected for complex matrices > - - gh-3733 Segfault from map_coordinates > - - gh-3780 Segfault when using CSR/CSC matrix and uint32/uint64 > - - gh-3781 Fix omitted types in sparsetools typemaps > - - gh-3802 0.14.0 API breakage: _gen generators are missing from > scipy.stats.distributions API > - - gh-3805 ndimge test failures with numpy 1.10 > - - gh-3812 == sometimes wrong on csr_matrix > - - gh-3853 Many scipy.sparse test errors/failures with numpy 1.9.0b2 > - - gh-4084 Fix exception declarations for Cython 0.21.1 compatibility > - - gh-4093 Avoid a memory error in splev(x, tck, der=k) > - - gh-4104 Workaround SGEMV segfault in Accelerate (maintenance 0.14.x) > - - gh-4143 Fix ndimage functions for large data > - - gh-4149 Bug in expm for integer arrays > - - gh-4154 Ensure that the 'size' argument of PIL's 'resize' method is > a tuple > - - gh-4163 ZeroDivisionError in scipy.sparse.linalg.lsqr > - - gh-4164 Remove use of deprecated numpy API in lib/lapack/ f2py wrapper > - - gh-4180 pil resize support tuple fix > - - gh-4168 Address arpack test failures on windows 32 bits with numpy > 1.9.1 > - - gh-4218 make ndimage interpolation compatible with numpy relaxed > strides > - - gh-4225 off-by-one error in PPoly shape checks > - - gh-4248 fix issue with incorrect use of closure for slsqp > > Source tarballs and binaries are available at > https://sourceforge.net/projects/scipy/files/scipy/0.14.1rc1/ > > Best regards, > Pauli Virtanen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlSOD0YACgkQ6BQxb7O0pWDO5ACfccLqMvZWfkHqSzDCkMSoRKAU > n7cAni6XhWJRy7oJ757rlGeIi0e34HTn > =9bB/ > -----END PGP SIGNATURE----- > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev(a)scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev >

1 0

Re: [SciPy-User] [SciPy-Dev] ANN: Scipy 0.15.0 release candidate 1
by Matthew Brett 17 Dec '14

17 Dec '14

Hi, On Mon, Dec 15, 2014 at 2:47 PM, Pauli Virtanen <pav(a)iki.fi> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > Scipy 0.15.0 release candidate 1 is now available. If no surprises > turn up, the final release is planned within two weeks. > > Source tarballs, full release notes etc. are available at > https://sourceforge.net/projects/scipy/files/scipy/0.15.0rc1/ OSX wheels at http://wheels.scipy.org/ (via https://travis-ci.org/MacPython/scipy-wheels). Scipy-stack tests running at https://travis-ci.org/MacPython/scipy-stack-osx-testing Cheers, Matthew

1 0

[ANN] Summer School "Advanced Scientific Programming in Python" in Munich, Germany
by Tiziano Zito 17 Dec '14

17 Dec '14

Advanced Scientific Programming in Python ========================================= a Summer School by the G-Node, the Bernstein Center for Computational Neuroscience Munich and the Graduate School of Systemic Neurosciences Scientists spend more and more time writing, maintaining, and debugging software. While techniques for doing this efficiently have evolved, only few scientists have been trained to use them. As a result, instead of doing their research, they spend far too much time writing deficient code and reinventing the wheel. In this course we will present a selection of advanced programming techniques, incorporating theoretical lectures and practical exercises tailored to the needs of a programming scientist. New skills will be tested in a real programming project: we will team up to develop an entertaining scientific computer game. We use the Python programming language for the entire course. Python works as a simple programming language for beginners, but more importantly, it also works great in scientific simulations and data analysis. We show how clean language design, ease of extensibility, and the great wealth of open source libraries for scientific computing and data visualization are driving Python to become a standard tool for the programming scientist. This school is targeted at Master or PhD students and Post-docs from all areas of science. Competence in Python or in another language such as Java, C/C++, MATLAB, or Mathematica is absolutely required. Basic knowledge of Python is assumed. Participants without any prior experience with Python should work through the proposed introductory materials before the course. Date and Location ================= August 31—September 5, 2015. Munich, Germany. Preliminary Program =================== Day 0 (Mon Aug 31) — Best Programming Practices • Best Practices for Scientific Computing • Version control with git and how to contribute to Open Source with github • Object-oriented programming & design patterns Day 1 (Tue Sept 1) — Software Carpentry • Test-driven development, unit testing & quality assurance • Debugging, profiling and benchmarking techniques • Advanced Python: generators, decorators, and context managers Day 2 (Wed Sept 2) — Scientific Tools for Python • Advanced NumPy • The Quest for Speed (intro): Interfacing to C with Cython • Contributing to Open Source Software/Programming in teams Day 3 (Thu Sept 3) — The Quest for Speed • Writing parallel applications in Python • Python 3: why should I care • Programming project Day 4 (Fri Sept 4) — Efficient Memory Management • When parallelization does not help: the starving CPUs problem • Programming project Day 5 (Sat Sept 5) — Practical Software Development • Programming project • The Pelita Tournament Every evening we will have the tutors' consultation hour: Tutors will answer your questions and give suggestions for your own projects. Applications ============ You can apply on-line at https://python.g-node.org Applications must be submitted before 23:59 UTC, March 31, 2015. Notifications of acceptance will be sent by May 1, 2015. No fee is charged but participants should take care of travel, living, and accommodation expenses. Candidates will be selected on the basis of their profile. Places are limited: acceptance rate is usually around 20%. Prerequisites: You are supposed to know the basics of Python to participate in the lectures Preliminary Faculty =================== • Francesc Alted, freelance developer, author of PyTables, Spain • Pietro Berkes, Enthought Inc., UK • Kathryn D. Huff, Department of Nuclear Engineering, University of California - Berkeley, USA • Zbigniew Jędrzejewski-Szmek, Krasnow Institute, George Mason University, USA • Eilif Muller, Blue Brain Project, École Polytechnique Fédérale de Lausanne, Switzerland • Rike-Benjamin Schuppner, Institute for Theoretical Biology, Humboldt-Universität zu Berlin, Germany • Nelle Varoquaux, Centre for Computational Biology Mines ParisTech, Institut Curie, U900 INSERM, Paris, France • Stéfan van der Walt, Applied Mathematics, Stellenbosch University, South Africa • Niko Wilbert, TNG Technology Consulting GmbH, Germany • Tiziano Zito, Forschungszentrum Jülich GmbH, Germany Organized by Tiziano Zito (head) and Zbigniew Jędrzejewski-Szmek for the German Neuroinformatics Node of the INCF Germany, Christopher Roppelt for the German Center for Vertigo and Balance Disorders (DSGZ) and the Graduate School of Systemic Neurosciences (GSN) of the Ludwig-Maximilians-Universität Munich Germany, Christoph Hartmann for the Frankfurt Institute for Advanced Studies (FIAS) and International Max Planck Research School (IMPRS) for Neural Circuits, Frankfurt Germany, and Jakob Jordan for the Institute of Neuroscience and Medicine (INM-6) and Institute for Advanced Simulation (IAS-6), Jülich Research Centre and JARA. Additional funding provided by the Bernstein Center for Computational Neuroscience (BCCN) Munich. Website: https://python.g-node.org Contact: python-info(a)g-node.org

1 0