I recently took a bit of time to study the comment "The ecological impact of high-performance computing in astrophysics" published in Nature Astronomy (Zwart, 2020, https://www.nature.com/articles/s41550-020-1208-y, https://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best however, for the environment is to abandon Python for a more environmentally friendly (compiled) programming language.".
I wrote a simple Python-Numpy implementation of the problem used for this study (https://www.nbabel.org) and, accelerated by Transonic-Pythran, it's very efficient. Here are some numbers (elapsed times in s, smaller is better):
| # particles | Py | C++ | Fortran | Julia |
| 1024 | 29 | 55 | 41 | 45 |
| 2048 | 123 | 231 | 166 | 173 |
The code and a modified figure are here: https://github.com/paugier/nbabel (There is no check on the results for https://www.nbabel.org, so one still has to be very careful.)
I think that the Numpy community should spend a bit of energy to show what can be done with the existing tools to get very high performance (and low CO2 production) with Python. This work could be the basis of a serious reply to the comment by Zwart (2020).
Unfortunately the Python solution in https://www.nbabel.org is very bad in terms of performance (and therefore CO2 production). It is also true for most of the Python solutions for the Computer Language Benchmarks Game in https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else).
We could try to fix this so that people see that in many cases, it is not necessary to "abandon Python for a more environmentally friendly (compiled) programming language". One of the longest and hardest task would be to implement the different cases of the Computer Language Benchmarks Game in standard and modern Python-Numpy. Then, optimizing and accelerating such code should be doable and we should be able to get very good performance at least for some cases. Good news for this project, (i) the first point can be done by anyone with good knowledge in Python-Numpy (many potential workers), (ii) for some cases, there are already good Python implementations and (iii) the work can easily be parallelized.
It is not a criticism, but the (beautiful and very nice) new Numpy website https://numpy.org/ is not very convincing in terms of performance. It's written "Performant The core of NumPy is well-optimized C code. Enjoy the flexibility of Python with the speed of compiled code." It's true that the core of Numpy is well-optimized C code but to seriously compete with C++, Fortran or Julia in terms of numerical performance, one needs to use other tools to move the compiled-interpreted boundary outside the hot loops. So it could be reasonable to mention such tools (in particular Numba, Pythran, Cython and Transonic).
Is there already something planned to answer to Zwart (2020)?
Any opinions or suggestions on this potential project?
PS: Of course, alternative Python interpreters (PyPy, GraalPython, Pyjion, Pyston, etc.) could also be used, especially if HPy (https://github.com/hpyproject/hpy) is successful (C core of Numpy written in HPy, Cython able to produce HPy code, etc.). However, I tend to be a bit skeptical in the ability of such technologies to reach very high performance for low-level Numpy code (performance that can be reached by replacing whole Python functions with optimized compiled code). Of course, I hope I'm wrong! IMHO, it does not remove the need for a successful HPy!
Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
BP53, 38041 Grenoble Cedex, France tel:+184.108.40.206.86.16
I suggest removing the deprecation warning when constructing a datetime64
with a timezone. For example, this is the current behavior:
>>> np.datetime64('2020-11-05 16:00+0200')
<stdin>:1: DeprecationWarning: parsing timezone aware datetimes is
deprecated; this will raise an error in the future
I suggest removing the deprecation warning because I find this to be a
useful behavior, and because it is a correct behavior. The manual says:
"The datetime object represents a single moment in time... Datetimes are
always stored based on POSIX time, with an epoch of 1970-01-01T00:00Z."
So 2020-11-05T16:00+0200 is indeed the moment in time represented by
I just used this to restrict my data set to records created after a certain
moment. It was easier for me to write the moment in my local time and add
"+0200" than to figure out the moment representation in UTC.
So this is my simple suggestion: remove the deprecation warning.
Beyond that, I have 3 ideas for changing the repr of datetime64 that I
would like to discuss.
1. Add "Z" at the end, for example, numpy.datetime64('2020-11-05T14:00Z').
This will make it clear to which moment it refers. I think this is
significant - I had to dig quite a bit to realize that
datetime64('2020-11-05T14:00') means 14:00 UTC.
2. Replace the 'T' with a space. I just find it much easier to read
'2020-11-05 14:00Z' than '2020-11-05T14:00Z'. The long sequence of
characters makes it hard for my brain to parse.
3. This will require discussion, but will be very convenient: have the repr
display the time using the environment time zone, including a time offset.
So, in my specific time zone (+0200), I will have:
repr(np.datetime64('2020-11-05 14:00Z')) ==
I'm sure the pros and cons of having an environment-dependent repr should
be discussed. But I will list some pros:
1. It's very convenient - it's immediately obvious to me to which moment
2020-11-05 16:00+0200 refers.
2. It's well defined - I may collect timestamps from machines with
different time zones, and I will be able to know to which exact moment each
3. It's very simple - I could compare any two timestamps, I don't have to
worry about time zones.
I would be happy to hear your thoughts.
Time to start planning for the 1.20.x branch. These are my thoughts at the
- Keep support for Python 3.6. Python 3.7 came out in June 2018, which
seems too recent to be our oldest supported version.
- Drop Python 3.6 for 1.21.x, that will make the oldest supported
version about three years old.
- Drop manylinux1 for 1.21.x. It would be nice to drop earlier, but
manylinux2010 is pretty recent.
There were 33 wheels in the 1.19.3 release, I think we can live with that
for 1.20.x. I'm more worried about our tools aging out. After Python has
settled into its yearly release cycle, I think we will end up supporting
the latest 4 versions.
I would like to draw the attention of this list to PR #17394  that
adds the implementation of a sliding window view to numpy.
Having a sliding window view in numpy is a longstanding open issue (cf
#7753  from 2016). A brief summary of the discussions surrounding it
can be found in the description of the PR.
This PR implements a sliding window view based on stride tricks.
Following the discussion in issue #7753, a first implementation was
provided by Fanjin Zeng in PR #10771. After some discussion, that PR
stalled and I picked up the issue in the present PR #17394. It is based
on the first implementation, but follows the changed API as suggested by
Code reviews have been provided by Bas van Beek, Stephen Hoyer, and Eric
Wieser. Sebastian Berg added the "62 - Python API" label.
Do you think this is suitable for inclusion in numpy?
Do you consider the PR ready?
Do you have suggestions or requests?
Thanks for your time and consideration!
There will be a NumPy Community meeting Wednesday November 25th at 12pm
Pacific Time (19:00 UTC). Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:
I have a proposal for a feature and I hope this is the right place to post
The idea is to have a function to map any input angle to the range of [ 0,
2*pi ] or [ - pi, pi ].
There already is a function called 'unwrap' that does the opposite, so I'd
suggest calling this function 'wrap'.
# wrap to range [ 0, 2*pi ]
>>> np.wrap([ -2*pi, -pi, 0, 4*pi ])
[0, pi, 0, 2*pi]
There is some ambiguity regarding what the solution should be for the
extremes. An example would be an input of 4*pi, as both 0 and 2*pi would be
There has been interest for this topic in the community (see
Similar functions exist for Matlab (see
https://de.mathworks.com/help/map/ref/wrapto2pi.html). They solved the
ambiguity by mapping "positive multiples of 2*pi map to 2*pi and negative
multiples of 2*pi map to 0." for the 0 to 2*pi case.