Mailman 3 September 2014 - NumPy-Discussion

Add `nrows` to `genfromtxt`
by Jaime Fernández del Río Nov. 3, 2014

Nov. 3, 2014

There is a PR in github that adds a new keyword to the genfromtxt function, to limit the number of rows that actually get read in: https://github.com/numpy/numpy/pull/5103 It is mostly ready to go, and several devs have looked at it without complaining. Since it is an API change, I wanted to check here: if no one has any strong opposition, I will be merging it sometime tomorrow. You have been warned... ;-) Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

5 16

f2py and debug mode
by Bayard Oct. 6, 2014

Oct. 6, 2014

Hello to all. I'm aiming to wrap a Fortran program into Python. I started to work with f2py, and am trying to setup a debug mode where I could reach breakpoints in Fortran module launched by Python. I've been looking in the existing post, but not seeing things like that. I'm used to work with visual studio 2012 and Intel Fortran compiler, I have tried to get that point doing : 1) Run f2py -m to get *.c wrapper 2) Embed it in a C Project in Visual Studio, containing also with fortranobject.c and fortranobject.h, 3) Create a solution which also contains my fortran files compiled as a lib 4) Generate in debug mode a "dll" with extension pyd (to get to that point name of the "main" function in Fortran by "_main"). I compiled without any error, and reach break point in C Wrapper, but not in Fortran, and the fortran code seems not to be executed (whereas it is when compiling with f2py -c). Trying to understand f2py code, I noticed that f2py is not only writing c-wrapper, but compiling it in a specific way. Is there a way to get a debug mode in Visual Studio with f2py (some members of the team are used to it) ? Any alternative tool we should use for debugging ? Thanks for answering Ferdinand --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com

3 2

Round away from zero (towards +/- infinity)
by T J Oct. 4, 2014

Oct. 4, 2014

Is there a ufunc for rounding away from zero? Or do I need to do x2 = sign(x) * ceil(abs(x)) whenever I want to round away from zero? Maybe the following is better? x_ceil = ceil(x) x_floor = floor(x) x2 = where(x >= 0, x_ceil, x_floor) Python's round function goes away from zero, so I am looking for the NumPy equivalent (and using vectorize() seems undesirable). In this sense, it seems that having a ufunc for this type of rounding could be helpful. Aside: Is there interest in a more general around() that allows users to specify alternative tie-breaking rules, with the default staying 'round half to nearest even'? [1] Also, what is the difference between NumPy's fix() and trunc() functions? It seems like they achieve the same goal. trunc() was added in 1.3.0. So is fix() just legacy? --- [1] http://stackoverflow.com/questions/16000574/tie-breaking-of-round-with-numpy

3 4

Proposal: add ndarray.keys() to return dtype.names
by John Zwinck Oct. 2, 2014

Oct. 2, 2014

I first proposed this on GitHub: https://github.com/numpy/numpy/issues/5134 ; jaimefrio requested that I bring it to this list for discussion. My proposal is to add a keys() method to NumPy's array class ndarray. The behavior would be to return self.dtype.names, i.e. the "column names" for a structured array (and None when dtype.names is None, which it is for pure numeric arrays without named columns). I originally proposed to add a values() method also, but I am tabling that for now so we needn't discuss it in this thread. The motivation is to enhance the ability to use duck typing with NumPy arrays, Python dicts, and other types like Pandas DataFrames, h5py Files, and more. It's a fairly common thing to want to get the "keys" of a container, where "keys" is understood to be a sequence of values one can pass to __getitem__(), and this is exactly what I'm aiming at. Thoughts? John Zwinck

5 12

Interpolation using `np.interp()` with periodic x-coordinates
by Saullo Castro Oct. 2, 2014

Oct. 2, 2014

>From the closed pull request PR #5109: https://github.com/numpy/numpy/pull/5109 it came out that the a good implementation would be adding a parameter `period`. I would like to know about the community's interest for this implementation. The modification are shown here: https://github.com/saullocastro/numpy/compare/interp_with_period?expand=1 Please, let me know about your feedback. Regards, Saullo

2 1

Hamming etc. windows are wrong
by Jerry Sept. 28, 2014

Sept. 28, 2014

I’ve noticed that the Hamming window (and I suppose other windows) provided by Octave, SciPy****, and NumPy***** is wrong, returning a window that is symmetric rather than one that is “DFT symmetric.” This is easily spotted by looking at the first and last points of the window; if they are the same values, then the window is incorrect. These windows are normally applied to data that are equally spaced, thus implying that their DFTs are periodic. Let’s assume that we are windowing N data points, indexed from 0 to N-1 as is normal in signal processing. Then the DFT is also N points long, also indexed from 0 to N-1. The periodic extension principal implies that the point indexed by N in the DFT domain has the same value as the point indexed by 0. The window can also be imagined to have the same kind of periodic extension, so that what would be the N-th point of the window matches the N-point of the data with the same weight as was applied to the 0-th point of the data but without duplicating that point at N-1. This mistake is widespread, infecting many software packages. (I am sending this same note to the NumPy, SciPy, and Octave lists.) It is certainly wrong in most textbooks, including the classic, Oppenheim & Schafer, 1975. However, the definitive and widely referenced paper on windows by Fredric J. Harris, “On the Use of Windows for Harmonic Analysis with the Discrete Fourier Transform,” Proceedings of the IEEE, vol. 66, NO. 1 , January, 1978 * discusses this problem, both its roots and its correction. For example, quoting from the paper: “Since the DFT essentially considers sequences to be periodic, we can consider the missing end point to be the beginning of the next period of the periodic extension of this sequence. In fact, under the periodic extension, the next sample (at 16 s in Fig. 1.) is indistinguishable from the sample at zero seconds. “This apparent lack of symmetry due to the missing (but implied) end point is a source of confusion in sampled window design. This can be traced to the early work related to convergence factors for the partial sums of the Fourier series. The partial sums (or the finite Fourier transform) always include an odd number of points and exhibit even symmetry about the origin. Hence much of the literature and many software libraries incorporate windows designed with true even symmetry rather than the implied symmetry with the missing end point!” ...and later... “We will now catalog some well-known (and some not well-known windows. For each window we will comment on the justification for its use and identify its significant parameters. All the windows will be presented as even (about the origin) sequences with an odd number of points. To convert the window to DFT even, the right endpoint will be discarded and the sequence will be shifted so that the left end point coincides with the origin.” Note that he limits himself therefore to even-numbered "DFT even" windows, but the rule remains--honor the implied periodicity even for windows of odd length. Lest one consider this a trivial difference, consider the following Octave-Matlab code (corresponding NumPy and SciPy code would yield the same results). x = ones(8, 1); # An even sequence; its DFT should be real. hWrong = hamming(8) h9 = hamming(9); hRight = h9(1:8) xWrong = x .* hWrong; # Multiplication by "ones" xRight = x .* hRight; # shown for clarity. XWrong = fft(xWrong) # Contains nonzero imaginary part. XRight = fft(xRight) # Real, as expected from evenness of x. XWrongMag = abs(XWrong) # The magnitudes are XRightMag = abs(XRight) # also different. This causes the following output: hWrong = 0.080000 0.253195 0.642360 0.954446 0.954446 0.642360 0.253195 0.080000 hRight = 0.080000 0.214731 0.540000 0.865269 1.000000 0.865269 0.540000 0.214731 XWrong = 3.86000 + 0.00000i -1.76795 - 0.73231i 0.13889 + 0.13889i 0.01906 + 0.04602i 0.00000 + 0.00000i 0.01906 - 0.04602i 0.13889 - 0.13889i -1.76795 + 0.73231i XRight = 4.32000 + 0.00000i -1.84000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 - 0.00000i 0.00000 - 0.00000i -1.84000 - 0.00000i XWrongMag = 3.86000 1.91362 0.19642 0.04981 0.00000 0.04981 0.19642 1.91362 XRightMag = 4.32000 1.84000 0.00000 0.00000 0.00000 0.00000 0.00000 1.84000 This news will likely upset many and I will be interested to see what arguments will flow in favor of keeping the status quo--I’m sure one will be, “we’ve always done it this way” and others will be more substantial, possibly expressing decent arguments why the current situation is useful for some applications. In any case, I refer again to the Harris paper. So rather than host an argument on this list, this is what I propose: Do what Matlab** does. Acknowledge both uses by making a flag to handle the “periodic” or the “symmetric” cases. The Matlab default is “symmetric” which is of course unfortunate but at least such inclusion in Octave, NumPy, and SciPy would retain compatibility with the existing usage. Then it’s up to the user whether to shoot him/herself in the foot, assuming that such a decision is guided by actually referring to the documentation for the package being used and not blindly using the default. Jerry Bauck * http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1455106&url=http%3A%2… ** http://www.mathworks.com/help/signal/ref/hamming.html *** http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.signal.ham… **** I am just learning Python-NumPy-SciPy but it appears as though the SciPy situation is that the documentation page above *** mentions the flag but the flag has not been implemented into SciPy itself. I would be glad to stand corrected. ***** http://docs.scipy.org/doc/numpy/reference/generated/numpy.hamming.html

5 6

Strange bug in SVD when numpy is installed with pip
by Darlan Cavalcante Moreira Sept. 27, 2014

Sept. 27, 2014

Some time ago I have reported a bug about the linalg.matrix_rank in numpy for complex matrices. This was quickly fixed and to take the advantage of the fix I'm now using numpy 1.9.0 installed through pip, instead of the version from my system (Ubuntu 14.04, with numpy version 1.8.1). However, I have now encountered a very strange bug in the SVD function, but only when numpy is manually installed (with pip in my case). When I calculate the SVD of complex matrices with more columns than rows the last rows of the returned V_H matrix are all equal to zeros. This does not happens for all shapes, but for the ones where this happens it will always happen. This can be reproduced with the code below. You can change the sizes of M and N and it happens for other sizes where N > M, but now all of them. --8<---------------cut here---------------start------------->8--- import numpy as np M = 8 # Number of rows N = 12 # Number of columns # Calculate the SVD of a non-square complex random matrix [U, S, V_H] = np.linalg.svd(np.random.randn(M, N) + 1j*np.random.randn(M, N), full_matrices=True) # Calculate the norm of the submatrix formed by the last N-M rows if np.linalg.norm(V_H[M-N:]) < 1e-30: print("Bug!") else: print("No Bug") # See the N-M rows. They are all equal to zeros print(V_H[M-N:]) --8<---------------cut here---------------end--------------->8--- The original matrix can still be obtained from the decomposition, since the zero rows correspond to zero singular values due to the fact that the original matrix has more columns then rows. However, since the user asked for 'full_matrices' here (the default) returning all zeroes for these extra rows is not useful. In order to isolate the bug I tried installing some different numpy versions in different virtualenvs. I tried version 1.6, 1.7, 1.8.1 and 1.9 and the bug appears in all of then. Since it does not happen if I use the version 1.8.1 installed through the Ubuntu package manager, I imagine it is due to some issue when pip compiles numpy locally. Note: If I run numpy.testing.test() all tests are OK for all numpy versions I have tested. The only fail is a known fail and I get "OK (KNOWNFAIL=1)". -- Darlan Cavalcante Moreira

3 4

Online docs for numpy are for version 1.8
by Warren Weckesser Sept. 25, 2014

Sept. 25, 2014

Pinging the webmeisters: numpy 1.9 is released, but the docs at http://docs.scipy.org/doc/numpy/ are still for version 1.8. Warren

1 0

ANN: SfePy 2014.3
by Robert Cimrman Sept. 25, 2014

Sept. 25, 2014

I am pleased to announce release 2014.3 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (preliminary support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker, wiki: http://github.com/sfepy Highlights of this release -------------------------- - isogeometric analysis (IGA) speed-up by C implementation of NURBS basis evaluation - generalized linear combination boundary conditions that work between different fields/variables and support non-homogeneous periodic conditions - non-constant essential boundary conditions given by a function in IGA - reorganized and improved documentation For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman and Contributors (*) (*) Contributors to this release (alphabetical order): Vladimir Lukes, Matyas Novak, Zhihua Ouyang, Jaroslav Vondrejc

1 0

Fwd: Sport Rock Friday?
by Aron Ahmadia Sept. 25, 2014

Sept. 25, 2014

---------- Forwarded message ---------- From: *Brian Joseph* <briansenta(a)gmail.com> Date: Thursday, September 25, 2014 Subject: Sport Rock Friday? To: Aron Ahmadia <aron(a)ahmadia.net> Hey Aron want to hit up Sport Rock tomorrow night? Meg and I would like to go. Meg has to work until 8, so how does 8:30 sound?

1 1