Mailman 3 April 2023 - NumPy-Discussion

next NumPy community meeting
by Inessa Pawson 04 Jun '23

04 Jun '23

The next NumPy community meeting will be held this Wednesday, August 17th at 18:00 (6 pm) UTC. Join us via Zoom: https://us06web.zoom.us/j/83278611437?pwd=ekhoLzlHRjdWc0NOY2FQM0NPemdkZz09 Everyone is welcome and encouraged to attend. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both For the notes from the previous meeting, visit: https://github.com/numpy/archive/blob/main/community_meetings/community-202… Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ Twitter: @inessapawson

1 21

next NumPy Newcomers' Hour - 8 pm UTC
by Inessa Pawson 28 May '23

28 May '23

Our next Newcomers' Hour will be held this Thursday, December 15th at 8 pm UTC. Stop by to ask questions or just to say hi. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/3f3otyyuTte3FU9y3QzsLg?both Join the meeting via Zoom: https://us06web.zoom.us/j/82563808729?pwd=ZFU3Z2dMcXBGb05YemRsaGE1OW5nQT09 -- Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ GitHub: inessapawson

1 9

next NumPy triage meeting - now starting at 5 pm UTC
by Inessa Pawson 28 May '23

28 May '23

The next NumPy triage meeting will be held this Wednesday, January 11th at 5 pm UTC. (Please note the new time!) This is a meeting where we synchronously triage prioritized PRs and issues. Join us via Zoom: https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVX… Everyone is welcome to attend and contribute to a conversation. Please notify us of issues or PRs that you’d like to have reviewed by adding a GitHub link to them in the meeting agenda: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg. -- Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ GitHub: inessapawson

1 10

Giving deprecation of e.g. `float(np.array([1]))` a shot (not 0-d)
by Sebastian Berg 16 May '23

16 May '23

Hi all, Unlike conversions of 0-d arrays via: float(np.array([1])) conversions of 1-D or higher dimensional arrays with a single element are a bit strange: float(np.array([1])) And deprecating it has come up often enough with many in favor, but also many worried about the possible annoyance to users. I decided to give the PR a shot, I may have misread the room on it though: https://github.com/numpy/numpy/pull/10615 So if this turns out noisy (or you may simply disagree), I am happy to revert! There was always the worry that it might be painful for downstream. SciPy, pandas, matplotlib should all be fine (were fixed in the past years). And the fact that SciPy required much more changes than the other gives me some hope that many libraries won't mind. For end-users, I would lean towards taking it slow, but if you see issues there we can also revert of course. Cheers, Sebastian

5 8

next NumPy Newcomers' Hour - 12 pm UTC
by Inessa Pawson 14 May '23

14 May '23

Our next Newcomers' Hour will be held tomorrow, December 1st, at 12 pm UTC. Stop by to ask questions or just to say hi. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/3f3otyyuTte3FU9y3QzsLg?both Join the meeting via Zoom: https://us06web.zoom.us/j/82563808729?pwd=ZFU3Z2dMcXBGb05YemRsaGE1OW5nQT09 -- Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ GitHub: inessapawson

1 3

Consider linking to Accelerate in Apple Silicon ARM64 wheels
by Clemens Brunner 10 May '23

10 May '23

Hello! I recently got a new MacBook Pro with an M2 Pro CPU (ARM64). When I ran some numerical computations (ICA to be precise), I was surprised how slow it was - way slower than e.g. my almost 10 year old Intel Mac. It turns out that the default OpenBLAS, which is what you get when installing the binary wheel with pip (i.e. "pip install numpy"), is the reason why computations are so slow. When installing NumPy from source (by using "pip install --no-binary :all: --no-use-pep517 numpy"), it uses the Apple-provided Accelerate framework, which includes an optimized BLAS library. The difference is mind-boggling, I'd even say that NumPy is pretty much unusable with the default OpenBLAS backend (at least for the applications I tested). In my test with four different ICA algorithms, I got these runtimes with the default OpenBLAS: - FastICA: 6.3s - Picard: 26.3s - Infomax: 0.8s - Extended Infomax: 1.4s Especially the second algorithm is way slower than on my 10 year old Intel Mac using OpenBLAS. Here are the times with Accelerate: - FastICA: 0.4s - Picard: 0.6s - Infomax: 1.0s - Extended Infomax: 1.3s Given this huge performance difference, my question is if you would consider distributing a binary wheel for ARM64-based Macs which links to Accelerate. Or are there any caveats why you do not want to do that? I know that NumPy moved away from Accelerate years ago on Intel Macs, but maybe now is the time to reconsider this decision. Thanks! Clemens

3 6

Managing integer overflow
by jmsachs＠gmail.com 03 May '23

03 May '23

Hi there! I'm looking at options for fixed-point math, and none of the existing Python modules (https://github.com/smlgit/fpbinary, https://github.com/francof2a/fxpmath, etc.) seem to check the right boxes, so I'm thinking about creating my own, and maybe contributing it to numpy. Are there any facilities in numpy to manage integer overflow in addition/subtraction/multiplication of values with identical dtypes? The default behavior with integer types like np.uint8 appears to be twos-complement wrapping syntax with an optional warning (or exception or whatever via np.seterr), and that's well-designed, but not as helpful as what I'd like to see in some cases where I'm willing to sacrifice some speed to provide feedback. Ideally if there is an overflow in an array operation I'd like to produce an "overflow array" that's the same size as the result array, but with the values +1 if it's a positive overflow or -1 if it's a negative overflow. That way I can either raise an exception or saturate the output. If there are not such facilities already --- and again, I don't want to burden the default operations with this kind of behavior, but would like to see some way of facilitating this behavior through some mechanism --- let me know and I will open up a feature request. --Jason

3 5

Google Season of Docs 2023 Project Roadmap
by Mars Lee 02 May '23

02 May '23

Hi everyone, I'm Mars, the selected technical writer for NumPy’s Google Summer of Docs project proposal, the ‘NumPy Contributor Comics'. The project roadmap and timeline can be read here: https://medium.com/@marsbarlee/gsod-numpy-contributor-comics-project-roadma…. In a few weeks, I'll host short brainstorming sessions to gather community input during the NumPy Community and Docs meeting. It will also be open for review soon. Looking forward to shaping and sharing these comics with everyone! Best, Mars

3 2

Google Season of Docs 2023 participation announcement
by Mukulika Pahari 28 Apr '23

28 Apr '23

Hi all, I am pleased to announce that NumPy has been selected as a participant for the Google Season of Docs program. This year, the grant will support Mars (@MarsBarLee) as our technical writer on the "NumPy Contributor Journey Comics" project. She has been instrumental in improving the NumPy documentation experience through design and conceived the idea for this project here- https://github.com/numpy/numpy.org/pull/600. She will share her detailed implementation plan with us soon. The project proposal can be read here- https://github.com/numpy/numpy/wiki/Google-Season-of-Docs-2023:-Project-Pro…. And the full list of selected participants can be seen at https://developers.google.com/season-of-docs/docs/participants. Also, we are always happy to welcome other documentation contributions on a volunteer basis. Please check out our community page (https://numpy.org/community/) if you wish to get involved. Best wishes, Mukulika

3 2

Align Community & Triage meeting times
by Ross Barnowski 26 Apr '23

26 Apr '23

Hi All, Currently, the numpy community and triage meetings alternate between 7PM UTC (community) and 5PM UTC (triage) on a biweekly basis. At the most recent community meeting, there was a strong preference among attendees to do away with the alternating times and have both meetings at 5PM UTC. Therefore, I plan to update the meeting times so that both community & triage meetings are held at 5PM UTC (10AM PST, 8PM EEST). This time was determined to work better for regular meeting attendees, but if there are any strong objections please comment on this pull request <https://github.com/scientific-python/scientific-python.org/pull/383>. ~Ross

1 0

NumPy-Discussion April 2023