Mailman 3 February 2025 - NumPy-Discussion

next NumPy Optimization Team meeting - Monday, January 20th, 2025 at 5 pm UTC
by Inessa Pawson Jan. 31, 2026

Jan. 31, 2026

Hi, all! The next NumPy Optimization Team meeting will be held on Monday, January 20th at 17:00 UTC. Join us via Zoom: https://numfocus-org.zoom.us/j/81261288210?pwd=iwV99tGSjR61RTGEERKM4QKxe46g… 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/dVdSlQ0TThWkOk0OkmGsmw?both For the notes from the previous meetings, visit: https://github.com/numpy/archive/tree/main/optim_team_meetings -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 17

next NumPy Newcomers' Hour - June 27th, 2024 at 10 pm UTC
by Inessa Pawson Sept. 12, 2025

Sept. 12, 2025

Our next Newcomers' Hour will be held TOMORROW, June 27th at 10 pm UTC. Stop by to ask questions, share your progress, celebrate success, 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 GitHub: inessapawson

1 11

next NumPy triage meeting - Wednesday, January 22nd, 2025 at 6 pm UTC
by Inessa Pawson May 11, 2025

May 11, 2025

The next NumPy triage meeting will be held this Wednesday, January 22nd at 18:00 UTC. As always, this is a meeting where we synchronously triage prioritized PRs and issues. Everyone is welcome to attend and contribute to a conversation. Join us via Zoom: https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVX… 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 GitHub: inessapawson

1 7

next Documentation team meeting
by Mukulika Pahari May 5, 2025

May 5, 2025

Hi all, Our next Documentation Team meeting will happen on *Monday, July 15* at *7PM UTC*. All are welcome - you don't need to already be a contributor to join. If you have questions or are curious about what we're doing, we'll be happy to meet you! If you wish to join on Zoom, use this (updated) link: https://numfocus-org.zoom.us/j/85016474448?pwd=TWEvaWJ1SklyVEpwNXUrcHV1YmFJQ... Here's the permanent hackmd document with the meeting notes (still being updated): https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg Hope to see you around! Best wishes, Mukulika

2 18

next NumPy community meeting - June 5th, 2024 at 6 pm UTC
by Inessa Pawson March 22, 2025

March 22, 2025

The next NumPy community meeting will be held this Wednesday, June 5th at 6 pm UTC. Join us via Zoom: https://numfocus-org.zoom.us/j/83278611437?pwd=ekhoLzlHRjdWc0NOY2FQM0NPemdk… . 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 meetings, visit: https://github.com/numpy/archive/tree/main/community_meetings. -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 19

Compiled einsum path support
by gtoombs＠avidrone.com Feb. 27, 2025

Feb. 27, 2025

The Github issue tracker requested that I make a mailing list thread, so this is a cross-post of ENH#28394. einsum_path pre-analyzes the best contraction strategy for an Einstein sum; fine. einsum can accept that contraction strategy; also fine. I imagine that this works well in the case that there are very few, very large calls to einsum. Where this breaks down is the case where the input is smaller or the calls are more frequent, making the overhead of the Python side of einsum dominant when optimize is not False. This effect can get really bad and easily overwhelm any benefit of the planned einsum_path contraction. Another issue is that the planned contraction implies a specific subscript string, but that string needs to be passed again to einsum; this API allows for a mismatch between the subscript and optimize arguments. I can imagine a few solutions, but the one that's currently my favourite is a simple loop evaluation -> AST -> compiled set of calls to tensordot and c_einsum. In my testing this solves all of the problems I described above. In the Github issue I posted example code for an implementation that uses `ast`. I can post it here as well on request, though I don't know whether it will have syntax highlighting etc.

1 0

Usage of Datetime DType in NumPy 2.0 C-API
by Lee Johnston Feb. 24, 2025

Feb. 24, 2025

We have a C-extension module that works with Datetime DType objects through the C-API. The existing code works fine for NumPy 1x, but not 2x. The NumPy 2.0 migration documentation <https://numpy.org/doc/stable/numpy_2_0_migration_guide.html#the-pyarray-des…> does not address Datetime DType. This line of code works for 1x: NPY_DATETIMEUNIT dtu = ((PyArray_DatetimeDTypeMetaData *)descr->c_metadata)->meta.base; Here, descr is a PyArray_Descr and the code accesses the datetime's unit value. The documentation notes that in 2x, this struct is now opaque. I updated this line of code to use the provided helper macro: NPY_DATETIMEUNIT dtu = ((PyArray_DatetimeDTypeMetaData *)((_PyArray_LegacyDescr *) PyDataType_C_METADATA(descr))->c_metadata)->meta.base; The code compiles, but raises the exception "Windows fatal exception: access violation". I changed the line of code to: NPY_DATETIMEUNIT dtu = ((PyArray_DatetimeDTypeMetaData *)((_PyArray_LegacyDescr *)descr)->c_metadata)->meta.base; This code compiles and runs, but _PyArray_LegacyDescr is semi-private: [image: image.png] And, the helper macro NPY_DT_is_legacy is not in the public API. What is the correct usage pattern for accessing Datetime DType descriptor fields? Lee

2 1

StringDType useage and roadmap
by Dan Patterson Feb. 24, 2025

Feb. 24, 2025

StringDType is interesting. I was just looking for confirmation on a few things I have tried. 1. you can't use the StringDType in structured arrays. 2. you can't save or savetxt arrays with this dtype For example, something as simple as this in either scenario produces errors >>> vals = ['a little string', 'small one', '', None] >>> dt1 = StringDType(na_object=None) >>> z = np.array(vals, dtype=dt1) array(['a little string', 'small one', '', None], dtype=StringDType(na_object=None)) >>>z0 = np.asarray(vals) # -- as expected, an object array) array(['a little string', 'small one', '', None], dtype=object) >>> z1 = np.asarray(vals, dtype=[("fld", dt1)]) # -- using the dtype from above ...snip ... errored out with... TypeError: StringDType is not currently supported for structured dtype fields. Yes there are other packages one could use, but in those two use cases, I was wondering the roadmap is for this dtype, (if any)

1 0

Format of arrays to facilitate analysis
by Dan Patterson Feb. 18, 2025

Feb. 18, 2025

I tend to work with Nx2 arrays representing coordinate geometry. I have examined a number of packages and there is no guidelines as to why a certain arrangement is preferred over the other. For example: a rectangle, coordinates ordered clockwise with the first and last the same to ensure closure of the geometry as a numpy ndarray array([[ 0.00, 0.00], [ 0.00, 2.00], [ 8.00, 2.00], [ 8.00, 0.00], [ 0.00, 0.00]]) same, but just ravelled array([ 0.00, 0.00, 0.00, 2.00, 8.00, 2.00, 8.00, 0.00, 0.00, 0.00]) How about a T array([[ 0.00, 0.00, 8.00, 8.00, 0.00], [ 0.00, 2.00, 2.00, 0.00, 0.00]]) and of course there are the python list equivalents of the above. Preference/history seems to be the only guiding principle as to one chooses a certain coordinate layout over another. Nx2 for 2D coordinates makes sense to me ( eg X, Y graphs, Longitude, Latitude) If I were to profer a reason to another person why I chose a particular format over another other than "works for me", would there be any other guiding considerations? In general I: - work with the coordinates as a pair - sometimes, just the 'X' or 'Y' - I save the values to disk on occasion so I can recover a particular entity without having to recreate it. Curious... since I also worked with 3D coordinates (X, Y, Z as position and elevation) but I am considering working with temporal representation of 2D and 3D data. This is still ndim=2, but adding time as a the 3rd dimension array([[[ 0.00, 0.00], # locations at time 0 [ 0.00, 2.00], [ 8.00, 2.00], [ 8.00, 0.00], [ 0.00, 0.00]], [[ 10.00, 10.00], # locations at time 2, shifted by 10, 10 in X, and Y [ 10.00, 12.00], [ 18.00, 12.00], [ 18.00, 10.00], [ 10.00, 10.00]]])

2 3

NumPy 2.2.3 Release
by Charles R Harris Feb. 13, 2025

Feb. 13, 2025

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 2.2.3. NumPy 2.2.3 is a patch release that fixes bugs found after the 2.2.2 release. The majority of the changes are typing improvements and fixes for free threaded Python. Both of those areas are still under development, so if you discover new problems, please report them. This release supports Python 3.10-3.13. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.2.3>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v2.2.3>. *Contributors* A total of 9 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - !amotzop - Charles Harris - Chris Sidebottom - Joren Hammudoglu - Matthew Brett - Nathan Goldbaum - Raghuveer Devulapalli - Sebastian Berg - Yakov Danishevsky + *Pull requests merged* A total of 21 pull requests were merged for this release. - #28185: MAINT: Prepare 2.2.x for further development - #28201: BUG: fix data race in a more minimal way on stable branch - #28208: BUG: Fix ``from_float_positional`` errors for huge pads - #28209: BUG: fix data race in np.repeat - #28212: MAINT: Use VQSORT_COMPILER_COMPATIBLE to determine if we should... - #28224: MAINT: update highway to latest - #28236: BUG: Add cpp atomic support (#28234) - #28237: BLD: Compile fix for clang-cl on WoA - #28243: TYP: Avoid upcasting ``float64`` in the set-ops - #28249: BLD: better fix for clang / ARM compiles - #28266: TYP: Fix ``timedelta64.__divmod__`` and ``timedelta64.__mod__``... - #28274: TYP: Fixed missing typing information of set_printoptions - #28278: BUG: backport resource cleanup bugfix from gh-28273 - #28282: BUG: fix incorrect bytes to stringdtype coercion - #28283: TYP: Fix scalar constructors - #28284: TYP: stub ``numpy.matlib`` - #28285: TYP: stub the missing ``numpy.testing`` modules - #28286: CI: Fix the github label for ``TYP:`` PR's and issues - #28305: TYP: Backport typing updates from main - #28321: BUG: fix race initializing legacy dtype casts - #28324: CI: update test_moderately_small_alpha Cheers, Charles Harris

1 0