Mailman 3 September 2022 - NumPy-Discussion

Confusd about the implementation of @TYPE@_pairwise_sum
by 腾刘 30 Sep '22

30 Sep '22

Hello there, I'm here again. With the help of the previous emails, I finally found out the real C implementation of np.sum(x), where x is a Numpy array. I found that there is a "template" function named @TYPE@_pairwise_sum in numpy/core/src/umath/loops_utils.h.src which is the underlying C code of np.sum(). I can understand the code but there is still something that I didn't figure out. Here is the code link: https://github.com/numpy/numpy/blob/main/numpy/core/src/umath/loops_utils.h… The control logic is quite simple, if the size of the array which is going to be summed up is smaller than 8, then we directly add them up; If the size is greater than 8 but smaller than PW_BLOCKSIZE, then we sum a block with 8 accumulators which will utilize the speed-up of AVX. Then if the size is greater than PW_BLOCKSIZE, we divide the array into two halves and recursively call function @TYPE@_pairwise_sum to calculate the two halves respectively. My confusion lies here: why should we divide the array into two halves and recursively calculate this? Since we won't assign two threads to compute the result in parallel, we can't get any profits from "divide and conquer". Actually we waste some time and memory in calling functions and operations in heap. There must be something that I didn't take into consideration. It will be appreciated if you can point it out! Thanks in advance~

1 0

PR hasn't been responded to in 2 weeks
by matteo_luigi_raso 28 Sep '22

28 Sep '22

I made a PR (#22255) that received some attention, but has been ignored for 2 weeks now. I commented on the PR 5 days ago, but there was still no response. Sent with [Proton Mail](https://proton.me/) secure email.

4 3

ENH: Proposal to add shift functionality to array (follow up)
by Filippo Tagliacarne 27 Sep '22

27 Sep '22

Hello everyone, I hope this is the correct place to post this as this is my first (potential) contribution to numpy. I would like to implement a function numpy.shift which would work similarly to numpy.roll, with one key difference. After shifting an array by a value `shift`, the function fills the missing values with a `fill_value` For example shifting the following array by 1 along axis 1with fill_value of 0 >>> arr = numpy.arange(10).reshape((2,5)) >>> arr array([[0, 1, 2, 3, 4], [5, 6, 7, 8, 9]]) >>> numpy.shift(arr, 1, axis=1, fill_value=0) array([[0, 0, 1, 2, 3], [0, 5, 6, 7, 8]]) Cheers, Filippo

2 1

No documentation meeting Monday Sept. 26th
by Ross Barnowski 24 Sep '22

24 Sep '22

Hi all, The regularly-scheduled documentation meeting for this Monday, Sept. 26th has been cancelled due to limited availability. The next documentation meeting will be held on Monday October 10th. If there are any documentation-related discussions you'd like to raise before the next meeting, please don't hesitate to reach out on slack! ~Ross

1 0

Ways to achieve faster np.nanpercentile() calculation?
by Aron Gergely 23 Sep '22

23 Sep '22

Hi all, On my system, np.nanpercentile() is orders of magnitude (>100x) slower than np.percentile(). I use numpy 1.23.1 Wondering if there is a way to speed it up. I came across this workaround for 3D arrays: https://krstn.eu/np.nanpercentile()-there-has-to-be-a-faster-way/ But I would need a generalized solution that works on N dimensions. So I started adopting the above - but wondering if I am reinventing the wheel here? Is there already a python package that implements a speedier nanpercentile for numpy? (similar idea as the 'Bottleneck' package?) Or other known workarounds to achieve the same result? Best regards, Aron

2 2

Re: Enhancement for AArch64 SVE instruction set
by kawakami.k＠fujitsu.com 16 Sep '22

16 Sep '22

Hi, It's been a long time since I first contacted here, but I submitted my pull request about handling Arm64 SVE architecture yesterday. https://github.com/numpy/numpy/pull/22265 Since there may be no public CI environment that runs the SVE instruction set, I tested my source code on an inhouse server (Fujitsu FX700 with A64FX). - A64FX is one of the Armv8.2-a + SVE compliant CPUs. I think the regression test was successfully completed. - python3 runtests.py --cpu-baseline=sve --cpu-dispatch=none The result shows "21354 passed, 203 skipped, 1302 deselected, 30 xfailed, 7 xpassed". My implementation is similar to those of AVX/AVX2/ASIMD. - SVE intrinsics are defined in numpy/core/src/common/simd/sve/*.h files. Travis CI reported errors https://github.com/numpy/numpy/pull/22265/checks?check_run_id=8384699529 , but it seems that the job exceeded the maximum log length, and has been terminated. I would appreciate your review of my pull request, as well as your comments and advice on this mailing list. Thanks, Kentaro

2 1

How to avoid this memory copy overhead in d=a*b+c?
by 腾刘 16 Sep '22

16 Sep '22

Hello everyone, I 'm here again to ask a naive question about Numpy performance. As far as I know, Numpy's vectorization operator is very effective because it utilizes SIMD instructions and multi-threads compared to index-style programming (using a "for" loop and assigning each element with its index in array). I 'm wondering how fast Numpy could be so I did some experiments. Take this simple task as an example: a = np.random.rand(10 000 000) b = np.random.rand(10 000 000) c = a + b To check the performance, I wrote a simple C++ implementation of adding two arrays using multi-threads too (with the compile options of: -O3 -mavx2). I found that the C++ implementation is slightly faster than Numpy (running 100 times each to get a rather convincing statistic). *Here comes the first question, how come there is this efficiency gap?* I guess this is because Numpy needs to load the shared object and find the wrapper of ufunc and then finally execute the underlying computation. Am I right? Am I missing something here? Then I did another experiment for this statement: d = a * b + c , where a, b, c and d are all numpy arrays. I also use C++ to implement this logic and found that C++ is 2 times faster than Numpy on average (also executed 100 times each). I guess this is because in python we first calculate: temporary_var = a * b and then: d = temporary_var + c so we have an unnecessary memory transfer overhead. Since each array is very large, Numpy needs to write temporary_var to memory and then read it back to cache. However in C++ we could just write d[i] = a[i] * b[i] + c[i] and we won't create a temporary array along with the memory transfer penalty. *So another problem is if there is a method to avoid this kind of overhead?* I 've learned that in Numpy we could create our own ufunc with: *frompyfunc*, but it seems that there is no SIMD optimization nor multi-threads utilized since this is 100 times slower than *"d = a * b + c" way*.

3 6

NumPy 1.23. 3 Release
by Charles R Harris 09 Sep '22

09 Sep '22

Hi All, On behalf of the NumPy team, I am pleased to announce the release of NumPy 1.23.3. NumPy 1.23.3 is a maintenance release that fixes bugs discovered after the 1.23.2 release. There is no major theme for this release, the main improvements are for some downstream builds and some annotation corner cases. The Python versions supported for this release are 3.8-3.11. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.23.3>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.23.3>. Note that we will move to MacOS 11 for the NumPy 1.23.4 release, the 10.15 version currently used will no longer be supported by our build infrastructure at that point. *Contributors* A total of 16 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Aaron Meurer - Bas van Beek - Charles Harris - Ganesh Kathiresan - Gavin Zhang + - Iantra Solari+ - Jyn Spring 琴春 + - Matti Picus - Rafael Cardoso Fernandes Sousa - Rafael Sousa + - Ralf Gommers - Rin Cat (鈴猫) + - Saransh Chopra + - Sayed Adel - Sebastian Berg - Serge Guelton *Pull requests merged* A total of 14 pull requests were merged for this release. - #22136: BLD: Add Python 3.11 wheels to aarch64 build - #22148: MAINT: Update setup.py for Python 3.11. - #22155: CI: Test NumPy build against old versions of GCC(6, 7, 8) - #22156: MAINT: support IBM i system - #22195: BUG: Fix circleci build - #22214: BUG: Expose heapsort algorithms in a shared header - #22215: BUG: Support using libunwind for backtrack - #22216: MAINT: fix an incorrect pointer type usage in f2py - #22220: BUG: change overloads to play nice with pyright. - #22221: TST,BUG: Use fork context to fix MacOS savez test - #22222: TYP,BUG: Reduce argument validation in C-based ``__class_getitem__`` - #22223: TST: ensure ``np.equal.reduce`` raises a ``TypeError`` - #22224: BUG: Fix the implementation of numpy.array_api.vecdot - #22230: BUG: Better report integer division overflow (backport) Cheers, Charles Harris

1 0

Ufuncs and dtypes: New possibilities in NumPy - video
by Inessa Pawson 08 Sep '22

08 Sep '22

A video recording of Sebastian Berg’s presentation “Ufuncs and dtypes: New possibilities in NumPy” has been posted on the NumPy YouTube channel: https://youtu.be/u9qU6cy5JkE. On Tue, Sep 6, 2022 at 10:58 PM Inessa Pawson <albuscode(a)gmail.com> wrote: > The next NumPy Newcomers Hour will be held this Thursday, September 8th at > 4 pm UTC. > > Sebastian Berg, a senior software engineer at Nvidia and long time NumPy > core developer, will present about his work on refactoring NumPy core > functionalities, such as universal functions, casting, and dtypes. We will > discuss what has been accomplished and what new applications are now > available. > > Join us via Zoom: https://us02web.zoom.us/j/87192457898 > -- Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ GitHub: inessapawson

1 0

Re: Representation of NumPy scalars
by Stefano Miccoli 08 Sep '22

08 Sep '22

On 8 Sep 2022, at 11:39, numpy-discussion-request(a)python.org<mailto:numpy-discussion-request@python.org> wrote: TL;DR: NumPy scalars representation is e.g. `34.3` instead of `float32(34.3)`. So the representation is missing the type information. What are your thoughts on changing that? This would be a VERY welcome change! If I got it right, under this proposal only the __repr__ method would be changed keeping the current __str__ behaviour: this would bring almost no change to program behaviour, but facilitate debugging. In other words: repr(np.float32(34.3)) == "numpy.float32(34.3)" str(np.float32(34.3)) == "34.3" One could even argue that the current behaviour is not only misleading, but also wrong, according to the official definition of repr <https://docs.python.org/3/library/functions.html#repr>. Let me point out that maybe also other quirks should be fixed: for example currently we have >>> np.float32(34.3).__str__() '34.3' >>> np.float32(34.3).__format__("") '34.29999923706055' It is quite strange that the single precision is promoted to double by __format__("") but not by __str__() or __repr__(). Stefano

3 2