There are several open issues about people not being able to compile the
latest release with Python 3.8 betas due to our release containing
generated C code with a too old version of Cython. This happened for Python
3.7 as well. With the Python packaging system having improved that build
dependencies are no longer insane, I think we should stop shipping the
generated C sources.
We've discussed this a couple of times before on GitHub, but I've now
opened a PR for this (https://github.com/numpy/numpy/pull/14453) so I
thought it would be good to mention here in case anyone sees an issue with
On behalf of the NumPy team I am pleased to announce that NumPy 1.17.2 has
been released. This release contains fixes for bugs reported against NumPy
1.17.1 along with some documentation improvements. The most important fix
is for lexsort when the keys are of type (u)int8 or (u)int16. If you are
currently using 1.17 you
should upgrade. The Python versions supported in this release are 3.5-3.7,
Python 3.8b4 should work with the released source packages, but there are
no future guarantees.
Downstream developers should use Cython >= 0.29.13 for Python 3.8 support
and OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The
NumPy wheels on PyPI are built from the OpenBLAS development branch in
order to avoid those problems. Wheels for this release can be downloaded
from PyPI <https://pypi.org/project/numpy/1.17.2/>, source archives and
release notes are available from Github
A total of 7 people contributed to this release. People with a "+" by their
names contributed a patch for the first time.
- CakeWithSteak +
- Charles Harris
- Dan Allan
- Hameer Abbasi
- Lars Grueter
- Matti Picus
- Sebastian Berg
*Pull requests merged*
A total of 8 pull requests were merged for this release.
- #14418: BUG: Fix aradixsort indirect indexing.
- #14420: DOC: Fix a minor typo in dispatch documentation.
- #14421: BUG: test, fix regression in converting to ctypes
- #14430: BUG: Do not show Override module in private error classes.
- #14432: BUG: Fixed maximum relative error reporting in assert_allclose.
- #14433: BUG: Fix uint-overflow if padding with linear_ramp and
- #14436: BUG: Update 1.17.x with 1.18.0-dev pocketfft.py.
- #14446: REL: Prepare for NumPy 1.17.2 release.
I'm planning to make a 1.17.2 release Friday or Saturday in order to fix
some newly reported regressions. If there is anything that you think
absolutely needs to be in that release, please yell.
I'm a long-time user of Numpy; I had a question and I didn't know where
else to ask. (It's not a bug—otherwise I would have posted it at
Has anyone noticed that indexing an array with integer arrays (i.e.
numpy.take) is a function composition? For example, suppose you have any
two non-negative functions of integers:
return x**2 - 5*x + 10
return max(0, 2*y - 10) + 3
and you sample them as arrays, as well as their composition g(f(•)):
F = numpy.array([f(i) for i in range(10)]) # F is f at 10 elements
G = numpy.array([g(i) for i in range(100)]) # G is g at enough
elements to include max(f)
GoF = numpy.array([g(f(i)) for i in range(10)]) # GoF is g∘f at 10 elements
Indexing G by F (G[F]) returns the same result as the sampled composition (
print("G\u2218F =", G[F]) # integer indexing
print("g\u2218f =", GoF) # array of the composed functions
G∘F = [13 5 3 3 5 13 25 41 61 85]
g∘f = [13 5 3 3 5 13 25 41 61 85]
This isn't a proof, but I think it's easy to see that it would be true for
any non-negative functions (negative index handling spoils this property).
It might sound like a purely academic point, but I've noticed that I've
been able to optimize and simplify some code by taking advantage of the
associative property of function composition, repeatedly applying
numpy.take on arrays of integers before applying the fully composed index
to my data. As an example of an optimization, if I have to do the same
thing to N data arrays, it helps to prepare a single integer index and
apply it to the N data arrays instead of modifying all N data arrays in
multiple steps. As an example of a simplification, if I need to modify
arrays in recursion, it's easier to reason about the recursion if only the
terminal case applies an index to data, with the non-terminal steps
applying indexes to indexes.
This is such a basic property that I bet it has a name, and there's
probably some literature on it, like what you could find if you were
interested in monads in Haskell. But I haven't been able to find the right
search strings—what would you call this property? Is there a literature on
it and its uses?
As a user of Numpy in finance, I'm absolutely in favour of removing these functions.
They're too domain-specific, not flexible and general enough for widespread use, and probably
not easy to maintain.
There will be a NumPy Community meeting Wednesday September 4 at 11 am
Pacific Time. Everyone is invited to join in and edit the work-in-
progress meeting topics and notes: