Mailman 3 October 2014 - NumPy-Discussion

return unique combinations of stacked arrays - slow
by Matt Gregory Oct. 21, 2014

Oct. 21, 2014

I'm trying to create an output array of integers where each value represents a unique combination of values from (1..n) input arrays. As a simple example, given these three arrays: a = np.array([0, 1, 2, 3, 0, 1, 2, 3]) b = np.array([0, 1, 0, 1, 0, 1, 0, 1]) c = np.array([0, 1, 1, 0, 0, 1, 0, 1]) I want an output array that holds 'codes' for the unique combinations and a dictionary that holds the unique combinations as keys and codes as values. out = np.array([0, 1, 2, 3, 0, 1, 4, 5]) out_dict = { (0, 0, 0): 0, (1, 1, 1): 1, (2, 0, 1): 2, (3, 1, 0): 3, (2, 0, 0): 4, (3, 1, 1): 5, } An additional constraint is that I'm bringing in the (a, b, c) arrays a chunk at a time due to memory limits (ie. very large rasters) and so I need to retain the mapping between chunks. My current (very naive and pretty slow) implementation in loop form is: out_dict = {} out = np.zeros_like(a) count = 0 stack = np.vstack((a, b, c)).T for (i, arr) in enumerate(stack): t = tuple(arr) if t not in out_dict: out_dict[t] = count count += 1 out[i] = out_dict[t] Thanks for help, matt

2 1

MKL not available as separate download since 10/16/2014
by Mark Mikofski Oct. 21, 2014

Oct. 21, 2014

the old MKL links point to 404.html the new MKL link has this link in the right sidebar: Changes to Intel® Software Development Products | Intel® Developer Zone Changes to Intel® Software Development Products | Intel® Developer Zone Intel® Parallel Studio XE simplification Intel® Parallel Studio XE has been simplified to three editions, Composer, Professional and Cluster. Here’s a table showing the old and new simplified names. More information about Intel Parallel Studio editions is here. View on software.intel.com Preview by Yahoo which has the following statement: Ingredient product availability changes New licenses of the following ingredient products will be available only in suites going forward. Current licensees of these ingredient products can continue to renew support maintenance for their existing license or upgrade to a suite. For more info about the ingredients below, click the product name below: Intel® Integrated Performance Primitives Intel® Math Kernel Library Intel® Threading Building Blocks Intel® Inspector XE “As I breath in, I calm my body, as I breath out, I smile” - Thich_Nhat_Hanh

2 1

ANN: Pandas 0.15.0 released
by Jeff Reback Oct. 19, 2014

Oct. 19, 2014

Hello, We are proud to announce v0.15.0 of pandas, a major release from 0.14.1. This release includes a small number of API changes, several new features, enhancements, and performance improvements along with a large number of bug fixes. This was 4 months of work with 420 commits by 79 authors encompassing 236 issues. We recommend that all users upgrade to this version. *Highlights:* - Drop support for numpy < 1.7.0 - The Categorical type was integrated as a first-class pandas type - New scalar type Timedelta, and a new index type TimedeltaIndex - New DataFrame default display for df.info() to include memory usage - New datetimelike properties accessor .dt for Series - Split indexing documentation into Indexing and Selecting Data and MultiIndex / Advanced Indexing - Split out string methods documentation into Working with Text Data - read_csv will now by default ignore blank lines when parsing - API change in using Indexes in set operations - Internal refactoring of the Index class to no longer sub-class ndarray - dropping support for PyTables less than version 3.0.0, and numexpr less than version 2.1 See a full description of Whatsnew for v0.15.0 here: http://pandas.pydata.org/pandas-docs/stable/whatsnew.html *What is it:* *pandas* is a Python package providing fast, flexible, and expressive data structures designed to make working with “relational” or “labeled” data both easy and intuitive. It aims to be the fundamental high-level building block for doing practical, real world data analysis in Python. Additionally, it has the broader goal of becoming the most powerful and flexible open source data analysis / manipulation tool available in any language. Documentation: http://pandas.pydata.org/pandas-docs/stable/ Source tarballs, windows binaries are available on PyPI: https://pypi.python.org/pypi/pandas windows binaries are courtesy of Christoph Gohlke and are built on Numpy 1.8 macosx wheels are courtesy of Matthew Brett and are built on Numpy 1.7.1 Please report any issues here: https://github.com/pydata/pandas/issues Thanks The Pandas Development Team Contributors to the 0.15.0 release

1 0

Add an axis argument to generalized ufuncs?
by Stephan Hoyer Oct. 19, 2014

Oct. 19, 2014

Yesterday I created a GitHub issue proposing adding an axis argument to numpy's gufuncs: https://github.com/numpy/numpy/issues/5197 I was told I should repost this on the mailing list, so here's the recap: I would like to write generalized ufuncs (probably using numba), to create fast functions such as nanmean (signature '(n)->()') or rolling_mean (signature '(n),()->(n)') that take the axis along which to aggregate as a keyword argument, e.g., nanmean(x, axis=0) or rolling_mean(x, window=5, axis=0). Of course, I could write my own wrapper for this that reorders dimensions using swapaxes or transpose. But I also think that an "axis" argument to allow for specifying the core dimensions of gufuncs would be more generally useful, and we should consider adding it to numpy. Nathaniel and Jaime added some good points, noting that such an axis argument should cleanly handle multiple input and output arguments and have a plan for handling optional dimensions (e.g., (m?,n),(n,p?)->(m?,p?) for the new dot). Here are my initial thoughts on the syntax: (1) Generally speaking, I think the "nested tuple" syntax (e.g., axis=[(0, 1), (2, 3)]) would be most congruous with the axis arguments numpy already supports. (2) For gufuncs with simpler signatures, we should support supplying an integer or an unnested tuple, e.g., - axis=0 for (n)->() - axis=(0, 1) for (n)(m)->() or (n,m)->() - axis=[(0, 1), 2] for (n,m),(o)->(). (3) If we require a full axis specification for core dimensions, we could use the axis argument for unambiguous control of optional core dimensions: e.g., axis=(0, 1) would indicate that you want the "vectorized inner product" version of the new dot operator, rather than matrix multiplication, and axis=[(-2, -1), -1] would mean that you want the "vectorized matrix-vector product". This seems relatively tidy, although I admit I am not convinced that optional core dimensions are necessary. (4) We can either include the output axis as part of the signature, or add another argument "axis_out" or "out_axis". I think prefer the separate argument, particularly if we require "axis" to specify all core dimensions, which may be a good idea even if we don't use "axis" for controlling optional core dimensions. Cheers, Stephan

3 5

np.gradient
by Nathaniel Smith Oct. 19, 2014

Oct. 19, 2014

Okay! I think I now actually understand what was going on with np.gradient! The discussion has been pretty confused, and I'm worried that what's in master right now is not the right solution, which is a problem because we're supposed to cut 1.9.1 tomorrow. Background: np.gradient computes gradients using a finite difference method. Wikipedia has a good explanation of how this works: https://en.wikipedia.org/wiki/Numerical_differentiation The key point is that there are multiple formulas one can use that all converge to the derivative, e.g. (f(x + h) - f(x)) / h or (f(x + h) - f(x - h)) / 2h The first is the textbook definition of the derivative. As h -> 0, the error in that approximation shrinks like O(h). The second formula also converges to the derivative as h -> 0, but it converges like O(h^2), i.e., much faster. And there's are many many formulas like this with different trade-offs: https://en.wikipedia.org/wiki/Finite_difference_coefficient In practice, given a grid of values of f(x) and a grid stepsize of h, all of these formulas come down to doing a simple convolution of the data with certain coefficients (e.g. [-1/h, 1/h] or [-1/2h, 0, 1/2h] for the two formulas above). Traditionally np.gradient has used the second formula above, with its quadratically diminishing error term, for interior points in the grid. For points on the boundary of the grid, though, this formula has a problem, b/c it requires you look at points to both the left and the right of the current point -- but for boundary points one of these doesn't exist. In such situations np.gradient has traditionally used the first formula instead (the "forward (or backward) finite difference approximation with linear error", where "forward"/"backward" means that it works on the boundary). As the web page linked above shows, though, there's an easy alternative formula that works on The change in numpy 1.9.0 that has caused all the fuss, is that we switched to using the quadratically accurate approximation instead of the linearly accurate approximation for boundary points. This had two effects: 1) it produced (hopefully small) changes in the calculation for the boundaries. In general these should have made the calculations more accurate, but apparently this did cause problems for some people who wanted perfectly reproducible output. 2) it tickled a nasty bug in how gradient and masked arrays work together. It turns out gradient applied to masked arrays has always been seriously buggy; there's some horribleness in the masked array implementation that means the output array that np.gradient is writing into ends up sharing a mask array with the input. So as we go along calculating the output, we also mutate the input. This can definitely corrupt the input, for example here: https://gist.github.com/njsmith/551738469b74d175e039 ...and I strongly suspect it's possible to find cases where it means you get the wrong answer. For mysterious reasons involving the order in which values were calculated or something, the version of np.gradient in 1.9.0 tickled this bug in a much worse manner, with early mutations to the input array ended up affecting later calculations using the same input array, causing cascading errors. This is the cause of the massive problems that matplotlib encountered in their test suite: https://github.com/matplotlib/matplotlib/issues/3598#issuecomment-58859663 There's a proposed fix for the masked array issues at: https://github.com/numpy/numpy/pull/5203 For the reasons described above, I would be very wary about using *any* currently released version of np.gradient on masked arrays. A workaround would be to make a local copy of the definition of np.gradient, and immediately after the 'out' array is allocated do 'out.mask = out.mask.copy()'. Once this bug is fixed, the "new" gradient code produces results which are identical to the "old" gradient code on the interior; only the boundary is different. ------ So here are my concerns: - We decided to revert the changes to np.gradient in 1.9.1 (at least by default). I'm not sure how much of that decision was based on the issues with masked arrays, though, which turns out to be a different issue entirely. The previous discussion conflated the two issues above. - We decided to gate the more-accurate boundary calculation behind a kwarg called "edge_order=2". AFAICT now that I actually understand what this code is doing, this is a terrible name -- we're using a 3-coefficient kernel to compute a quadratically accurate approximation to a first-order derivative. There probably exist other kernels that are also quadratically accurate. "Order 2" simply doesn't refer to this in any unique or meaningful way. And it will be even more confusing if we ever add the option to select which kernel to use on the interior, where "quadratically accurate" is definitely not enough information to uniquely define a kernel. Maybe we want something like edge_accuracy=2 or edge_accuracy="quadratic" or something? I'm not sure. - If edge_order=2 escapes into a release tomorrow then we'll be stuck with it. Some possible options for 1.9.1: - Just revert the entire np.gradient code to match 1.8, and put off a real fix until 1.9. This at least avoids getting stuck with a poor API. - Put the masked array bug fix into 1.9.1, and leave the gradient code the same as 1.9.0; put off designing a proper API for selecting the old behavior for 1.9.2. (Or 1.10 I guess.) This doesn't solve the pure reproduceability problems, but it might be enough to make matplotlib work again at least? - Delay 1.9.1 to rehash the issues and make a decision on what we want to support long-term. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org

3 5

Extract Indices of Numpy Array Based on Given Bit Information
by Artur Bercik Oct. 18, 2014

Oct. 18, 2014

Dear Python and Numpy Users: My data are in the form of '32-bit unsigned integer' as follows: myData = np.array([1073741824, 1073741877, 1073742657, 1073742709, 1073742723, 1073755137, 1073755189,1073755969],dtype=np.int32) I want to get the index of my data where the following occurs: Bit No. 0–1 Bit Combination: 00 How can I do it? I heard this type of problem first time, please help me. Artur

2 5

Changed behavior of np.gradient
by Ariel Rokem Oct. 17, 2014

Oct. 17, 2014

Hi everyone, >>> import numpy as np >>> np.__version__ '1.9.0' >>> np.gradient(np.array([[1, 2, 6], [3, 4, 5]], dtype=np.float)) [array([[ 2., 2., -1.], [ 2., 2., -1.]]), array([[-0.5, 2.5, 5.5], [ 1. , 1. , 1. ]])] On the other hand: >>> import numpy as np >>> np.__version__ '1.8.2' >>> np.gradient(np.array([[1, 2, 6], [3, 4, 5]], dtype=np.float)) [array([[ 2., 2., -1.], [ 2., 2., -1.]]), array([[ 1. , 2.5, 4. ], [ 1. , 1. , 1. ]])] For what it's worth, the 1.8 version of this function seems to be in agreement with the Matlab equivalent function ('gradient'): >> gradient([[1, 2, 6]; [3, 4, 5]]) ans = 1.0000 2.5000 4.0000 1.0000 1.0000 1.0000 This seems like a regression to me, but maybe it's an improvement? Cheers,

7 18

Request for enhancement to numpy.random.shuffle
by Warren Weckesser Oct. 17, 2014

Oct. 17, 2014

I created an issue on github for an enhancement to numpy.random.shuffle: https://github.com/numpy/numpy/issues/5173 I'd like to get some feedback on the idea. Currently, `shuffle` shuffles the first dimension of an array in-place. For example, shuffling a 2D array shuffles the rows: In [227]: a Out[227]: array([[ 0, 1, 2], [ 3, 4, 5], [ 6, 7, 8], [ 9, 10, 11]]) In [228]: np.random.shuffle(a) In [229]: a Out[229]: array([[ 0, 1, 2], [ 9, 10, 11], [ 3, 4, 5], [ 6, 7, 8]]) To add an axis keyword, we could (in effect) apply `shuffle` to `a.swapaxes(axis, 0)`. For a 2-D array, `axis=1` would shuffles the columns: In [232]: a = np.arange(15).reshape(3,5) In [233]: a Out[233]: array([[ 0, 1, 2, 3, 4], [ 5, 6, 7, 8, 9], [10, 11, 12, 13, 14]]) In [234]: axis = 1 In [235]: np.random.shuffle(a.swapaxes(axis, 0)) In [236]: a Out[236]: array([[ 3, 2, 4, 0, 1], [ 8, 7, 9, 5, 6], [13, 12, 14, 10, 11]]) So that's the first part--adding an `axis` keyword. The other part of the enhancement request is to add a shuffle behavior that shuffles the 1-d slices *independently*. That is, for a 2-d array, shuffling with `axis=0` would apply a different shuffle to each column. In the github issue, I defined a function called `disarrange` that implements this behavior: In [240]: a Out[240]: array([[ 0, 1, 2], [ 3, 4, 5], [ 6, 7, 8], [ 9, 10, 11], [12, 13, 14]]) In [241]: disarrange(a, axis=0) In [242]: a Out[242]: array([[ 6, 1, 2], [ 3, 13, 14], [ 9, 10, 5], [12, 7, 8], [ 0, 4, 11]]) Note that each column has been shuffled independently. This behavior is analogous to how `sort` handles the `axis` keyword. `sort` sorts the 1-d slices along the given axis independently. In the github issue, I suggested the following signature for `shuffle` (but I'm not too fond of the name `independent`): def shuffle(a, independent=False, axis=0) If `independent` is False, the current behavior of `shuffle` is used. If `independent` is True, each 1-d slice is shuffled independently (in the same way that `sort` sorts each 1-d slice). Like most functions that take an `axis` argument, `axis=None` means to shuffle the flattened array. With `independent=True`, it would act like `np.random.shuffle(a.flat)`, e.g. In [247]: a Out[247]: array([[ 0, 1, 2, 3, 4], [ 5, 6, 7, 8, 9], [10, 11, 12, 13, 14]]) In [248]: np.random.shuffle(a.flat) In [249]: a Out[249]: array([[ 0, 14, 9, 1, 13], [ 2, 8, 5, 3, 4], [ 6, 10, 7, 12, 11]]) A small wart in this API is the meaning of shuffle(a, independent=False, axis=None) It could be argued that the correct behavior is to leave the array unchanged. (The current behavior can be interpreted as shuffling a 1-d sequence of monolithic blobs; the axis argument specifies which axis of the array corresponds to the sequence index. Then `axis=None` means the argument is a single monolithic blob, so there is nothing to shuffle.) Or an error could be raised. What do you think? Warren

10 25

Instaling numpy without root access
by Lahiru Samarakoon Oct. 17, 2014

Oct. 17, 2014

Dear all, I am trying to install numpy without root access. So I am building from the source. I have installed atlas which also has lapack with it. I changed the site.cfg file as given below [DEFAULT] library_dirs = /home/svu/a0095654/ATLAS/build/lib include_dirs = /home/svu/a0095654/ATLAS/build/include However, I am getting a segmentation fault when importing numpy. Please advise. I also put the build log file at the end of the email if necessary. Thank you, Best Regards, Lahiru Log starts below. * python2.7 setup.py build --fcompiler=gnu95* Running from numpy source directory. /home/svu/a0095654/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'test_suite' warnings.warn(msg) non-existing path in 'numpy/f2py': 'docs' non-existing path in 'numpy/f2py': 'f2py.1' F2PY Version 2 blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in ['/home/svu/a0095654/ATLAS/build/lib'] NOT AVAILABLE openblas_info: libraries openblas not found in ['/home/svu/a0095654/ATLAS/build/lib'] NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS Setting PTATLAS=ATLAS customize Gnu95FCompiler Found executable /usr/bin/gfortran customize Gnu95FCompiler customize Gnu95FCompiler using config compiling '_configtest.c': /* This file is generated from numpy/distutils/system_info.py */ void ATL_buildinfo(void); int main(void) { ATL_buildinfo(); return 0; } C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/home/svu/a0095654/ATLAS/build/install/lib -lptf77blas -lptcblas -latlas -o _configtest _configtest.o: In function `main': /hpctmp/a0095654/Software/numpy-1.9.0/_configtest.c:5: undefined reference to `ATL_buildinfo' collect2: ld returned 1 exit status _configtest.o: In function `main': /hpctmp/a0095654/Software/numpy-1.9.0/_configtest.c:5: undefined reference to `ATL_buildinfo' collect2: ld returned 1 exit status failure. removing: _configtest.c _configtest.o Status: 255 Output: compiling '_configtest.c': /* This file is generated from numpy/distutils/system_info.py */ void ATL_buildinfo(void); int main(void) { ATL_buildinfo(); return 0; } C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/home/svu/a0095654/ATLAS/build/install/lib -lptf77blas -lptcblas -latlas -o _configtest _configtest.o: In function `main': /hpctmp/a0095654/Software/numpy-1.9.0/_configtest.c:5: undefined reference to `ATL_buildinfo' collect2: ld returned 1 exit status Setting PTATLAS=ATLAS FOUND: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/svu/a0095654/ATLAS/build/install/lib'] language = c define_macros = [('ATLAS_INFO', '"\\"None\\""')] FOUND: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/svu/a0095654/ATLAS/build/install/lib'] language = c define_macros = [('ATLAS_INFO', '"\\"None\\""')] non-existing path in 'numpy/lib': 'benchmarks' lapack_opt_info: openblas_lapack_info: libraries openblas not found in ['/home/svu/a0095654/ATLAS/build/lib'] NOT AVAILABLE lapack_mkl_info: mkl_info: libraries mkl,vml,guide not found in ['/home/svu/a0095654/ATLAS/build/lib'] NOT AVAILABLE NOT AVAILABLE atlas_threads_info: Setting PTATLAS=ATLAS libraries lapack_atlas not found in /home/svu/a0095654/ATLAS/build/install/lib numpy.distutils.system_info.atlas_threads_info Setting PTATLAS=ATLAS /hpctmp/a0095654/Software/numpy-1.9.0/numpy/distutils/system_info.py:1095: UserWarning: ********************************************************************* Lapack library (from ATLAS) is probably incomplete: size of /home/svu/a0095654/ATLAS/build/install/lib/liblapack.so is 5.0673828125k (expected >4000k) Follow the instructions in the KNOWN PROBLEMS section of the file numpy/INSTALL.txt. ********************************************************************* warnings.warn(message) Setting PTATLAS=ATLAS FOUND: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/svu/a0095654/ATLAS/build/install/lib'] language = c define_macros = [('ATLAS_INFO', '"\\"None\\""')] FOUND: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/svu/a0095654/ATLAS/build/install/lib'] language = c define_macros = [('ATLAS_INFO', '"\\"None\\""')] /home/svu/a0095654/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'define_macros' warnings.warn(msg) running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src build_src building py_modules sources building library "npymath" sources customize Gnu95FCompiler customize Gnu95FCompiler using config C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/home/svu/a0095654/include/python2.7 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/home/svu/a0095654/include/python2.7 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function ‘exp’ gcc -pthread _configtest.o -o _configtest _configtest.o: In function `main': /hpctmp/a0095654/Software/numpy-1.9.0/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status _configtest.o: In function `main': /hpctmp/a0095654/Software/numpy-1.9.0/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status failure. removing: _configtest.c _configtest.o C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/home/svu/a0095654/include/python2.7 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function ‘exp’ gcc -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest building library "npysort" sources adding 'build/src.linux-x86_64-2.7/numpy/core/src/private' to include_dirs. None - nothing done with h_files = ['build/src.linux-x86_64-2.7/numpy/core/src/private/npy_partition.h', 'build/src.linux-x86_64-2.7/numpy/core/src/private/npy_binsearch.h'] building extension "numpy.core._dummy" sources adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h' to sources. adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h' to sources. numpy.core - nothing done with h_files = ['build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h'] building extension "numpy.core.multiarray" sources adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h' to sources. adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h' to sources. numpy.core - nothing done with h_files = ['build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h'] building extension "numpy.core.umath" sources adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h' to sources. adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_ufunc_api.py adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__ufunc_api.h' to sources. adding 'build/src.linux-x86_64-2.7/numpy/core/src/umath' to include_dirs. numpy.core - nothing done with h_files = ['build/src.linux-x86_64-2.7/numpy/core/src/umath/funcs.inc', 'build/src.linux-x86_64-2.7/numpy/core/src/umath/simd.inc', 'build/src.linux-x86_64-2.7/numpy/core/src/umath/loops.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__ufunc_api.h'] building extension "numpy.core.scalarmath" sources adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h' to sources. adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h' to sources. executing numpy/core/code_generators/generate_ufunc_api.py adding 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__ufunc_api.h' to sources. adding 'build/src.linux-x86_64-2.7/numpy/core/src/private' to include_dirs. numpy.core - nothing done with h_files = ['build/src.linux-x86_64-2.7/numpy/core/src/private/scalarmathmodule.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h', 'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__ufunc_api.h'] building extension "numpy.core._dotblas" sources adding 'numpy/core/blasdot/_dotblas.c' to sources. building extension "numpy.core.umath_tests" sources building extension "numpy.core.test_rational" sources building extension "numpy.core.struct_ufunc_test" sources building extension "numpy.core.multiarray_tests" sources building extension "numpy.core.operand_flag_tests" sources building extension "numpy.lib._compiled_base" sources building extension "numpy.fft.fftpack_lite" sources building extension "numpy.linalg.lapack_lite" sources adding 'numpy/linalg/lapack_litemodule.c' to sources. adding 'numpy/linalg/lapack_lite/python_xerbla.c' to sources. building extension "numpy.linalg._umath_linalg" sources adding 'numpy/linalg/umath_linalg.c.src' to sources. adding 'numpy/linalg/lapack_lite/python_xerbla.c' to sources. building extension "numpy.random.mtrand" sources C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/home/svu/a0095654/include/python2.7 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest _configtest failure. removing: _configtest.c _configtest.o _configtest building data_files sources build_src: building npy-pkg config files running build_py copying numpy/version.py -> build/lib.linux-x86_64-2.7/numpy copying build/src.linux-x86_64-2.7/numpy/__config__.py -> build/lib.linux-x86_64-2.7/numpy copying build/src.linux-x86_64-2.7/numpy/distutils/__config__.py -> build/lib.linux-x86_64-2.7/numpy/distutils running build_clib customize UnixCCompiler customize UnixCCompiler using build_clib building 'npymath' library compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.7 creating build/temp.linux-x86_64-2.7/build creating build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7 creating build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/numpy creating build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/numpy/core creating build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/numpy/core/src creating build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/numpy/core/src/npymath creating build/temp.linux-x86_64-2.7/numpy creating build/temp.linux-x86_64-2.7/numpy/core creating build/temp.linux-x86_64-2.7/numpy/core/src creating build/temp.linux-x86_64-2.7/numpy/core/src/npymath compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/home/svu/a0095654/include/python2.7 -Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -c' gcc: numpy/core/src/npymath/halffloat.c gcc: build/src.linux-x86_64-2.7/numpy/core/src/npymath/ieee754.c gcc: build/src.linux-x86_64-2.7/numpy/core/src/npymath/npy_math.c gcc: build/src.linux-x86_64-2.7/numpy/core/src/npymath/npy_math_complex.c ar: adding 4 object files to build/temp.linux-x86_64-2.7/libnpymath.a building 'npysort' library compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/numpy/core/src/npysort compile options: '-Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -Inumpy/core/include -Ibuild/src.linux-x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/home/svu/a0095654/include/python2.7 -Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -Ibuild/src.linux-x86_64-2.7/numpy/core/src/private -c' gcc: build/src.linux-x86_64-2.7/numpy/core/src/npysort/selection.c gcc: build/src.linux-x86_64-2.7/numpy/core/src/npysort/quicksort.c gcc: build/src.linux-x86_64-2.7/numpy/core/src/npysort/mergesort.c gcc: build/src.linux-x86_64-2.7/numpy/core/src/npysort/binsearch.c gcc: build/src.linux-x86_64-2.7/numpy/core/src/npysort/heapsort.c ar: adding 5 object files to build/temp.linux-x86_64-2.7/libnpysort.a running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext running build_scripts adding 'build/scripts.linux-x86_64-2.7/f2py2.7' to scripts

3 6

Passing multiple output arguments to ufunc
by Jaime Fernández del Río Oct. 17, 2014

Oct. 17, 2014

There is an oldish feature request in github (https://github.com/numpy/numpy/issues/4752), complaining about it not being possible to pass multiple output arguments to a ufunc using keyword arguments. You can pass them all as positional arguments: >>> out1 = np.empty(1) >>> out2 = np.empty(1) >>> np.modf([1.333], out1, out2) (array([ 0.333]), array([ 1.])) You can also pass the first as a kwarg if you leave the others unspecified: >>> np.modf([1.333], out=out1) (array([ 0.333]), array([ 1.])) You can also use None in a positional argument to leave some of the output arguments unspecified: >>> np.modf([1.3333], None, out2) (array([ 0.3333]), array([ 1.])) But you cannot do something like >>> np.modf([1.333], out=(out1, out2)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: return arrays must be of ArrayType Would this behavior make sense? The idea would be to allow a tuple as a valid input for the 'out=' kwarg. It would have to have a length exactly matching the number of output arguments, and its items would have to be either arrays or None. For backwards compatibility we probably should still allow a single array to mean the first output argument, even if the ufunc has multiple outputs. Any other thoughts? Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

1 0