[Numpy-discussion] NumPy 1.12.0b1 released.

[Charles R Harris]

Hi All,

I'm pleased to annouce the release of NumPy 1.12.0b1. This release
supports  Python 2.7 and 3.4 - 3.6 and is the result of 388 pull requests
submitted by 133 contributors. It is quite sizeable and rather than put the
release notes inline I've attached them as a file and they may also be
viewed at Github .
Zip files and tarballs may also be found the Github link. Wheels and source
archives may be downloaded from PyPI, which is the recommended method.

This release is a large collection of fixes, enhancements, and improvements
and it is difficult to select just a few as highlights. However, the
following enhancements may be of particular interest

   - Order of operations in ``np.einsum`` now can be optimized for large
   speed improvements.
   - New ``signature`` argument to ``np.vectorize`` for vectorizing with
   core dimensions.
   - The ``keepdims`` argument was added to many functions.
   - Support for PyPy 2.7 v5.6.0 has been added. While not complete, this
   is a milestone for PyPy's C-API compatibility layer.

Thanks to all,

Chuck
NumPy 1.12.0 Release Notes
**

This release supports Python 2.7 and 3.4 - 3.6.

Highlights
==

* Order of operations in ``np.einsum`` now can be optimized for large speed improvements.
* New ``signature`` argument to ``np.vectorize`` for vectorizing with core dimensions.
* The ``keepdims`` argument was added to many functions.

Dropped Support
===

* Support for Python 2.6, 3.2, and 3.3 has been dropped.


Added Support
=

* Support for PyPy 2.7 v5.6.0 has been added. While not complete (nditer
  ``updateifcopy`` is not supported yet), this is a milestone for PyPy's
  C-API compatibility layer.


Build System Changes


* Library order is preserved, instead of being reordered to match that of
  the directories.


Deprecations


Assignment of ndarray object's ``data`` attribute
~
Assigning the 'data' attribute is an inherently unsafe operation as pointed
out in gh-7083. Such a capability will be removed in the future.

Unsafe int casting of the num attribute in ``linspace``
~~~
``np.linspace`` now raises DeprecationWarning when num cannot be safely
interpreted as an integer.

Insufficient bit width parameter to ``binary_repr``
~~~
If a 'width' parameter is passed into ``binary_repr`` that is insufficient to
represent the number in base 2 (positive) or 2's complement (negative) form,
the function used to silently ignore the parameter and return a representation
using the minimal number of bits needed for the form in question. Such behavior
is now considered unsafe from a user perspective and will raise an error in the
future.


Future Changes
==

* In 1.13 NAT will always compare False except for ``NAT != NAT``,
  which will be True.  In short, NAT will behave like NaN
* In 1.13 np.average will preserve subclasses, to match the behavior of most
  other numpy functions such as np.mean. In particular, this means calls which
  returned a scalar may return a 0-d subclass object instead.

Multiple-field manipulation of structured arrays

In 1.13 the behavior of structured arrays involving multiple fields will change
in two ways:

First, indexing a structured array with multiple fields (eg,
``arr[['f1', 'f3']]``) will return a view into the original array in 1.13,
instead of a copy. Note the returned view will have extra padding bytes
corresponding to intervening fields in the original array, unlike the copy in
1.12, which will affect code such as ``arr[['f1', 'f3']].view(newdtype)``.

Second, for numpy versions 1.6 to 1.12 assignment between structured arrays
occurs "by field name": Fields in the destination array are set to the
identically-named field in the source array or to 0 if the source does not have
a field::

>>> a = np.array([(1,2),(3,4)], dtype=[('x', 'i4'), ('y', 'i4')])
>>> b = np.ones(2, dtype=[('z', 'i4'), ('y', 'i4'), ('x', 'i4')])
>>> b[:] = a
>>> b
array([(0, 2, 1), (0, 4, 3)],
  dtype=[('z', '

Re: [Numpy-discussion] ufunc for sum of squared difference

[Matthew Harrigan]

Thanks for pointing me to that.  I think its a great match for a 1D case,
like the inner product of two arrays in terms of signature.  I don't see
how it works with higher dimensional arrays, esp with something like the
axis parameter in ufunc.reduce.  With what I proposed for an array of shape
(M, N) for example, result.shape could be (1,) or (M, 1) or (1, N) for
reducing over the flattened array or either axis.  Can you do something
like that with gufunc or do you need to iterate gufunc calls over
slices/views?  Thanks again.

On Mon, Nov 14, 2016 at 8:49 PM, Stephan Hoyer  wrote:

> On Mon, Nov 14, 2016 at 5:40 PM, Matthew Harrigan <
> harrigan.matt...@gmail.com> wrote:
>
>> Essentially it creates a reduce for a function which isn't binary.  I
>> think this would be generally useful.
>>
>
> NumPy already has a generic enough interface for creating such ufuncs. In
> fact, it's called a "generalized ufunc":
> https://docs.scipy.org/doc/numpy/reference/c-api.generalized-ufuncs.html
>
> I think you could already write "implicit reductions" using gufuncs?
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ufunc for sum of squared difference

[Jerome Kieffer]

On Mon, 14 Nov 2016 22:38:25 +0200
eat  wrote:

> but it's not so obvious what's happening "under the hoods". Consider this
> (with an old Win7 machine):
> Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64
> bit (AMD64)]
> np.__version__
> '1.11.1'

What matters is the "blas" library used under the hood, hence the
options passed to numpy at compile time. I notices 20x differences
depending on the blas version.

But more importantly:
* results are the same (at the limit of the numerical precision)
* dot() was always faster than sum(square()), varying from a bit to a lot.

I agree this may change in future version of numpy.

Cheers,
-- 
Jérôme Kieffer
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion