Mailman 3 May 2012 - SciPy-User

ANN: IEP 3.0 - the Interactive Editor for Python
by Almar Klein 15 May '12

15 May '12

Dear all, We're pleased to announce version 3.0 of the Interactive Editor for Python. IEP is a cross-platform Python IDE focused on interactivity and introspection, which makes it very suitable for scientific computing. Its practical design is aimed at simplicity and efficiency. IEP is written in Python 3 and Qt. Binaries are available for Windows, Linux, and Mac. Website: http://code.google.com/p/iep/ Discussion group: http://groups.google.com/group/iep_ Release notes: http://code.google.com/p/iep/wiki/Release#version_3.0_(14-05-2012) Regards, Rob, Ludo & Almar

1 0

2D phase unwrapping
by Gregor Thalhammer 15 May '12

15 May '12

Hi all, I have beend searching for an implementation for phase unwrapping in 2D (and possibly also 3D). I found this old thread in the numpy mailing list http://mail.scipy.org/pipermail/numpy-discussion/2008-November/038873.html which mentions the C implementation from GERI: http://www.ljmu.ac.uk/GERI/90202.htm While searching I found remarks by the authors that these algorithms have been incorporated into scipy, however I am unable to find them in current scipy or numpy. Am I missing something obvious? Instead I found this wrapper: https://github.com/pointtonull/pyunwrap This seems to be based on a wrapper already mentioned in the above mentioned discussion, but the links mentioned there are dead. I added some setup.py, and with some small modifications I managed to compile the extension both on OS X and Windows. I would like to see these algorithms included in scipy, and I am willing to work on this. So now my questions: In the old numpy-discussion thread licensing issues are raised, can anybody tell more? On the GERI homepage they distribute their code under a non-commercial-use license, but the authors seem to agree on incorporating their code into scipy. Except from this, what else would be required? Thanks for any advice Gregor

5 7

Trajectory Integration via scipy.integrate or PyDSTool?
by Sara Gallian 15 May '12

15 May '12

Hi all, I'm trying to integrate particle trajectories in a finite domain, and I need to make them "reflect" at the boundaries (i.e. reverse the velocity perpendicular to the plane they collided with). I started by using scipy.integrate.odeint , but since the integration steps are variable, simply checking the position and reversing the velocity won't work! Can anyone suggest the quickest way to obtain this? would Vode be able to handle this, or should I try to learn to use PyDSTool? I'm running pretty late on a deadline, so any suggestion is more than appreciated :) Thanks! Sara

3 8

Simple ndarray dim question?
by Erik Kastman 14 May '12

14 May '12

Hi all, Using SciPy and Matlab, I'm having trouble reconstructing an array to match what is given from a matlab cell array loaded using scipy.io.loadmat(). For example, say I create a cell containing a pair of double arrays in matlab and then load it using scipy.io (I'm using SPM to do imaging analyses in conjunction with pynifti and the like) Matlab >> onsets{1} = [0 30 60 90] >> onsets{2} = [15 45 75 105] Python >>> import scipy.io as scio >>> mat = scio.loadmat('onsets.mat') >>> mat['onsets'][0] array([[[ 0 30 60 90]], [[ 15 45 75 105]]], dtype=object) >>> mat['onsets'][0].shape (2,) My question is this: **Why does this numpy array have the shape (2,) instead of (2,1,4)**? In real life I'm trying to use Python to parse a logfile and build these onsets cell arrays, so I'd like to be able to build them from scratch. When I try to build the same array from the printed output, I get a different shape back: >>> new_onsets = array([[[ 0, 30, 60, 90]], [[ 15, 45, 75, 105]]], dtype=object) array([[[0, 30, 60, 90]], [[15, 45, 75, 105]]], dtype=object) >>> new_onsets.shape (2,1,4) Unfortunately, the shape (vectors of doubles in a cell array) is coded in a spec upstream, so I need to be able to get this saved exactly in this format. Of course, it's not a big deal since I could just write the parser in matlab, but it would be nice to figure out what's going on and add a little to my [minuscule] knowledge of numpy. Thanks in advance for any suggestions, Erik cross-posted to stack-overflow: http://stackoverflow.com/questions/10542263

3 2

Re: [SciPy-User] How to assemble large sparse matrices
by Dave Wells 13 May '12

13 May '12

cm, The trick is to use the IJV storage format. This is a trio of three arrays where the first one contains row indicies, the second has column indicies, and the third has the values of the matrix at that location. This is the best way to build finite element matricies (or any sparse matrix in my opinion) as access to the first format is really fast (just filling an an array) and conversion is also very fast. In scipy this is called the COO matrix. It sums entries with the same indicies and can be converted to any other format fast. It ignores zeros too (so it does 'the right things' for finite elements). For finite elements, you can estimate the size of the three arrays by something like size = number_of_elements * number_of_basis_functions**2 so if you have 2D quadratics you would do number_of_elements * 36, for example. This approach is convenient because if you have local matricies you definitely have the global numbers and entry values: exactly what you need for building the three IJV arrays. I hope this helps, Dave Wells Virginia Tech > Message: 4 > Date: Wed, 9 May 2012 11:36:39 -0700 (PDT) > From: cp3028 <cp3028(a)googlemail.com> > Subject: [SciPy-User] How to assemble large sparse matrices > effectively > To: scipy-user(a)scipy.org > Message-ID: > <681b81d4-491f-4b4b-b201-df6bc1fbcce7(a)m10g2000vbb.googlegroups.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello everyone, > > I am working on an FEM project using Scipy. Now my problem is, that > the assembly of the sparse matrices is to slow. I compute the > contribution of every element in dense small matrices (one for each > element). For the assembly of the global matrices I loop over all > small dense matrices and set the matrice entries the following way: > ... > [i,j] = someList[k][l] > Mglobal[i,j] = Mglobal[i,j] + Mlocal[k,l] > ... > > Mglobal is a lil_matrice of appropriate size, someList maps the > indexing variables. > > Of course this is rather slow and consumes most of the matrice > assembly time. Is there a better way to assemble a large sparse matrix > from many small dense matrices? I tried scipy.weave but it doesn't > seem to work with sparse matrices > > Yours, > > cm

1 0

How to assemble large sparse matrices effectively
by cp3028 12 May '12

12 May '12

Hello everyone, I am working on an FEM project using Scipy. Now my problem is, that the assembly of the sparse matrices is to slow. I compute the contribution of every element in dense small matrices (one for each element). For the assembly of the global matrices I loop over all small dense matrices and set the matrice entries the following way: ... [i,j] = someList[k][l] Mglobal[i,j] = Mglobal[i,j] + Mlocal[k,l] ... Mglobal is a lil_matrice of appropriate size, someList maps the indexing variables. Of course this is rather slow and consumes most of the matrice assembly time. Is there a better way to assemble a large sparse matrix from many small dense matrices? I tried scipy.weave but it doesn't seem to work with sparse matrices Yours, cm

2 1

ANN: NumPy 1.6.2 release candidate 1
by Ralf Gommers 11 May '12

11 May '12

Hi, I'm pleased to announce the availability of the first release candidate of NumPy 1.6.2. This is a maintenance release. Due to the delay of the NumPy 1.7.0, this release contains far more fixes than a regular NumPy bugfix release. It also includes a number of documentation and build improvements. Sources and binary installers can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.6.2rc1/ Please test this release and report any issues on the numpy-discussion mailing list. Cheers, Ralf ``numpy.core`` issues fixed --------------------------- #2063 make unique() return consistent index #1138 allow creating arrays from empty buffers or empty slices #1446 correct note about correspondence vstack and concatenate #1149 make argmin() work for datetime #1672 fix allclose() to work for scalar inf #1747 make np.median() work for 0-D arrays #1776 make complex division by zero to yield inf properly #1675 add scalar support for the format() function #1905 explicitly check for NaNs in allclose() #1952 allow floating ddof in std() and var() #1948 fix regression for indexing chararrays with empty list #2017 fix type hashing #2046 deleting array attributes causes segfault #2033 a**2.0 has incorrect type #2045 make attribute/iterator_element deletions not segfault #2021 fix segfault in searchsorted() #2073 fix float16 __array_interface__ bug ``numpy.lib`` issues fixed -------------------------- #2048 break reference cycle in NpzFile #1573 savetxt() now handles complex arrays #1387 allow bincount() to accept empty arrays #1899 fixed histogramdd() bug with empty inputs #1793 fix failing npyio test under py3k #1936 fix extra nesting for subarray dtypes #1848 make tril/triu return the same dtype as the original array #1918 use Py_TYPE to access ob_type, so it works also on Py3 ``numpy.f2py`` changes ---------------------- ENH: Introduce new options extra_f77_compiler_args and extra_f90_compiler_args BLD: Improve reporting of fcompiler value BUG: Fix f2py test_kind.py test ``numpy.poly`` changes ---------------------- ENH: Add some tests for polynomial printing ENH: Add companion matrix functions DOC: Rearrange the polynomial documents BUG: Fix up links to classes DOC: Add version added to some of the polynomial package modules DOC: Document xxxfit functions in the polynomial package modules BUG: The polynomial convenience classes let different types interact DOC: Document the use of the polynomial convenience classes DOC: Improve numpy reference documentation of polynomial classes ENH: Improve the computation of polynomials from roots STY: Code cleanup in polynomial [*]fromroots functions DOC: Remove references to cast and NA, which were added in 1.7 ``numpy.distutils`` issues fixed ------------------------------- #1261 change compile flag on AIX from -O5 to -O3 #1377 update HP compiler flags #1383 provide better support for C++ code on HPUX #1857 fix build for py3k + pip BLD: raise a clearer warning in case of building without cleaning up first BLD: follow build_ext coding convention in build_clib BLD: fix up detection of Intel CPU on OS X in system_info.py BLD: add support for the new X11 directory structure on Ubuntu & co. BLD: add ufsparse to the libraries search path. BLD: add 'pgfortran' as a valid compiler in the Portland Group BLD: update version match regexp for IBM AIX Fortran compilers.

3 2

OT: Python and C syntax highlighting with LaTeX
by Sturla Molden 10 May '12

10 May '12

I know this is slightly OT on the scipy list, but it applies to scientific computing nevertheless. Do you have suggesting for a LaTeX package to do consistent syntax highlighting of Python and C (preferably C99)? Colors are ok, but I want C and Python to look about the same style wise. Regards, Sturla

3 2

Using Scipy Sparse Matrices and Weave Inline possible?
by cp3028 10 May '12

10 May '12

Hello Everyone, I have to assemble a very large sparse matrix from small dense matrices. Is there a way to use weave.inlne to speed up the process? The problem is, the entries of the small dense matrices are distributed very irregular on the large sparse matrice. Until now I loop over all dense matrices and every entry and assign it to the corresponding position in the sparse large matrice through a lookup table. Is there a faster way? Cheers!

2 1

How to assemble large sparse matrices effectively
by cp3028 10 May '12

10 May '12

Hello everyone, I am working on an FEM project using Scipy. Now my problem is, that the assembly of the sparse matrices is to slow. I compute the contribution of every element in dense small matrices (one for each element). For the assembly of the global matrices I loop over all small dense matrices and set the matrice entries the following way: ... [i,j] = someList[k][l] Mglobal[i,j] = Mglobal[i,j] + Mlocal[k,l] ... Mglobal is a lil_matrice of appropriate size, someList maps the indexing variables. Of course this is rather slow and consumes most of the matrice assembly time. Is there a better way to assemble a large sparse matrix from many small dense matrices? I tried scipy.weave but it doesn't seem to work with sparse matrices Yours, cm

1 0