Mailman 3 October 2015 - NumPy-Discussion

msvc9 comipiler problems
by Charles R Harris 09 Oct '15

09 Oct '15

Hi All, There is a compilation problem <https://github.com/numpy/numpy/issues/6428>with 1.10.0 on 32 bit windows using the msvc9 compiler. One possible solution to this is to drop support for python 2.6. The last, and final, release of of that series was Python 2.6.9 in Oct 2013. The first release was in 2008. Thoughts? Chuck

4 4

Oops - maybe post3 numpy file?
by Matthew Brett 09 Oct '15

09 Oct '15

Hi, I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error: Error processing form This filename has previously been used, you should use a different version. Any chance of a post3 upload so I can upload some matching wheels? Sorry about that, Matthew

5 11

ANN: pandas v0.17.0 released
by Jeff Reback 09 Oct '15

09 Oct '15

Hi, We are proud to announce v0.17.0 of pandas. This is a major release from 0.16.2 and includes a small number of API changes, several new features, enhancements, and performance improvements along with a large number of bug fixes. We recommend that all users upgrade to this version. This was a release of 4 months with 515 commits by 112 authors encompassing 233 issues and 362 pull-requests. We recommend that all users upgrade to this version. *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. *Highlights*: - Release the Global Interpreter Lock (GIL) on some cython operations, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - Plotting methods are now available as attributes of the .plot accessor, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - The sorting API has been revamped to remove some long-time inconsistencies, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - Support for a datetime64[ns] with timezones as a first-class dtype, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - The default for to_datetime will now be to raise when presented with unparseable formats, previously this would return the original input, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - The default for dropna in HDFStore has changed to False, to store by default all rows even if they are all NaN, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - Support for Series.dt.strftime to generate formatted strings for datetime-likes, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - Development installed versions of pandas will now have PEP440 compliant version strings GH9518 <https://github.com/pydata/pandas/issues/9518> - Development support for benchmarking with the Air Speed Velocity library GH8316 <https://github.com/pydata/pandas/pull/8316> - Support for reading SAS xport files, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - Removal of the automatic TimeSeries broadcasting, deprecated since 0.8.0, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - Display format with plain text can optionally align with Unicode East Asian Width, see here <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html#whatsnew-…> - Compatibility with Python 3.5 GH11097 <https://github.com/pydata/pandas/issues/11097> - Compatibility with matplotlib 1.5.0 GH11111 <https://github.com/pydata/pandas/issues/11111> See the Whatsnew <http://pandas.pydata.org/pandas-docs/version/0.17.0/whatsnew.html> for much more information and the full Documentation <http://pandas.pydata.org/pandas-docs/stable/> link. *How to get it:* Source tarballs, windows wheels, macosx wheels are available on PyPI <https://pypi.python.org/pypi/pandas> - note that currently PyPi is not accepting 3.5 wheels. Installation via conda is: - conda install pandas windows wheels are courtesy of Christoph Gohlke and are built on Numpy 1.9 macosx wheels are courtesy of Matthew Brett *Issues:* Please report any issues on our issue tracker <https://github.com/pydata/pandas/issues>: Thanks to all who made this release happen. It is a very large release! Jeff *Thanks to all of the contributors* - Alex Rothberg - Andrea Bedini - Andrew Rosenfeld - Andy Li - Anthonios Partheniou - Artemy Kolchinsky - Bernard Willers - Charlie Clark - Chris - Chris Whelan - Christoph Gohlke - Christopher Whelan - Clark Fitzgerald - Clearfield Christopher - Dan Ringwalt - Daniel Ni - Data & Code Expert Experimenting with Code on Data - David Cottrell - David John Gagne - David Kelly - ETF - Eduardo Schettino - Egor - Egor Panfilov - Evan Wright - Frank Pinter - Gabriel Araujo - Garrett-R - Gianluca Rossi - Guillaume Gay - Guillaume Poulin - Harsh Nisar - Ian Henriksen - Ian Hoegen - Jaidev Deshpande - Jan Rudolph - Jan Schulz - Jason Swails - Jeff Reback - Jonas Buyl - Joris Van den Bossche - Joris Vankerschaver - Josh Levy-Kramer - Julien Danjou - Ka Wo Chen - Karrie Kehoe - Kelsey Jordahl - Kerby Shedden - Kevin Sheppard - Lars Buitinck - Leif Johnson - Luis Ortiz - Mac - Matt Gambogi - Matt Savoie - Matthew Gilbert - Maximilian Roos - Michelangelo D'Agostino - Mortada Mehyar - Nick Eubank - Nipun Batra - Ondřej Čertík - Phillip Cloud - Pratap Vardhan - Rafal Skolasinski - Richard Lewis - Rinoc Johnson - Rob Levy - Robert Gieseke - Safia Abdalla - Samuel Denny - Saumitra Shahapure - Sebastian Pölsterl - Sebastian Rubbert - Sheppard, Kevin - Sinhrks - Siu Kwan Lam - Skipper Seabold - Spencer Carrucciu - Stephan Hoyer - Stephen Hoover - Stephen Pascoe - Terry Santegoeds - Thomas Grainger - Tjerk Santegoeds - Tom Augspurger - Vincent Davis - Winterflower - Yaroslav Halchenko - Yuan Tang (Terry) - agijsberts - ajcr - behzad nouri - cel4 - cyrusmaher - davidovitch - ganego - jreback - juricast - larvian - maximilianr - msund - rekcahpassyla - robertzk - scls19fr - seth-p - sinhrks - springcoil - terrytangyuan - tzinckgraf

1 0

Should we allow arrays with "empty string" dtypes?
by Erik Bray 09 Oct '15

09 Oct '15

Hi all, This is a post about strings--for the purpose of discussion then I'll be assuming Python 2 and string means non-unicode strings. However, the discussion applies all the same to unicode strings. For a long time Numpy has had the following behavior: When creating an array with a zero-width string dtype like 'S0', Numpy automatically increases the width of the dtype to support the longest string in the input, like so: >>> np.array(['abc', 'de'], dtype='S0') # or equivalently dtype=str array(['abc', 'de'], dtype='|S3') But it *always* converts to a one character string dtype, at a minimum. So even when passing in a list of empty strings: >>> np.array(['', '', ''], dtype='S0') array(['', '', ''], dtype='|S1') Or even >>> np.zeros(3, dtype='S0') array(['', '', ''], dtype='|S1') This behavior is encoded in PyArray_NewFromDescr_int [1] and is very old (since 2006) [2]. This made sense at the time, certainly, since the logic for handling zero-sized strides was shaky, but most issues with that have long since been worked out. However, there's an oversight associated with this that it *is* possible to make a structured dtype that has a zero-width string as one of its fields. But since even PyArray_View goes through PyArray_NewFromDescr, viewing such a field results in a non-empty view that contains garbage and allows writing garbage into a structured array. This is documented in several issues, such as #473 [3]. A fixed I've proposed in #6430 [4] takes a conservative approach of keeping all the existing behavior *except* in the case of structured arrays, where views with a dtype of 'S0' would be allowed. However, a simpler fix would be to just remove the restriction on creating arrays of dtype 'S0' in general (with my first example above being one exception--given a list of strings it will still convert 'S0' to a dtype that can hold the longest string in the list). I think I would prefer the general fix, but it would be a slight change in behavior for any code using PyArray_NewFromDescr to create string arrays. But would anyone actually be negatively impacted by such a change? It seems to me that any code actually relies on the existing behavior would smell fishy anyways. Thanks, Erik [1] https://github.com/numpy/numpy/blob/8cb3ec6ab804f594daf553e53e7cf7478656beb… [2] https://github.com/numpy/numpy/commit/b022765aa487070866663b1707e4a2a0d8ead… [3] https://github.com/numpy/numpy/issues/473 [4] https://github.com/numpy/numpy/pull/6430

1 0

reorganizing numpy internal extensions (was: Re: Should we drop support for "one file" compilation mode?)
by Nathaniel Smith 09 Oct '15

09 Oct '15

[splitting this off into a new thread] On Tue, Oct 6, 2015 at 3:00 AM, David Cournapeau <cournape(a)gmail.com> wrote: [...] > I also agree the current situation is not sustainable -- as we discussed > privately before, cythonizing numpy.core is made quite more complicated by > this. I have myself quite a few issues w/ cythonizing the other parts of > umath. I would also like to support the static link better than we do now > (do we know some static link users we can contact to validate our approach > ?) > > Currently, what we have in numpy core is the following: > > numpy.core.multiarray -> compilation units in numpy/core/src/multiarray/ + > statically link npymath > numpy.core.umath -> compilation units in numpy/core/src/umath + statically > link npymath/npysort + some shenanigans to use things in > numpy.core.multiarray There are also shenanigans in the other direction - supposedly umath is layered "above" multiarray, but in practice there are circular dependencies (see e.g. np.set_numeric_ops). > I would suggest to have a more layered approach, to enable both 'normal' > build and static build, without polluting the public namespace too much. > This is an approach followed by most large libraries (e.g. MKL), and is > fairly flexible. > > Concretely, we could start by putting more common functionalities (aka the > 'core' library) into its own static library. The API would be considered > private to numpy (no stability guaranteed outside numpy), and every exported > symbol from that library would be decorated appropriately to avoid potential > clashes (e.g. '_npy_internal_'). I don't see why we need this multi-layered complexity, though. npymath is a well-defined utility library that other people use, so sure, it makes sense to keep that somewhat separate as a static library (as discussed in the other thread). Beyond that -- NumPy is really not a large library. multiarray is <50k lines of code, and umath is only ~6k (!). And there's no particular reason to keep them split up from the user point of view -- all their functionality gets combined into the flat numpy namespace anyway. So we *could* rewrite them as three libraries, with a "common core" that then gets exported via two different wrapper libraries -- but it's much simpler just to do mv umath/* multiarray/ rmdir umath and then make multiarray work the way we want. (After fixing up the build system of course :-).) -n -- Nathaniel J. Smith -- http://vorpus.org

5 10

Should we drop support for "one file" compilation mode?
by Nathaniel Smith 08 Oct '15

08 Oct '15

Hi all, For a long time, NumPy has supported two different ways of being compiled: "Separate compilation" mode: like most C projects, each .c file gets compiled to a .o file, and then the .o files get linked together to make a shared library. (This has been the default since 1.8.0.) "One file" mode: first concatenate all the .c files together to make one monster .c file, and then compile that .c file to make a shared library. (This was the default before 1.8.0.) Supporting these two different build modes creates a drag on development progress; in particular Stefan recently ran into this in this experiments with porting parts of the NumPy internals to Cython: https://github.com/numpy/numpy/pull/6408 (I suspect the particular problem he's running into can be fixed b/c so far he only has one .pyx file, but I also suspect that it will be impossible to support "one file" mode once we have multiple .pyx files.) There are some rumors that "one file" mode might be needed on some obscure platform somewhere, or that it might be necessary for statically linking numpy into the CPython executable, but we can't continue supporting things forever based only on rumors. If all we can get are rumors, then eventually we have to risk breaking things just to force anyone who cares to actually show up and explain what they need so we can support it properly :-). Would anyone object if we dropped support for the "one file" mode, making "separate compilation" mandatory, e.g. in 1.11? -n -- Nathaniel J. Smith -- http://vorpus.org

4 19

nditer when using operands with mixed C and F order
by Matti Picus 07 Oct '15

07 Oct '15

2 1

Numpy 1.10.0 release
by Charles R Harris 07 Oct '15

07 Oct '15

Hi All, It is my pleasure to release NumPy 1.10.0. Files may be found at Sourceforge <http://sourceforge.net/projects/numpy/files/NumPy/1.10.0/> and pypi <https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=numpy>. This release is the result of 789 non-merge commits made by 160 developers over a period of a year and supports Python 2.6 - 2.7 and 3.2 - 3.5. NumPy 1.10.0 Release Notes ************************** This release supports Python 2.6 - 2.7 and 3.2 - 3.5. Highlights ========== * numpy.distutils now supports parallel compilation via the --parallel/-j argument passed to setup.py build * numpy.distutils now supports additional customization via site.cfg to control compilation parameters, i.e. runtime libraries, extra linking/compilation flags. * Addition of *np.linalg.multi_dot*: compute the dot product of two or more arrays in a single function call, while automatically selecting the fastest evaluation order. * The new function `np.stack` provides a general interface for joining a sequence of arrays along a new axis, complementing `np.concatenate` for joining along an existing axis. * Addition of `nanprod` to the set of nanfunctions. * Support for the '@' operator in Python 3.5. Dropped Support: * The _dotblas module has been removed. CBLAS Support is now in Multiarray. * The testcalcs.py file has been removed. * The polytemplate.py file has been removed. * npy_PyFile_Dup and npy_PyFile_DupClose have been removed from npy_3kcompat.h. * splitcmdline has been removed from numpy/distutils/exec_command.py. * try_run and get_output have been removed from numpy/distutils/command/config.py * The a._format attribute is no longer supported for array printing. * Keywords ``skiprows`` and ``missing`` removed from np.genfromtxt. * Keyword ``old_behavior`` removed from np.correlate. Future Changes: * In array comparisons like ``arr1 == arr2``, many corner cases involving strings or structured dtypes that used to return scalars now issue ``FutureWarning`` or ``DeprecationWarning``, and in the future will be change to either perform elementwise comparisons or raise an error. * The SafeEval class will be removed. * The alterdot and restoredot functions will be removed. See below for more details on these changes. Compatibility notes =================== numpy version string ~~~~~~~~~~~~~~~~~~~~ The numpy version string for development builds has been changed from ``x.y.z.dev-githash`` to ``x.y.z.dev0+githash`` (note the +) in order to comply with PEP 440. relaxed stride checking ~~~~~~~~~~~~~~~~~~~~~~~ NPY_RELAXED_STRIDE_CHECKING is now true by default. Concatenation of 1d arrays along any but ``axis=0`` raises ``IndexError`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Using axis != 0 has raised a DeprecationWarning since NumPy 1.7, it now raises an error. *np.ravel*, *np.diagonal* and *np.diag* now preserve subtypes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There was inconsistent behavior between *x.ravel()* and *np.ravel(x)*, as well as between *x.diagonal()* and *np.diagonal(x)*, with the methods preserving subtypes while the functions did not. This has been fixed and the functions now behave like the methods, preserving subtypes except in the case of matrices. Matrices are special cased for backward compatibility and still return 1-D arrays as before. If you need to preserve the matrix subtype, use the methods instead of the functions. *rollaxis* and *swapaxes* always return a view ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Previously, a view was returned except when no change was made in the order of the axes, in which case the input array was returned. A view is now returned in all cases. *nonzero* now returns base ndarrays ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Previously, an inconsistency existed between 1-D inputs (returning a base ndarray) and higher dimensional ones (which preserved subclasses). Behavior has been unified, and the return will now be a base ndarray. Subclasses can still override this behavior by providing their own *nonzero* method. C API ~~~~~ The changes to *swapaxes* also apply to the *PyArray_SwapAxes* C function, which now returns a view in all cases. The changes to *nonzero* also apply to the *PyArray_Nonzero* C function, which now returns a base ndarray in all cases. The dtype structure (PyArray_Descr) has a new member at the end to cache its hash value. This shouldn't affect any well-written applications. The change to the concatenation function DeprecationWarning also affects PyArray_ConcatenateArrays, recarray field return types ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Previously the returned types for recarray fields accessed by attribute and by index were inconsistent, and fields of string type were returned as chararrays. Now, fields accessed by either attribute or indexing will return an ndarray for fields of non-structured type, and a recarray for fields of structured type. Notably, this affect recarrays containing strings with whitespace, as trailing whitespace is trimmed from chararrays but kept in ndarrays of string type. Also, the dtype.type of nested structured fields is now inherited. recarray views ~~~~~~~~~~~~~~ Viewing an ndarray as a recarray now automatically converts the dtype to np.record. See new record array documentation. Additionally, viewing a recarray with a non-structured dtype no longer converts the result's type to ndarray - the result will remain a recarray. 'out' keyword argument of ufuncs now accepts tuples of arrays ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When using the 'out' keyword argument of a ufunc, a tuple of arrays, one per ufunc output, can be provided. For ufuncs with a single output a single array is also a valid 'out' keyword argument. Previously a single array could be provided in the 'out' keyword argument, and it would be used as the first output for ufuncs with multiple outputs, is deprecated, and will result in a `DeprecationWarning` now and an error in the future. byte-array indices now raises an IndexError ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Indexing an ndarray using a byte-string in Python 3 now raises an IndexError instead of a ValueError. Masked arrays containing objects with arrays ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For such (rare) masked arrays, getting a single masked item no longer returns a corrupted masked array, but a fully masked version of the item. Median warns and returns nan when invalid values are encountered ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Similar to mean, median and percentile now emits a Runtime warning and returns `NaN` in slices where a `NaN` is present. To compute the median or percentile while ignoring invalid values use the new `nanmedian` or `nanpercentile` functions. Functions available from numpy.ma.testutils have changed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All functions from numpy.testing were once available from numpy.ma.testutils but not all of them were redefined to work with masked arrays. Most of those functions have now been removed from numpy.ma.testutils with a small subset retained in order to preserve backward compatibility. In the long run this should help avoid mistaken use of the wrong functions, but it may cause import problems for some. New Features ============ Reading extra flags from site.cfg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Previously customization of compilation of dependency libraries and numpy itself was only accomblishable via code changes in the distutils package. Now numpy.distutils reads in the following extra flags from each group of the *site.cfg*: * ``runtime_library_dirs/rpath``, sets runtime library directories to override ``LD_LIBRARY_PATH`` * ``extra_compile_args``, add extra flags to the compilation of sources * ``extra_link_args``, add extra flags when linking libraries This should, at least partially, complete user customization. *np.cbrt* to compute cube root for real floats ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *np.cbrt* wraps the C99 cube root function *cbrt*. Compared to *np.power(x, 1./3.)* it is well defined for negative real floats and a bit faster. numpy.distutils now allows parallel compilation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By passing *--parallel=n* or *-j n* to *setup.py build* the compilation of extensions is now performed in *n* parallel processes. The parallelization is limited to files within one extension so projects using Cython will not profit because it builds extensions from single files. *genfromtxt* has a new ``max_rows`` argument ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A ``max_rows`` argument has been added to *genfromtxt* to limit the number of rows read in a single call. Using this functionality, it is possible to read in multiple arrays stored in a single file by making repeated calls to the function. New function *np.broadcast_to* for invoking array broadcasting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *np.broadcast_to* manually broadcasts an array to a given shape according to numpy's broadcasting rules. The functionality is similar to broadcast_arrays, which in fact has been rewritten to use broadcast_to internally, but only a single array is necessary. New context manager *clear_and_catch_warnings* for testing warnings ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When Python emits a warning, it records that this warning has been emitted in the module that caused the warning, in a module attribute ``__warningregistry__``. Once this has happened, it is not possible to emit the warning again, unless you clear the relevant entry in ``__warningregistry__``. This makes is hard and fragile to test warnings, because if your test comes after another that has already caused the warning, you will not be able to emit the warning or test it. The context manager ``clear_and_catch_warnings`` clears warnings from the module registry on entry and resets them on exit, meaning that warnings can be re-raised. *cov* has new ``fweights`` and ``aweights`` arguments ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The ``fweights`` and ``aweights`` arguments add new functionality to covariance calculations by applying two types of weighting to observation vectors. An array of ``fweights`` indicates the number of repeats of each observation vector, and an array of ``aweights`` provides their relative importance or probability. Support for the '@' operator in Python 3.5+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Python 3.5 adds support for a matrix multiplication operator '@' proposed in PEP465. Preliminary support for that has been implemented, and an equivalent function ``matmul`` has also been added for testing purposes and use in earlier Python versions. The function is preliminary and the order and number of its optional arguments can be expected to change. New argument ``norm`` to fft functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The default normalization has the direct transforms unscaled and the inverse transforms are scaled by :math:`1/n`. It is possible to obtain unitary transforms by setting the keyword argument ``norm`` to ``"ortho"`` (default is `None`) so that both direct and inverse transforms will be scaled by :math:`1/\\sqrt{n}`. Improvements ============ *np.digitize* using binary search ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *np.digitize* is now implemented in terms of *np.searchsorted*. This means that a binary search is used to bin the values, which scales much better for larger number of bins than the previous linear search. It also removes the requirement for the input array to be 1-dimensional. *np.poly* now casts integer inputs to float ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *np.poly* will now cast 1-dimensional input arrays of integer type to double precision floating point, to prevent integer overflow when computing the monic polynomial. It is still possible to obtain higher precision results by passing in an array of object type, filled e.g. with Python ints. *np.interp* can now be used with periodic functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *np.interp* now has a new parameter *period* that supplies the period of the input data *xp*. In such case, the input data is properly normalized to the given period and one end point is added to each extremity of *xp* in order to close the previous and the next period cycles, resulting in the correct interpolation behavior. *np.pad* supports more input types for ``pad_width`` and ``constant_values`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``constant_values`` parameters now accepts NumPy arrays and float values. NumPy arrays are supported as input for ``pad_width``, and an exception is raised if its values are not of integral type. *np.argmax* and *np.argmin* now support an ``out`` argument ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The ``out`` parameter was added to *np.argmax* and *np.argmin* for consistency with *ndarray.argmax* and *ndarray.argmin*. The new parameter behaves exactly as it does in those methods. More system C99 complex functions detected and used ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All of the functions ``in complex.h`` are now detected. There are new fallback implementations of the following functions. * npy_ctan, * npy_cacos, npy_casin, npy_catan * npy_ccosh, npy_csinh, npy_ctanh, * npy_cacosh, npy_casinh, npy_catanh As a result of these improvements, there will be some small changes in returned values, especially for corner cases. *np.loadtxt* support for the strings produced by the ``float.hex`` method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The strings produced by ``float.hex`` look like ``0x1.921fb54442d18p+1``, so this is not the hex used to represent unsigned integer types. *np.isclose* properly handles minimal values of integer dtypes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to properly handle minimal values of integer types, *np.isclose* will now cast to the float dtype during comparisons. This aligns its behavior with what was provided by *np.allclose*. *np.allclose* uses *np.isclose* internally. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *np.allclose* now uses *np.isclose* internally and inherits the ability to compare NaNs as equal by setting ``equal_nan=True``. Subclasses, such as *np.ma.MaskedArray*, are also preserved now. *np.genfromtxt* now handles large integers correctly ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *np.genfromtxt* now correctly handles integers larger than ``2**31-1`` on 32-bit systems and larger than ``2**63-1`` on 64-bit systems (it previously crashed with an ``OverflowError`` in these cases). Integers larger than ``2**63-1`` are converted to floating-point values. *np.load*, *np.save* have pickle backward compatibility flags ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The functions *np.load* and *np.save* have additional keyword arguments for controlling backward compatibility of pickled Python objects. This enables Numpy on Python 3 to load npy files containing object arrays that were generated on Python 2. MaskedArray support for more complicated base classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Built-in assumptions that the baseclass behaved like a plain array are being removed. In particular, setting and getting elements and ranges will respect baseclass overrides of ``__setitem__`` and ``__getitem__``, and arithmetic will respect overrides of ``__add__``, ``__sub__``, etc. Changes ======= dotblas functionality moved to multiarray ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The cblas versions of dot, inner, and vdot have been integrated into the multiarray module. In particular, vdot is now a multiarray function, which it was not before. stricter check of gufunc signature compliance ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Inputs to generalized universal functions are now more strictly checked against the function's signature: all core dimensions are now required to be present in input arrays; core dimensions with the same label must have the exact same size; and output core dimension's must be specified, either by a same label input core dimension or by a passed-in output array. views returned from *np.einsum* are writeable ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Views returned by *np.einsum* will now be writeable whenever the input array is writeable. *np.argmin* skips NaT values ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *np.argmin* now skips NaT values in datetime64 and timedelta64 arrays, making it consistent with *np.min*, *np.argmax* and *np.max*. Deprecations ============ Array comparisons involving strings or structured dtypes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Normally, comparison operations on arrays perform elementwise comparisons and return arrays of booleans. But in some corner cases, especially involving strings are structured dtypes, NumPy has historically returned a scalar instead. For example:: ### Current behaviour np.arange(2) == "foo" # -> False np.arange(2) < "foo" # -> True on Python 2, error on Python 3 np.ones(2, dtype="i4,i4") == np.ones(2, dtype="i4,i4,i4") # -> False Continuing work started in 1.9, in 1.10 these comparisons will now raise ``FutureWarning`` or ``DeprecationWarning``, and in the future they will be modified to behave more consistently with other comparison operations, e.g.:: ### Future behaviour np.arange(2) == "foo" # -> array([False, False]) np.arange(2) < "foo" # -> error, strings and numbers are not orderable np.ones(2, dtype="i4,i4") == np.ones(2, dtype="i4,i4,i4") # -> [False, False] SafeEval ~~~~~~~~ The SafeEval class in numpy/lib/utils.py is deprecated and will be removed in the next release. alterdot, restoredot ~~~~~~~~~~~~~~~~~~~~ The alterdot and restoredot functions no longer do anything, and are deprecated. pkgload, PackageLoader ~~~~~~~~~~~~~~~~~~~~~~ These ways of loading packages are now deprecated. bias, ddof arguments to corrcoef ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The values for the ``bias`` and ``ddof`` arguments to the ``corrcoef`` function canceled in the division implied by the correlation coefficient and so had no effect on the returned values. We now deprecate these arguments to ``corrcoef`` and the masked array version ``ma.corrcoef``. Because we are deprecating the ``bias`` argument to ``ma.corrcoef``, we also deprecate the use of the ``allow_masked`` argument as a positional argument, as its position will change with the removal of ``bias``. ``allow_masked`` will in due course become a keyword-only argument. dtype string representation changes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Since 1.6, creating a dtype object from its string representation, e.g. ``'f4'``, would issue a deprecation warning if the size did not correspond to an existing type, and default to creating a dtype of the default size for the type. Starting with this release, this will now raise a ``TypeError``. The only exception is object dtypes, where both ``'O4'`` and ``'O8'`` will still issue a deprecation warning. This platform-dependent representation will raise an error in the next release. In preparation for this upcoming change, the string representation of an object dtype, i.e. ``np.dtype(object).str``, no longer includes the item size, i.e. will return ``'|O'`` instead of ``'|O4'`` or ``'|O8'`` as before. Authors ======= This release contains work by the following people who contributed at least one patch to this release. The names are in alphabetical order by first name. Names followed by a "+" contributed a patch for the first time. Abdul Muneer+ Adam Williams+ Alan Briolat+ Alex Griffing Alex Willmer+ Alexander Belopolsky Alistair Muldal+ Allan Haldane+ Amir Sarabadani+ Andrea Bedini+ Andrew Dawson+ Andrew Nelson+ Antoine Pitrou+ Anton Ovchinnikov+ Antony Lee+ Behzad Nouri+ Bertrand+ Blake Griffith Bob Poekert+ Brian Kearns+ CJ Carey Carl Kleffner+ Chander G+ Charles Harris Chris Hogan+ Chris Kerr Chris Lamb+ Chris Laumann+ Christian Brodbeck+ Christian Brueffer Christoph Gohlke Cimarron Mittelsteadt Daniel da Silva Darsh P. Ranjan+ David Cournapeau David M Fobes+ David Powell+ Didrik Pinte+ Dimas Abreu Dutra Dmitry Zagorny+ Eric Firing Eric Hunsberger+ Eric Martin+ Eric Moore Eric O. LEBIGOT (EOL)+ Erik M. Bray Ernest N. Mamikonyan+ Fei Liu+ François Magimel+ Gabor Kovacs+ Gabriel-p+ Garrett-R+ George Castillo+ Gerrit Holl+ Gert-Ludwig Ingold+ Glen Mabey+ Graham Christensen+ Greg Thomsen+ Gregory R. Lee+ Helder Cesar+ Helder Oliveira+ Henning Dickten+ Ian Henriksen+ Jaime Fernandez James Camel+ James Salter+ Jan Schlüter+ Jarl Haggerty+ Jay Bourque Joel Nothman+ John Kirkham+ John Tyree+ Joris Van den Bossche+ Joseph Martinot-Lagarde Josh Warner (Mac) Juan Luis Cano Rodríguez Julian Taylor Kreiswolke+ Lars Buitinck Leonardo Donelli+ Lev Abalkin Lev Levitsky+ Malik Woods+ Maniteja Nandana+ Marshall Farrier+ Marten van Kerkwijk Martin Spacek Martin Thoma+ Masud Rahman+ Matt Newville+ Mattheus Ueckermann+ Matthew Brett Matthew Craig+ Michael Currie+ Michael Droettboom Michele Vallisneri+ Mortada Mehyar+ Nate Jensen+ Nathaniel J. Smith Nick Papior Andersen+ Nick Papior+ Nils Werner Oliver Eberle+ Patrick Peglar+ Paul Jacobson Pauli Virtanen Peter Iannucci+ Ralf Gommers Richard Barnes+ Ritta Narita+ Robert Johansson+ Robert LU+ Robert McGibbon+ Ryan Blakemore+ Ryan Nelson+ Sandro Tosi Saullo Giovani+ Sebastian Berg Sebastien Gouezel+ Simon Gibbons+ Simon Guillot+ Stefan Eng+ Stefan Otte+ Stefan van der Walt Stephan Hoyer+ Stuart Berg+ Sturla Molden+ Thomas A Caswell+ Thomas Robitaille Tim D. Smith+ Tom Krauss+ Tom Poole+ Toon Verstraelen+ Ulrich Seidl Valentin Haenel Vraj Mohan+ Warren Weckesser Wendell Smith+ Yaroslav Halchenko Yotam Doron Yousef Hamza+ Yuval Langer+ Yuxiang Wang+ Zbigniew Jędrzejewski-Szmek+ cel+ chebee7i+ empeeu+ endolith hannaro+ immerrr jmrosen155+ jnothman kanhua+ mbyt+ mlai+ styr+ tdihp+ wim glenn+ yolanda15+ Åsmund Hjulstad+ Enjjoy, Chuck

5 8

Fwd: Numpy for data manipulation
by Alex Rogozhnikov 07 Oct '15

07 Oct '15

Hi, I have written some numpy tips and tricks I am using, which may be interesting to you. This is quite long reading, so I've splitted it into two parts: http://arogozhnikov.github.io/2015/09/29/NumpyTipsAndTricks1.html http://arogozhnikov.github.io/2015/09/30/NumpyTipsAndTricks2.html Comments are welcome, specially if you know any other ways to make this code faster (or better). Regards, Alex.

6 8

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver
by Slavin, Jonathan 06 Oct '15

06 Oct '15

Personally I like atleast_1d, which will convert a scalar into a 1d array but will leave arrays untouched (i.e. won't change the dimensions. Not sure what the advantages/disadvantages are relative to asarray. Jon On Fri, Oct 2, 2015 at 7:05 AM, <numpy-discussion-request(a)scipy.org> wrote: > From: Juha Jeronen <juha.jeronen(a)jyu.fi> > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Cc: > Date: Fri, 2 Oct 2015 13:31:47 +0300 > Subject: Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic > polynomial solver > On 02.10.2015 13:07, Daπid wrote: > > > On 2 October 2015 at 11:58, Juha Jeronen <juha.jeronen(a)jyu.fi> wrote: > >> >>> >> First version done and uploaded: >> >> >> https://yousource.it.jyu.fi/jjrandom2/miniprojects/trees/master/misc/polyso… >> > > Small comment: now you are checking if the input is a scalar or a ndarray, > but it should also accept any array-like. If I pass a list, I expect it to > work, internally converting it into an array. > > > Good catch. > > Is there an official way to test for array-likes? Or should I always > convert with asarray()? Or something else? > > > -J > -- ________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin(a)cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA ________________________________________________________

3 2