Mailman 3 October 2013 - NumPy-Discussion

Equivalent to IDL's help function
by Siegfried Gonzi 19 Oct '13

19 Oct '13

Hi all What is the equivalent to IDL its help function, e.g. == IDL> a = make_array(23,23,) IDL> help,a will result in: A FLOAT = Array[23, 23] or IDL> a = create_struct('idl',23) IDL> help,a gives: A STRUCT = -> <Anonymous> Array[1] == I have been looking for it ever since using numpy. It would make my life so much easier. Thanks, Siegfried -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

6 5

how to do scoring of random point to avoid overlapping in python
by Pooja Gupta 18 Oct '13

18 Oct '13

I have generated random point around a object and then evaluate each random point on certain criteria. But problem is that every time I am getting new point. How i can resolve this problem so that my result should be uniform. Is any way to evaluate the position of random point. for arang in range(1000): # generate 1000 random point around object arang = arang + 1 x,y,z = 9.251, 24.410, 64.133 # coordinates of objects (i have 500 object coordinates) x1,y1,z1 = (uniform(x-3.5,x+3.5),uniform(y-3.5,y+3.5),uniform(z-3.5,z+3.5)) #randompoint pacord = [x1,y1,z1] #random point coordinates dist_pap = euDist(uacoord, pacord) # check distance between object and random points if (dist_pap > 2.5): # if the random point far from obect dist_pap1 = dist_pap vecpw = euvector(uacoord, pacord) # generate vectors b/w objject and random point # angle between angle between object and random point num1 = np.dot (vect1, vecpw) denom1 = np.linalg.norm(vect1) * np.linalg.norm(vecpw) ang1 = rad2deg(np.arccos(num1/denom1)) if 140 > ang1 >100: # check angle ang2= ang1print pacord Queries every time i am getting new result (new positions of the random point). How to fix it. on above basis I want to score each random point and the two random point should be 2.5 distance apart from each other. How I can avoid overlapping of the random points. -- पूजा गुप्ता, पीएचडी राष्ट्रीय कोशिका विज्ञान केंद्र "जीवन को खुल कर मुस्कुराने दो, खोल दो बाहे अवसर आने दो । पग बढाओ हर पथ तुम्हारा है, पथ कंटक मंजिलो का इशारा है।।"

2 2

NumPy 1.8.0rc2 release
by Charles R Harris 17 Oct '13

17 Oct '13

Hi All, NumPy 1.8.0rc2 is up now on sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc2/>. Binary builds are included, except for Python 3.3 on windows. Many thanks to Ralf for the binaries and to those who found and fixed the bugs in rc1. Please test this thoroughly, especially if you have access to one of the less common platforms. Testing of rc1 turned up several bugs that would have been a embarrassment if they had made their way into the release and we are very happy that they were discovered. Chuck

3 4

On Topic: Faster way to implement Bernstein polys: explicit or recursion?
by David Goldsmith 17 Oct '13

17 Oct '13

Many thanks to Daniele Nicolodi for pointing me to the Wikipedia article on Bézier curves. Said article gives two formulae for the Bézier curve of degree n: one explicit, one recursive. Using numpy.polynomial.Polynomial as the base class, and its evaluation method for the evaluation in each dimension, which approach is likely to be faster for evaluation at parameter t? Does it depend on the degree, i.e., one approach will likely be faster for low degree while the other will likely be faster for higher degree? Thanks! DG

1 0

Using array mask swaps array axes
by Chad Kidder 17 Oct '13

17 Oct '13

Just found what should be a bug in 1.7.1. I'm running python(x,y) on windows here: >>> dataMatrix[ii,:,mask].shape (201, 23) >>> dataMatrix[ii,:,:].shape (23, 201) >>> dataMatrix.shape (24, 23, 201) >>> mask array([ True, True, True, True, True, True, True, True, True, ... True, True, True], dtype=bool) using a mask should not change the order of the dimensions. Is there a reason for this behavior, and if so, how do I avoid it in the future? Thanks --Chad Kidder

3 3

numpy ACML support is kind of broken
by Thomas Unthiner 17 Oct '13

17 Oct '13

1 0

Re: [Numpy-discussion] Bug in numpy.correlate documentation
by David Goldsmith 15 Oct '13

15 Oct '13

Date: Wed, 9 Oct 2013 21:54:07 +0100 > From: Nathaniel Smith <njs(a)pobox.com> > Subject: Re: [Numpy-discussion] Bug in numpy.correlate documentation > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: > <CAPJVwBmMZKN= > z8V-aHUU+85LZ88xYWmAwxgzHk5GhtfuW8HN9A(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Wed, Oct 9, 2013 at 7:48 PM, Bernhard Spinnler > <Bernhard.Spinnler(a)gmx.net> wrote: > > Hi Richard, > > > > Ah, I searched the list but didn't find those posts before? > > > > I can easily imagine that correlation is defined differently in different > > disciplines. Both ways are correct and it's just a convention or > definition. > > In my field (Digital Communications, Digital Signal Processing) the vast > > majority uses the convention implemented by the code. Here are a few > > examples of prominent text books: > > > > - Papoulis, "Probaility, Random Variables, and Stochastic Processes", > > McGraw-Hill, 2nd ed. > > - Benvenuto, Cherubini, "Algorithms for Communications Systems and their > > Applications", Wiley. > > - Carlson, "Communication Systems" 4th ed. 2002, McGraw-Hill. > > > > Last not least, Matlab's xcorr() function behaves exactly like > correlate() > > does right now, see > > - http://www.mathworks.de/de/help/signal/ref/xcorr.html > > > > But, as you say, the most important aspect might be, that most people > will > > probably prefer changing the docs instead of changing the code. > > Yeah, unless the current behaviour is actually broken or redundant in > some way, we're not going to switch from one perfectly good convention > to another perfectly good convention and break everyone's code in the > process. > > The most helpful thing would be if you could file a pull request that > just changes the docstring to what you think it should be. Extra bonus > points if it points out that there is another definition some people > might be expecting instead, and explains how those people can use the > existing functions to get what they want. :-) > > -n > IMHO, "point[ing] out that there is another definition some people might be expecting instead, and explain[ing] how those people can use the existing functions to get what they want" should be a requirement for the docstring ("Notes" section), not merely worth "extra bonus points." But then I'm not, presently, in a position to edit the docstring myself, so that's just MHO. IAE, I found what appears to me to be another "vote" for the extant docstring: Box & Jenkins, 1976, "Time Series Analysis: Forecasting and Control," Holden-Day, Oakland, pg. 374. Perhaps a "switch" (with a default value that maintains current definition, so that extant uses would not require a code change) c/should be added to the function signature so that users can get easily get what they want? DG

3 3

ANN: Scipy 0.13.0 release candidate 1
by Ralf Gommers 12 Oct '13

12 Oct '13

Hi all, Hi all, I'm happy to announce the availability of the first release candidate of Scipy 0.13.0. Please try this RC and report any issues on the scipy-dev mailing list. Source tarballs, binaries and release notes can be found at http://sourceforge.net/projects/scipy/files/scipy/0.13.0rc1/. Thanks to everyone who helped test and fix the beta release. This is shaping up to be a very solid release. Cheers, Ralf ========================== SciPy 0.13.0 Release Notes ========================== .. note:: Scipy 0.13.0 is not released yet! .. contents:: SciPy 0.13.0 is the culmination of 7 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 0.13.x branch, and on adding new features on the master branch. This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater. New features ============ ``scipy.integrate`` improvements -------------------------------- N-dimensional numerical integration ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A new function `scipy.integrate.nquad`, which provides N-dimensional integration functionality with a more flexible interface than ``dblquad`` and ``tplquad``, has been added. ``dopri*`` improvements ^^^^^^^^^^^^^^^^^^^^^^^ The intermediate results from the ``dopri`` family of ODE solvers can now be accessed by a *solout* callback function. ``scipy.linalg`` improvements ----------------------------- Interpolative decompositions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Scipy now includes a new module `scipy.linalg.interpolative` containing routines for computing interpolative matrix decompositions (ID). This feature is based on the ID software package by P.G. Martinsson, V. Rokhlin, Y. Shkolnisky, and M. Tygert, previously adapted for Python in the PymatrixId package by K.L. Ho. Polar decomposition ^^^^^^^^^^^^^^^^^^^ A new function `scipy.linalg.polar`, to compute the polar decomposition of a matrix, was added. BLAS level 3 functions ^^^^^^^^^^^^^^^^^^^^^^ The BLAS functions ``symm``, ``syrk``, ``syr2k``, ``hemm``, ``herk`` and ``her2k`` are now wrapped in `scipy.linalg`. Matrix functions ^^^^^^^^^^^^^^^^ Several matrix function algorithms have been implemented or updated following detailed descriptions in recent papers of Nick Higham and his co-authors. These include the matrix square root (``sqrtm``), the matrix logarithm (``logm``), the matrix exponential (``expm``) and its Frechet derivative (``expm_frechet``), and fractional matrix powers (``fractional_matrix_power``). ``scipy.optimize`` improvements ------------------------------- Trust-region unconstrained minimization algorithms ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The ``minimize`` function gained two trust-region solvers for unconstrained minimization: ``dogleg`` and ``trust-ncg``. ``scipy.sparse`` improvements ----------------------------- Boolean comparisons and sparse matrices ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ All sparse matrix types now support boolean data, and boolean operations. Two sparse matrices `A` and `B` can be compared in all the expected ways `A < B`, `A >= B`, `A != B`, producing similar results as dense Numpy arrays. Comparisons with dense matrices and scalars are also supported. CSR and CSC fancy indexing ^^^^^^^^^^^^^^^^^^^^^^^^^^ Compressed sparse row and column sparse matrix types now support fancy indexing with boolean matrices, slices, and lists. So where A is a (CSC or CSR) sparse matrix, you can do things like:: >>> A[A > 0.5] = 1 # since Boolean sparse matrices work >>> A[:2, :3] = 2 >>> A[[1,2], 2] = 3 ``scipy.sparse.linalg`` improvements ------------------------------------ The new function ``onenormest`` provides a lower bound of the 1-norm of a linear operator and has been implemented according to Higham and Tisseur (2000). This function is not only useful for sparse matrices, but can also be used to estimate the norm of products or powers of dense matrices without explictly building the intermediate matrix. The multiplicative action of the matrix exponential of a linear operator (``expm_multiply``) has been implemented following the description in Al-Mohy and Higham (2011). Abstract linear operators (`scipy.sparse.linalg.LinearOperator`) can now be multiplied, added to each other, and exponentiated, producing new linear operators. This enables easier construction of composite linear operations. ``scipy.spatial`` improvements ------------------------------ The vertices of a `ConvexHull` can now be accessed via the `vertices` attribute, which gives proper orientation in 2-D. ``scipy.signal`` improvements ----------------------------- The cosine window function `scipy.signal.cosine` was added. ``scipy.special`` improvements ------------------------------ New functions `scipy.special.xlogy` and `scipy.special.xlog1py` were added. These functions can simplify and speed up code that has to calculate ``x * log(y)`` and give 0 when ``x == 0``. ``scipy.io`` improvements ------------------------- Unformatted Fortran file reader ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The new class `scipy.io.FortranFile` facilitates reading unformatted sequential files written by Fortran code. ``scipy.io.wavfile`` enhancements ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `scipy.io.wavfile.write` now accepts a file buffer. Previously it only accepted a filename. `scipy.io.wavfile.read` and `scipy.io.wavfile.write` can now handle floating point WAV files. ``scipy.interpolate`` improvements ---------------------------------- B-spline derivatives and antiderivatives ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `scipy.interpolate.splder` and `scipy.interpolate.splantider` functions for computing B-splines that represent derivatives and antiderivatives of B-splines were added. These functions are also available in the class-based FITPACK interface as ``UnivariateSpline.derivative`` and ``UnivariateSpline.antiderivative``. ``scipy.stats`` improvements ---------------------------- Distributions now allow using keyword parameters in addition to positional parameters in all methods. The function `scipy.stats.power_divergence` has been added for the Cressie-Read power divergence statistic and goodness of fit test. Included in this family of statistics is the "G-test" (http://en.wikipedia.org/wiki/G-test). `scipy.stats.mood` now accepts multidimensional input. An option was added to `scipy.stats.wilcoxon` for continuity correction. `scipy.stats.chisquare` now has an `axis` argument. `scipy.stats.mstats.chisquare` now has `axis` and `ddof` arguments. Deprecated features =================== ``expm2`` and ``expm3`` ----------------------- The matrix exponential functions `scipy.linalg.expm2` and `scipy.linalg.expm3` are deprecated. All users should use the numerically more robust `scipy.linalg.expm` function instead. ``scipy.stats`` functions ------------------------- `scipy.stats.oneway` is deprecated; `scipy.stats.f_oneway` should be used instead. `scipy.stats.glm` is deprecated. `scipy.stats.ttest_ind` is an equivalent function; more full-featured general (and generalized) linear model implementations can be found in statsmodels. `scipy.stats.cmedian` is deprecated; ``numpy.median`` should be used instead. Backwards incompatible changes ============================== LIL matrix assignment --------------------- Assigning values to LIL matrices with two index arrays now works similarly as assigning into ndarrays:: >>> x = lil_matrix((3, 3)) >>> x[[0,1,2],[0,1,2]]=[0,1,2] >>> x.todense() matrix([[ 0., 0., 0.], [ 0., 1., 0.], [ 0., 0., 2.]]) rather than giving the result:: >>> x.todense() matrix([[ 0., 1., 2.], [ 0., 1., 2.], [ 0., 1., 2.]]) Users relying on the previous behavior will need to revisit their code. The previous behavior is obtained by ``x[numpy.ix_([0,1,2],[0,1,2])] = ...`. Deprecated ``radon`` function removed ------------------------------------- The ``misc.radon`` function, which was deprecated in scipy 0.11.0, has been removed. Users can find a more full-featured ``radon`` function in scikit-image. Removed deprecated keywords ``xa`` and ``xb`` from ``stats.distributions`` -------------------------------------------------------------------------- The keywords ``xa`` and ``xb``, which were deprecated since 0.11.0, have been removed from the distributions in ``scipy.stats``. Changes to MATLAB file readers / writers ---------------------------------------- The major change is that 1D arrays in numpy now become row vectors (shape 1, N) when saved to a MATLAB 5 format file. Previously 1D arrays saved as column vectors (N, 1). This is to harmonize the behavior of writing MATLAB 4 and 5 formats, and adapt to the defaults of numpy and MATLAB - for example ``np.atleast_2d`` returns 1D arrays as row vectors. Trying to save arrays of greater than 2 dimensions in MATLAB 4 format now raises an error instead of silently reshaping the array as 2D. ``scipy.io.loadmat('afile')`` used to look for `afile` on the Python system path (``sys.path``); now ``loadmat`` only looks in the current directory for a relative path filename. Other changes ============= Security fix: ``scipy.weave`` previously used temporary directories in an insecure manner under certain circumstances. Cython is now required to build *unreleased* versions of scipy. The C files generated from Cython sources are not included in the git repo anymore. They are however still shipped in source releases. The code base received a fairly large PEP8 cleanup. A ``tox pep8`` command has been added; new code should pass this test command. Authors ======= This release contains work by the following people (contributed at least one patch to this release, names in alphabetical order): * Jorge Cañardo Alastuey + * Tom Aldcroft + * Max Bolingbroke + * Joseph Jon Booker + * François Boulogne * Matthew Brett * Christian Brodbeck + * Per Brodtkorb + * Christian Brueffer + * Lars Buitinck * Evgeni Burovski + * Tim Cera * Lawrence Chan + * David Cournapeau * Dražen Lučanin + * Alexander J. Dunlap + * endolith * André Gaul + * Christoph Gohlke * Ralf Gommers * Alex Griffing + * Blake Griffith + * Charles Harris * Bob Helmbold + * Andreas Hilboll * Kat Huang + * Oleksandr (Sasha) Huziy + * Gert-Ludwig Ingold + * Thouis (Ray) Jones * Juan Luis Cano Rodríguez + * Robert Kern * Andreas Kloeckner + * Sytse Knypstra + * Gustav Larsson + * Denis Laxalde * Christopher Lee * Tim Leslie * Wendy Liu + * Clemens Novak + * Takuya Oshima + * Josef Perktold * Illia Polosukhin + * Przemek Porebski + * Steve Richardson + * Branden Rolston + * Skipper Seabold * Fazlul Shahriar * Leo Singer + * Rohit Sivaprasad + * Daniel B. Smith + * Julian Taylor * Louis Thibault + * Tomas Tomecek + * John Travers * Richard Tsai + * Jacob Vanderplas * Patrick Varilly * Pauli Virtanen * Stefan van der Walt * Warren Weckesser * Pedro Werneck + * Nils Werner + * Michael Wimmer + * Nathan Woods + * Tony S. Yu + A total of 65 people contributed to this release. People with a "+" by their names contributed a patch for the first time.

1 0

Python function for line intersection??
by Happyman 11 Oct '13

11 Oct '13

Hello, I am having trouble with solving line intersection problem. I would solve it using standard functions which may already exist in Python library. Let me explain it below: I have sets of lines A(x,y) and B(x,y) and one map as a matrix form, also with its resolution dx, dy which can be changed. I wanted to calculate all intersected points of line with the map depending on dx, dy value. I already did it, but two problems: 1) When some coordinate value (x or y) are zero, the program returns wrong answer. For example, distance is zero, but it is not zero in fact. 2) How can I optimize my code (using Python standard library), if possible. Or is there standard Python library for that purpose??? import numpy as np def intrsctd_pnts(map, dx, dy, A, B, line_number): height, width = np.shape(map) # slope of each line m = (B[:, 1] - A[:, 1]) / (B[:, 0] - A[:, 0]) b = A[:, 1] - m * A[:, 0] lx_min = np.minimum(A[:,0], B[:,0]) lx_max = np.maximum(A[:,0], B[:,0]) ly_min = np.minimum(A[:,1], B[:,1]) ly_max = np.maximum(A[:,1], B[:,1]) lx_floor = np.ceil(lx_min /dx)*dx lx_ceil = np.floor(lx_max /dx)*dx ly_floor = np.ceil(ly_min /dy)*dy ly_ceil = np.floor(ly_max /dy)*dy distance = [] i_pixel = [] intersect_point = [] for i in range(line_number): AB = [] # calculate all intersected x coordinates x = np.arange(lx_floor[i], lx_ceil[i]+dx, dx) y = m[i] * x + b[i] AB = zip(x, y) # calculate all intersected y coordinates y = np.arange(ly_floor[i], ly_ceil[i]+dy, dy) x = (y - b[i]) / m[i] AB.extend(zip(x, y)) AB.append((A[i,0], A[i,1])) AB.append((B[i,0], B[i,1])) AB.sort() AB = np.asarray(AB) intersect_point.append(AB) # compute distance between two points dist_x = np.diff(AB[:,0]) dist_y = np.diff(AB[:,1]) distance.append( np.sqrt((dist_x)**2 + (dist_y)**2) ) # FIND pixel value where line intersects that pixel col = (np.floor( min(AB[:,0]) / dx)).astype(int) row = (np.floor( min(AB[:,1]) / dy)).astype(int) # FIND pixel to which this lines belong i_pixel.append(col + width*row) return distance, i_pixel, intersect_point def main(): # INPUTS: map = np.array( [ [ 4.5, 4.5, 4.5, 3.4], [ 3.9, 4.5, 5.2, 4.5], [ 3.9, 3.9, 2.5, 2.2], [ 3.4, 3.9, 2.9, 2.2], [ 2.5, 3.4, 2.2, 1.4], [ 2.5, 2.2, 2.5, 1.2] ) dx = dy = 0.5 A = np.array( [ [ 0. , 0. ], [ 1.9 , 0.] ]) B = np.array( [ [ 1.1 , 2.3], [ 1.3 , 1.3] ]) line_number = len(A) # or len(B) distance, pixels, int_points = intrsctd_pnts(map, dx, dy, A, B, line_number) ## distance should not be zero if __name__ == '__main__': main()

2 1

Re: [Numpy-discussion] Bug in numpy.correlate documentation
by David Goldsmith 11 Oct '13

11 Oct '13

Looks like Wolfram MathWorld would favor the docstring, but the possibility of a "use-domain" dependency seems plausible (after all, a similar dilemma is observed, e.g., w/ the Fourier Transform)--I guess one discipline's future is another discipline's past. :-) http://mathworld.wolfram.com/Autocorrelation.html DG Date: Tue, 8 Oct 2013 20:10:41 +0100 > From: Richard Hattersley <rhattersley(a)gmail.com> > Subject: Re: [Numpy-discussion] Bug in numpy.correlate documentation > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: > <CAP=RS9k54vtNFHy9ppG=U09oEHwB=KLV0xvwR6BfFgB3o5S= > fw(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Bernard, > > Looks like you're on to something - two other people have raised this > discrepancy before: https://github.com/numpy/numpy/issues/2588. > Unfortunately, when it comes to resolving the discrepancy one of the > previous comments takes the opposite view. Namely, that the docstring is > correct and the code is wrong. > > Do different domains use different conventions here? Are there some > references to back up one stance or another? > > But all else being equal, I'm guessing there'll be far more appetite for > updating the documentation than the code. > > Regards, > Richard Hattersley > > > On 7 October 2013 22:09, Bernhard Spinnler <Bernhard.Spinnler(a)gmx.net > >wrote: > > > The numpy.correlate documentation says: > > > > correlate(a, v) = z[k] = sum_n a[n] * conj(v[n+k]) > > > <snip> > > [so] according to the documentation, z should be > > > > z[-1] = a[1] * conj(v[0]) = 4.+0.j > > z[0] = a[0] * conj(v[0]) + a[1] * conj(v[1]) = 2.-2.j > > z[1] = a[0] * conj(v[1]) = 0.-1.j > > > > which is the time reversed version of what correlate() calculates. >

2 1