On behalf of the NumPy team I am pleased to announce that NumPy 1.19.1 has
been released. This release supports Python 3.6-3.8 and may be built with
the latest Python 3.9 beta. It fixes several bugs found in the 1.19.0
release, replaces several functions deprecated in the upcoming Python-3.9
release, has improved support for AIX, and has a number of development
related updates to keep CI working with recent upstream changes.
Downstream developers should use Cython >= 0.29.21 when building for Python
3.9 and Cython >= 0.29.16 when building for Python 3.8. OpenBLAS >= 3.7 is
needed to avoid wrong results on the Skylake architecture. The NumPy Wheels
for this release can be downloaded from PyPI
<https://pypi.org/project/numpy/1.19.1/>, source archives, release notes,
and wheel hashes are available from Github
<https://github.com/numpy/numpy/releases/tag/v1.19.1>. Linux users will
need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014
A total of 15 people contributed to this release. People with a "+" by
names contributed a patch for the first time.
- Abhinav Reddy +
- Anirudh Subramanian
- Antonio Larrosa +
- Charles Harris
- Chunlin Fang
- Eric Wieser
- Etienne Guesnet +
- Kevin Sheppard
- Matti Picus
- Raghuveer Devulapalli
- Roman Yurchak
- Ross Barnowski
- Sayed Adel
- Sebastian Berg
- Tyler Reddy
*Pull requests merged*
A total of 25 pull requests were merged for this release.
- #16649: MAINT, CI: disable Shippable cache
- #16652: MAINT: Replace PyUString_GET_SIZE with PyUnicode_GetLength.
- #16654: REL: Fix outdated docs link
- #16656: BUG: raise IEEE exception on AIX
- #16672: BUG: Fix bug in AVX complex absolute while processing array
- #16693: TST: Add extra debugging information to CPU features detection
- #16703: BLD: Add CPU entry for Emscripten / WebAssembly
- #16705: TST: Disable Python 3.9-dev testing.
- #16714: MAINT: Disable use_hugepages in case of ValueError
- #16724: BUG: Fix PyArray_SearchSorted signature.
- #16768: MAINT: Fixes for deprecated functions in scalartypes.c.src
- #16772: MAINT: Remove unneeded call to PyUnicode_READY
- #16776: MAINT: Fix deprecated functions in scalarapi.c
- #16779: BLD, ENH: Add RPATH support for AIX
- #16780: BUG: Fix default fallback in genfromtxt
- #16784: BUG: Added missing return after raising error in methods.c
- #16795: BLD: update cython to 0.29.21
- #16832: MAINT: setuptools 49.2.0 emits a warning, avoid it
- #16872: BUG: Validate output size in bin- and multinomial
- #16875: BLD, MAINT: Pin setuptools
- #16904: DOC: Reconstruct Testing Guideline.
- #16905: TST, BUG: Re-raise MemoryError exception in test_large_zip's...
- #16906: BUG, DOC: Fix bad MPL kwarg.
- #16916: BUG: Fix string/bytes to complex assignment
- #16922: REL: Prepare for NumPy 1.19.1 release
There will be a NumPy Community meeting Wednesday July 22nd at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
Hello Melissa ,
Are we having our Docs meeting on 20th July ?
If yes , then could we have some discussion around the structure of
tutorials ,how-to sections .
I wanted to discuss how we are planning to distinguish between the two ,
should the How-to be straightforward solutions like here
something else .
Tutorials should be structured as in here
something else .
The general belief is when we hear the word "How to" is that we are greeted
to just the solution of the problem like above , while when we hear
Tutorials we are greeted to Detailed solutions with explanations for most
of the steps .
Here's a problem I've been dealing with. I wonder whether NumPy has a tool
that will help me, or whether this could be a useful feature request.
In the upcoming EuroPython 20200, I'll do a talk about live-coding a music
synthesizer. It's going to be a fun talk, I'll use the sounddevice
<https://github.com/spatialaudio/python-sounddevice/> module to make a
program that plays music. Do attend, or watch it on YouTube when it's out :)
There's a part in my talk that I could make simpler, and thus shave 3-4
minutes of cumbersome explanations. These 3-4 minutes matter a great deal
to me. But for that I need to do something with NumPy and I don't know
whether it's possible or not.
The sounddevice library takes an ndarray of sound data and plays it.
Currently I use `vectorize` to produce that array:
output_array = np.vectorize(f, otypes='d')(input_array)
And I'd like to replace it with this code, which is supposed to give the
output_array = np.ndarray(input_array.shape, dtype='d')
for i, item in enumerate(input_array):
output_array[i] = f(item)
The reason I want the second version is that I can then have sounddevice
start playing `output_array` in a separate thread, while it's being
calculated. (Yes, I know about the GIL, I believe that sounddevice releases
Unfortunately, the for loop is very slow, even when I'm not processing the
data on separate thread. I benchmarked it on both CPython and PyPy3, which
is my target platform. On CPython it's 3 times slower than vectorize, and
on PyPy3 it's 67 times slower than vectorize! That's despite the fact that
the Numpy documentation says "The `vectorize` function is provided
primarily for convenience, not for performance. The implementation is
essentially a `for` loop."
So here are a few questions:
1. Is there something like `vectorize`, except you get to access the output
array before it's finished? If not, what do you think about adding that as
an option to `vectorize`?
2. Is there a more efficient way of writing the `for` loop I've written
above? Or any other kind of solution to my problem?
Thanks for your help,
Our bi-weekly triage-focused NumPy development meeting is tomorrow
(Wednesday, July 15th) at 11 am Pacific Time (18:00 UTC).
Everyone is invited to join in and edit the work-in-progress meeting
topics and notes:
I encourage everyone to notify us of issues or PRs that you feel should
be prioritized or simply discussed briefly. Just comment on it so we
can label it, or add your PR/issue to this weeks topics for discussion.
Issue #16126: https://github.com/numpy/numpy/issues/16126
PR #16476: https://github.com/numpy/numpy/pull/16476
numpy.fft docs (v1.18):
I was advised to write on the numpy mailing list, after this week's
community meeting led to some general discussions on the normalization
schemes used in the FFT functions.
My post has to do with issue #16126, which asks for the addition of a new
option for the "norm" argument for the FFT functions; "norm" controls the
way the forward (direct) and backward (inverse) transforms are normalized,
and the two currently supported options are "norm=None" (default) and
"norm=ortho". The "ortho" option uses the orthonormal Fourier basis
functions, which translates to both the forward and backward transforms
being scaled by 1/sqrt(n), where n is the number of Fourier modes (and data
points). The default "None" option scales the forward transform by 1
(unscaled) and the backward by 1/n.
The new added option, called for now "norm=inverse", is the exact opposite
of the default option; i.e. it scales the forward transform by 1/n and the
backward by 1. In terms of using the FFT for spectral methods or
approximation problems, these are the three scaling schemes one encounters;
the transform itself is the same, with only a constant factor being the
difference. But having all three scaling options built in the fft and ifft
functions makes the code cleaner and it's easier to stay consistent.
I've submitted a PR for this change, and would be happy to get comments and
feedback on the implementation and anything else that hasn't been
Sent from: http://numpy-discussion.10968.n7.nabble.com/
Hi Mentors ,
In the last Docs meeting , we discussed about Explanations and ways we
could use to gather relevant topics for which we could provide explanations
. The light was shed upon mining of questions firstly from numpy
communities via Discussion like groups , then move to other sources .
We can mine such topics from the NumPy community via mining email threads
of numpy-discussion(a)python.org for Questions . Apart from doing this I am
thinking of opening an issue , the track of which will be kept by me and
other contributors if they wish . We can write relevant topics for
explanations over there . The link to this issue can be shared with
numpy-discussion(a)python.org and other NumPy community forums , where
contributors can comment their questions or queries which they wish to get
This way we can avoid multiple Github issues by using one Github issue ,
moreover this issue will populate queries from the community which will be
visible to everyone and may give rise to ideas regarding explanations which
we haven't thought about , in fact we can close other such issues later by
moving their queries to this issue .
In this manner we can have enough data within a month or two to document an
Explanations page . Then we could frame explanations from this pool of data
in this single Github issue ,
Do suggest your ideas/advice for the following and also if we should be
doing something else .
since there is the SciPy sprints going on we will also be joining the
event and sprinting as well.
The kickoff for the SciPy sprint session is at 9:00 CST (7:00 PST,
16:00 CET), with the start of the sprints around 9:30. We are
gathering all information at the hackmd:
so that we can be flexible with organization (e.g. which video software
to use). Note that attendance may pick up only a few hours later, but
we will try to be around most of the time.
Currently, we have a few documentation fixed listed to be worked on,
but it will be a good time to just chat or ask for help setting up a
getting started. Another bigger topic is website translations, but
more will be added certainly and input is welcome!
If you plan on coming, feel free to write yourself into the hackmd so
that we know when you are going to be around.
Hope you drop in, if just to say hi!