[Numpy-discussion] Numpy 1.11.0 released

[Charles R Harris]

Hi All,

I'm pleased to announce the release of Numpy 1.11.0. This release is the
result of six months of work comprising 371 merged pull requests submitted
by 112 authors containing many bug fixes and improvements. Highlights are:

   - The datetime64 type is now timezone naive.
   - A dtype parameter has been added to ``randint``.
   - Improved detection of two arrays possibly sharing memory.
   - Automatic bin size estimation for ``np.histogram``.
   - Speed optimization of A @ A.T and dot(A, A.T).
   - New function ``np.moveaxis`` for reordering array axes.

Source files and documentation can be found on Sourceforge
, while source
files and OS X wheels for Python 2.7, 3.3, 3.4, and 3.5 can be installed
from Pypi. Note that this is the last release to support Python 2.6, 3.2,
and 3.3.

Contributors are listed below in alphabetical order with the names of new
contributors starred.

Abdullah Alrasheed*
Aditya Panchal*
Alain*
Alex Griffing
Alex Rogozhnikov*
Alex Willmer
Alexander Heger*
Allan Haldane
Anatoly Techtonik*
Andrew Nelson
Anne Archibald
Antoine Pitrou
Antony Lee*
Behzad Nouri
Bertrand Lefebvre
Blake Griffith
Boxiang Sun*
Brigitta Sipocz*
Carl Kleffner
Charles Harris
Chris Hogan*
Christoph Gohlke
Colin Jermain*
Cong Ma*
Daniel
David Freese
David Sanders*
Dmitry Odzerikho*
Dmitry Zagorny*
Eric Larson*
Eric Moore
Ethan Kruse*
Eugene Krokhalev*
Evgeni Burovski*
Francis T. O'Donovan*
François Boulogne*
Gabi Davar*
Gerrit Holl
Gopal Singh Meena*
Greg Yang*
Greg Young*
Gregory R. Lee
Griffin Hosseinzadeh*
Hassan Kibirige*
Holger Kohr*
Ian Henriksen
Iceman9*
Jaime Fernandez
James Camel*
Jason King*
John Bjorn Nelson*
John Kirkham
Jonathan Helmus
Jonathan Underwood*
Joseph Fox-Rabinovitz*
Julian Taylor
Julien Dubois*
Julien Lhermitte*
Julien Schueller*
Jörn Hees*
Konstantinos Psychas*
Lars Buitinck
Luke Zoltan Kelley*
MaPePeR*
Mad Physicist*
Mark Wiebe
Marten van Kerkwijk
Matthew Brett
Matthias Geier*
Maximilian Trescher*
Michael  K. Tran*
Michael Behrisch*
Michael Currie*
Michael Löffler*
Nathaniel Hellabyte*
Nathaniel J. Smith
Nick Papior*
Nicolas Calle*
Nicolás Della Penna*
Olivier Grisel
Pauli Virtanen
Peter Iannucci
Phaiax*
Ralf Gommers
Rehas Sachdeva*
Ronan Lamy
Ruediger Meier*
Ryan Grout*
Ryosuke Okuta*
Rémy Léone*
Sam Radhakrishnan*
Samuel St-Jean*
Sebastian Berg
Simon Conseil*
Stephan Hoyer
Stuart Archibald*
Stuart Berg
Sumith*
Tapasweni Pathak*
Thomas Robitaille
Tobias Megies*
Tushar Gautam*
Varun Nayyar*
Vincent Legoll*
Warren Weckesser
Wendell Smith
Yash Mehrotra*
Yifan Li*
endolith
floatingpointstack*
ldoddema*
yolanda15*

Thanks to all who worked on this release.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why does asarray() create an intermediate memoryview?

[Pauli Virtanen]

Sun, 27 Mar 2016 17:00:51 -0400, Alexander Belopolsky kirjoitti:
[clip]
> Why can't a.base be base?  What is the need for the intermediate
> memoryview object?

Implementation detail vs. life cycle management of buffer acquisitions.

The PEP3118 Py_buffer structure representing an acquired buffer is a C 
struct that is not safe to copy (!), and needs to sit in an allocated 
blob of memory whose life cycle has to be managed. The acquisition also 
needs to be released after use.

Python's memoryview object happens to be a convenient way to babysit this.

Rather than adding a new entry to the ArrayObject struct for a potential 
acquired buffer and inserting corresponding release calls, I picked a 
more localized solution where the acquisition is managed by the 
memoryview object rather than ndarray itself, and the life cycle works out 
via the pre-existing ndarray.base refcounting.

-- 
Pauli Virtanen

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Why does asarray() create an intermediate memoryview?

[Alexander Belopolsky]

In the following session a numpy array is created from an stdlib array:

In [1]: import array

In [2]: base = array.array('i', [1, 2])

In [3]: a = np.asarray(base)

In [4]: a.base
Out[4]: 

In [5]: a.base.obj
Out[5]: array('i', [1, 2])

In [6]: a.base.obj is base
Out[6]: True

Why can't a.base be base?  What is the need for the intermediate memoryview
object?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ATLAS build errors

[Pauli Virtanen]

Sat, 26 Mar 2016 14:05:24 -0700, Matthew Brett kirjoitti:
> I'm workon on building manylinux wheels for numpy, and I ran into
> unexpected problems with a numpy built against the ATLAS 3.8 binaries
> supplied by CentOS 5.
[clip]
> Does anyone recognize these?   How should I modify the build to avoid
> them?

Maybe the ATLAS binaries supplied were compiled with g77 instead of 
gfortran. If so, they should not be used with gfortran --- need to 
recompile.

Also, in the past ATLAS binaries shipped by distributions had severe 
bugs. However, 3.8.x may be a new enough version.

-- 
Pauli Virtanen

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Behavior of .reduceat()

[Jaime Fernández del Río]

Two of the oldest issues in the tracker (#834
 and #835
) are about how .reduceat()
handles its indices parameter. I have been taking a look at the source
code, and it would be relatively easy to modify, the hardest part being to
figure out what the exact behavior should be.

Current behavior is that np.ufunc.reduceat(x, ind) returns
[np.ufunc.reduce(a[ind[i]:ind[i+1]]
for i in range(len(ind))] with a couple of caveats:

   1. if ind[i] >= ind[i+1], then a[ind[i]] is returned, rather than a
   reduction over an empty slice.
   2. an index of len(ind) is appended to the indices argument, to be used
   as the endpoint of the last slice to reduce over.
   3. aside from this last case, the indices are required to be strictly
   inbounds, 0 <= index < len(x), or an error is raised

The proposed new behavior, with some optional behaviors, would be:

   1. if ind[i] >= ind[i+1], then a reduction over an empty slice, i.e. the
   ufunc identity, is returned. This includes raising an error if the ufunc
   does not have an identity, e.g. np.minimum.
   2. to fully support the "reduction over slices" idea, some form of out
   of bounds indices should be allowed. This could mean either that:
  1. only index = len(x) is allowed without raising an error, to allow
  computing the full reduction anywhere, not just as the last entry of the
  return, or
  2. allow any index in -len(x) <= index <= len(x), with the usual
  meaning given to negative values, or
  3. any index is allowed, with reduction results clipped to existing
  values (and the usual meaning for negative values).
   3. Regarding the appending of that last index of len(ind) to indices, we
   could:
  1. keep appending it, or
  2. never append it, since you can now request it without an error
  being raised, or
  3. only append it if the last index is smaller than len(x).

My thoughts on the options:

   - The minimal, more conservative approach would go with 2.1 and 3.1. And
   of course 1, if we don't implement that none of this makes sense.
   - I kind of think 2.2 or even 2.3 are a nice enhancement that shouldn't
   break too much stuff.
   - 3.2 I'm not sure about, probably hurts more than it helps at this
   point, although in a brand new design you probably would either not append
   the last index or also prepend a zero, as in np.split.
   - And 3.3 seems too magical, probably not a good idea, only listed it
   for completeness.

Any other thoughts or votes on what, if anything, should we implement, and
what the deprecation of current behavior should look like?

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion