Mailman 3 October 2014 - NumPy-Discussion

Accept numpy arrays on arguments of numpy.testing.assert_approx_equal()
by Edison Gustavo Muenz Oct. 27, 2014

Oct. 27, 2014

I’ve implemented support for numpy.arrays for the arguments of numpy.testing.assert_approx_equal() and have issued a pull-request <https://github.com/numpy/numpy/pull/5219> on Github. I don’t know if I should be sending the message to the list to notify about this, but since I’m new to the *numpy-dev* list I think it never hurts to say hi :)

1 0

higher accuracy in diagonialzation
by Sunghwan Choi Oct. 27, 2014

Oct. 27, 2014

Dear all, I am now diagonalizing a 200-by-200 symmetric matrix. But the two methods, scipy.linalg.eigh and numpy.linalg.eigh give significantly different result. The results from two methods are different within 10^-4 order. One of them is inaccurate or both two of them are inaccurate within that range. Which one is more accurate? or Are there any ways to control the accuracy for diagonalization? If you have some idea please let me know. Sunghwan Choi Ph. D. candidator Department of Chemistry KAIST (South Korea)

3 2

ANN: NumPy 1.9.1 release candidate
by Julian Taylor Oct. 27, 2014

Oct. 27, 2014

Hi, We have finally finished the first release candidate of NumOy 1.9.1, sorry for the week delay. The 1.9.1 release will as usual be a bugfix only release to the 1.9.x series. The tarballs and win32 binaries are available on sourceforge: https://sourceforge.net/projects/numpy/files/NumPy/1.9.1rc1/ If no regressions show up the final release is planned next week. The upgrade is recommended for all users of the 1.9.x series. Following issues have been fixed: * gh-5184: restore linear edge behaviour of gradient to as it was in < 1.9. The second order behaviour is available via the `edge_order` keyword * gh-4007: workaround Accelerate sgemv crash on OSX 10.9 * gh-5100: restore object dtype inference from iterable objects without `len()` * gh-5163: avoid gcc-4.1.2 (red hat 5) miscompilation causing a crash * gh-5138: fix nanmedian on arrays containing inf * gh-5203: copy inherited masks in MaskedArray.__array_finalize__ * gh-2317: genfromtxt did not handle filling_values=0 correctly * gh-5067: restore api of npy_PyFile_DupClose in python2 * gh-5063: cannot convert invalid sequence index to tuple * gh-5082: Segmentation fault with argmin() on unicode arrays * gh-5095: don't propagate subtypes from np.where * gh-5104: np.inner segfaults with SciPy's sparse matrices * gh-5136: Import dummy_threading if importing threading fails * gh-5148: Make numpy import when run with Python flag '-OO' * gh-5147: Einsum double contraction in particular order causes ValueError * gh-479: Make f2py work with intent(in out) * gh-5170: Make python2 .npy files readable in python3 * gh-5027: Use 'll' as the default length specifier for long long * gh-4896: fix build error with MSVC 2013 caused by C99 complex support * gh-4465: Make PyArray_PutTo respect writeable flag * gh-5225: fix crash when using arange on datetime without dtype set * gh-5231: fix build in c99 mode Source tarballs, windows installers and release notes can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.9.1rc1/ Cheers, Julian Taylor

2 1

Subdividing NumPy array into Regular Grid
by Artur Bercik Oct. 27, 2014

Oct. 27, 2014

I have a rectangle with the following coordinates: import numpy as np ulx,uly = (110, 60) ##uppper left lon, upper left lat urx,ury = (120, 60) ##uppper right lon, upper right lat lrx, lry = (120, 50) ##lower right lon, lower right lat llx, lly = (110, 50) ##lower left lon, lower left lat I want to divide that single rectangle into 100 regular grids inside that, and want to calculate the (ulx, uly), (urx,ury), (lrx, lry), and (llx, lly) for each grid separately: lats = np.linspace(60, 50, 10) lons = np.linspace(110, 120, 10) lats = np.repeat(lats,10).reshape(10,10) lons = np.tile(lons,10).reshape(10,10) I could not imagine what to do then? Is somebody familiar with such kind of problem?

2 1

Re: [Numpy-discussion] Memory efficient alternative for np.loadtxt and np.genfromtxt
by RayS Oct. 26, 2014

Oct. 26, 2014

At 06:32 AM 10/26/2014, you wrote: >On Sun, Oct 26, 2014 at 1:21 PM, Eelco Hoogendoorn ><hoogendoorn.eelco(a)gmail.com> wrote: > > Im not sure why the memory doubling is necessary. Isnt it possible to > > preallocate the arrays and write to them? > >Not without reading the whole file first to know how many rows to preallocate Seems to me that loadtxt() http://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html should have an optional shape. I often know how many rows I have (# of samples of data) from other meta data. Then: - if the file is smaller for some reason (you're not sure and pad your estimate) it could do one of - zero pad array - raise() - return truncated view - if larger - raise() - return data read (this would act like fileObject.read( size ) ) - Ray S

1 0

Re: [Numpy-discussion] Memory efficient alternative for np.loadtxt and np.genfromtxt
by Saullo Castro Oct. 26, 2014

Oct. 26, 2014

I agree with @Daniele's point, storing huge arrays in text files migh indicate a bad process.... but once these functions can be improved, why not? Unless this turns to be a burden to change. Regarding the estimation of the array size, I don't see a big performance loss when the file iterator is exhausting once more in order to estimate the number of rows and pre-allocate the proper arrays to avoid using list of lists. The hardest part seems to be dealing with arrays of strings (perhaps easily solved with dtype=object) and structured arrays. Cheers, Saullo 2014-10-26 18:00 GMT+01:00 <numpy-discussion-request(a)scipy.org>: > Send NumPy-Discussion mailing list submissions to > numpy-discussion(a)scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/numpy-discussion > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)scipy.org > > You can reach the person managing the list at > numpy-discussion-owner(a)scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NumPy-Discussion digest..." > > > Today's Topics: > > 1. Re: Memory efficient alternative for np.loadtxt and > np.genfromtxt (Daniele Nicolodi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Oct 2014 17:42:32 +0100 > From: Daniele Nicolodi <daniele(a)grinta.net> > Subject: Re: [Numpy-discussion] Memory efficient alternative for > np.loadtxt and np.genfromtxt > To: numpy-discussion(a)scipy.org > Message-ID: <544D2478.8020504(a)grinta.net> > Content-Type: text/plain; charset=windows-1252 > > On 26/10/14 09:46, Saullo Castro wrote: > > I would like to start working on a memory efficient alternative for > > np.loadtxt and np.genfromtxt that uses arrays instead of lists to store > > the data while the file iterator is exhausted. > > ... > > > I would be glad if you could share your experience on this matter. > > I'm of the opinion that if your workflow requires you to regularly load > large arrays from text files, something else needs to be fixed rather > than the numpy speed and memory usage in reading data from text files. > > There are a number of data formats that are interoperable and allow to > store data much more efficiently. hdf5 is one natural choice, maybe with > the blosc compressor. > > Cheers, > Daniele > > > > ------------------------------ > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion(a)scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > End of NumPy-Discussion Digest, Vol 97, Issue 57 > ************************************************ >

1 0

npy_log2 undefined on Linux
by Matthew Brett Oct. 26, 2014

Oct. 26, 2014

Hi, We (dipy developers) have a hit a new problem trying to use the ``npy_log`` C function in our code. Specifically, on Linux, but not on Mac or Windows, we are getting errors of form: ImportError: /path/to/extension/distances.cpython-34m.so: undefined symbol: npy_log2 when compiling something like: <eg_log.pyx> import numpy as np cimport numpy as cnp cdef extern from "numpy/npy_math.h" nogil: double npy_log(double x) def use_log(double val): return npy_log(val) </eg_log.pyx> See : https://github.com/matthew-brett/mincy/tree/npy_log_example for a self-contained example that replicates the failure with ``make``. I guess this means that the code referred to by ``npy_log`` is not on the ordinary runtime path on Linux? What should I do next to debug? Thanks a lot, Matthew

2 4

segfault in np.arange
by Dave Hirschfeld Oct. 24, 2014

Oct. 24, 2014

Hi, I accidentally passed a pandas DatetimeIndex to `np.arange` which caused it to segfault. It's a pretty dumb thing to do but I don't think it should cause a segfault! Python 2.7.5 |Continuum Analytics, Inc.| (default, Jul 1 2013, 12:37:52) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. #>>> import faulthandler #>>> faulthandler.enable() #>>> import numpy as np #>>> np.__version__ '1.9.0' #>>> import pandas as pd #>>> pd.__version__ '0.14.1' #>>> np.arange(pd.DatetimeIndex([])) Fatal Python error: Segmentation fault Current thread 0x00001d18: File "<stdin>", line 1 in <module> The exception dialog which pops up contains the following information: Unhandled exception at 0x000000000255EB49 (multiarray.pyd) in python.exe: 0xC0000005: Access violation reading location 0x0000000000000008. Thanks, Dave

2 2

Re: [Numpy-discussion] successful Windows x64 build with acml-5.3.1 ifort64 static libs passes tests
by Mark Mikofski Oct. 24, 2014

Oct. 24, 2014

AMD acml libraries do not include the CBLAS implementation. To build CBLAS against the libacml.lib requires the Intel Fortran compiler. There is a note in the mailing list here http://mail.scipy.org/pipermail/numpy-discussion/2006-February/018379.html This detail should probably be added to the new wiki, but in general it means that the AMD acml is not a drop in library

1 0

successful Windows x64 build with acml-5.3.1 ifort64 static libs passes tests
by Mark Mikofski Oct. 23, 2014

Oct. 23, 2014

Both the /MT and /MD versions of the acml static libraries build, and pass all tests, except that for me at least there's a weird glitch in the build process. I have to purposefully add something so that config fails. EG: In the previous site.cfg, I did not realize that I had mistyped the vector math libraries as libsvml_disp.lib instead of svml_disp.lib. In fact you don't even need those libraries. Here I use the /MT version of the static libs, but add a dummy lib, "_". Config says NOT AVAILABLE for everything, but the build and install work fine. [blas] blas_libs = libacml, libifcoremt, libifport, libirc, libircmt, libmmt, svml_disp, svml_dispmt, _ library_dirs = C:\AMD\acml5.3.1\ifort64\lib\MT include_dirs = C:\AMD\acml5.3.1\ifort64\include [lapack] lapack_libs = libacml, libifcoremt, libifport, libirc, libircmt, libmmt, svml_disp, svml_dispmt, _ library_dirs = C:\AMD\acml5.3.1\ifort64\lib\MT include_dirs = C:\AMD\acml5.3.1\ifort64\include If I try to run the build without the dummy ("_"), then I get a traceback that says that lapack libs with appended underscores are unresolved. I think in the static library and the acml header file the c-wrappers remove the fortran underscore. Also I am using the Intel fortran built libs which I think use ALL CAPS not trailing underscores. I think this is the trailing underscore import issue, covered in this article: http://developer.amd.com/community/blog/2009/06/29/removing-c-wrapper-funct… Adding the dummy lib somehow sets the NO_APPEND_FORTRAN macro. Also it seems like the [amd] section in site.cfg does nothing. Also it doesn't matter if I change the library names to remove the lib- prefix, or if I rename the lib and header from acml to amd, makes no difference. THe only reference to AMD/ACML is http://wiki.scipy.org/Installing_SciPy/Windows but this site seems out of date, and in contradiction to other building scipy site that supports MKL out of the box.

1 1

Re: [Numpy-discussion] MKL not available as separate download since 10/16/2014
by Mark Mikofski Oct. 23, 2014

Oct. 23, 2014

Michael, Thanks for your response. The Intel Math Kernel Library package with just the static and dynamic libraries for blas, lapack (similar to AMD's acml self extracting zip file) is what I think many Windows users were depending on to build Python's numerical and scientific libraries (numpy and scipy). If it could be made available that would be very welcomed. Currently the only remaining option is AMD's acml here: http://developer.amd.com/tools-and-sdks/cpu-development/amd-core-math-libra… which passes all tests. Currently it is unfortunate that the Intel MKL website has instructions for building numpy and scipy here: https://software.intel.com/en-us/articles/numpyscipy-with-intel-mkland numpy/scipy has them here: http://www.scipy.org/scipylib/building/windows.html#building-numpy-with-the… but you can no longer download the MKL files. Thanks for your help! --Mark

1 0

Fwd: [julia-dev] OpenBLAS machines
by Fernando Perez Oct. 23, 2014

Oct. 23, 2014

Not sure if folks saw this one... Might be interesting to contact this team from the python side of things. Cheers f ---------- Forwarded message ---------- From: Zhang Xianyi <traits.zhang(a)gmail.com> Date: Sun, Oct 19, 2014 at 12:50 AM Subject: [julia-dev] OpenBLAS machines To: Julia Dev <julia-dev(a)googlegroups.com> Hi Julia developers, The OpenBLAS team deployed the following machines to support developing and testing the project. We like to share the machines with Julia developers. The interested developer can apply the remote access by sending the mail to OpenBLAS-dev mailing list <https://groups.google.com/forum/#!forum/openblas-dev> or traits.zhang(a)gmail.com. - 2-way Intel Xeon E5-2680 (2.7GHz, Intel Sandy Bridge), 32GB memory, 1TB hard disk, Ubuntu 14.04 64-bit. - 1-way Intel Core i7-4770 (3.4GHz, Intel Haswell), 8GB memory, 512GB hard disk, Ubuntu 14.04 64-bit. - 1-way AMD FX-8320 (3.5GHz, AMD Piledriver), 8GB memory, 512GB hard disk, Ubuntu 14.04 64-bit. - Odroid-U2 board <http://www.hardkernel.com/main/products/prdt_info.php?g_code=G135341370451>. 1-way Exynos4412 Prime 1.7Ghz ARM Cortex-A9 Quad Cores, 2GB memory, 16GB SD card, Ubuntu 14.04 32-bit. The AMD HSA Apu (Kaveri) machine and Intel KNC MIC are coming soon. Xianyi -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail

1 0

successful Windows x64 build with acml-5.3.1 ifort64 static libs passes tests
by Mark Mikofski Oct. 22, 2014

Oct. 22, 2014

* Either windows sdk 7 or ms visual studio 2008 is required, however Fortran compilers are not.* Download acml5.3.1-ifort64.exe from http://developer.amd.com/tools-and-sdks/cpu-development/amd-core-math-libra… and it extracts to c:\AMD\acml5.3.1 * NOTE: There is also a newer acml-6.0.6.17-ifort64 update but it only includes dynamic libraries which depend on msvcr110 (visual studio 2013). * NOTE: There are several other optional libs incl. ifort64-mt, ifort64-fma4, ifort64-mp and ifort64-fma4-mp* System info: Windows-7 (64bit), python-2.7.6, numpy-1.9.0, virtualenv-1.11.5, nose-1.3.4* create site.cfg with: [amd]amd_libs = libacml, libifcoremd, libifportmd, libirc, libmmd, libsvml_disp, libsvml_dispmdlibrary_dirs = C:\AMD\acml5.3.1\ifort64\libinclude_dirs = C:\AMD\acml5.3.1\ifort64\include[blas]blas_libs = libacml, libifcoremd, libifportmd, libirc, libmmd, libsvml_disp, libsvml_dispmdlibrary_dirs = C:\AMD\acml5.3.1\ifort64\libinclude_dirs = C:\AMD\acml5.3.1\ifort64\include[lapack]lapack_libs = libacml, libifcoremd, libifportmd, libirc, libmmd, libsvml_disp, libsvml_dispmdlibrary_dirs = C:\AMD\acml5.3.1\ifort64\libinclude_dirs = C:\AMD\acml5.3.1\ifort64\include * activate virtualenv and inside extracted numpy-1.9.0 folder find setup.py and run it with the following commands (venv) numpy-1.9.0/numpy-1.9.0 $python setup.py config --compiler=msvc * start python, import numpy and run numpy.test()Ran 5458 tests in 29.346s OK (KNOWNFAIL=10, SKIP=18)<nose.result.TextTestResult run=5458 errors=0 failures=0> “As I breath in, I calm my body, as I breath out, I smile” - Thich_Nhat_Hanh

1 0

Bug in 1.9?
by Neil Girdhar Oct. 22, 2014

Oct. 22, 2014

Hello, Is this desired behaviour or a regression or a bug? http://stackoverflow.com/questions/26497656/how-do-i-align-a-numpy-record-a… Thanks, Neil

3 3

numpy log and exceptions
by Daniel Hyams Oct. 22, 2014

Oct. 22, 2014

I would have thought that this snippet would raise an exception: import numpy numpy.seterr(all='raise') a = numpy.array([1.0,0.0,-1.0]) b = numpy.log(a) I get as a result (in b): [0, -Inf, NaN] It's basically the same issue as: http://numpy-discussion.10968.n7.nabble.com/numpy-log-does-not-raise- exceptions-td5854.html Except that I have explicitly set the error flags to raise exceptions. It works fine for sqrt(), but not for log(). I've checked numpy 1.4.0 and 1.7.1 and both have the same behavior. Is there a way to force the log (and log10) function to raise an exception on invalid input?

4 5

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