Mailman 3 - NumPy-Discussion

Beginners
by Monkeysigh March 11, 2025

March 11, 2025

Do you know if beginners are invited to attend?

2 1

ENH: Initilize Print Options from Environment Variables
by Daniel Bershatsky March 9, 2025

March 9, 2025

Dear NumPy Community, I would like to propose an enhancement to NumPy's print options that allows them to be initialized from environment variables. This would provide a more convenient way to configure array formatting without modifying source code. Background Currently, NumPy print options are initialized with default values and can be modified using numpy.set_printoptions() or the numpy.printoptions context manager. While effective, these approaches require explicit modifications to the source code, which is not always convenient. This discussion has been started on GitHub in issue #22188 <https://github.com/numpy/numpy/issues/22188>. Proposal I propose that NumPy print options be initialized from environment variables prefixed with NUMPY_PRINTOPTION_. For example, the precision option could be set using export NUMPY_PRINTOPTION_PRECISION=4 or on-demand execution as follows. NUMPY_PRINTOPTION_LINEWIDTH=120 python my-fancy-solver.py This approach has several advantages. 1. *Better Utilization of Wide Displays* The default line width of 80 is reasonable, but modern screens and terminals allow for wider output. Environment variables would provide a simple way to adjust this setting without modifying the code. 2. *No Source Code Modification Required* Changing print options via np.printoptions requires access to a text editor, which may not always be available (e.g., in isolated environments like Docker containers). Using environment variables allows for quick, non-invasive configuration. 3. *Familiar and Well-Understood Mechanism* Environment variables are a widely used and standard approach for configuring software behavior, making them a natural fit for setting print options. I would appreciate feedback on this idea, particularly regarding implementation details and any potential issues that might arise. Looking forward to hearing your thoughts. Best regards, Daniel Bershatsky

1 0

Automatic binning for np.histogram
by Pieter Eendebak March 7, 2025

March 7, 2025

Hi everyone, For certain input arrays with small variation the method np.histogram with automatic binning can select an enormous amount of bins and return with an out-of-memory error. A minimal example: import numpy as np e = 1 + 1e-12 Z = [0,1,1,1,1,1,e,e,e,e,e,e, 2] np.histogram(Z, bins="auto") There is a proposal to change the automatic bin selection to avoid this: https://github.com/numpy/numpy/pull/28426. The aim is to keep close to the original algorithm, but avoid the out-of-memory issues for input with small variance. It passes unit tests, but since this is a user visible change we would like some more input. In particular: * What are expectations of the auto binning algorithm? * What is a reasonable maximum number of bins for a sample of size n? With kind regards, Pieter Eendebak

2 1

Add a bit_width function
by Carlos Martin March 7, 2025

March 7, 2025

Feature request: Add a `bit_width` function to NumPy's [bit-wise operations](https://numpy.org/doc/stable/reference/routines.bitwise.html) that computes the [bit-width](https://en.wikipedia.org/wiki/Bit-width) (also called bit-length) of an input. For an example, see C++'s [`bit_width`](https://en.cppreference.com/w/cpp/numeric/bit_width) function.

4 4

Add a spectral_radius function
by Carlos Martin March 2, 2025

March 2, 2025

Add a function called `spectral_radius` that computes the [spectral_radius](https://en.wikipedia.org/wiki/Spectral_radius) of a given matrix. A naive way to do this is `np.max(np.abs(np.linalg.eigvals(a)))`, but there are more efficient methods.

2 1

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