Mailman 3 November 2023 - NumPy-Discussion

Switching default order to column-major
by Valerio De Benedetto 16 Nov '23

16 Nov '23

Hi, I found that the documented default row-major order is enforced throughout the library with a series of `order='C'` default parameters, so given this I supposed there's no way to change the default (or am I wrong?) If, supposedly, I'd change that by patching the library (substituting 'C's for 'F's), do you think there would by any problem with other downstream libraries using numpy in my project? Do you think they assume a default-constructed array is always row-major and access the underlying data?

7 7

Re: Switching default order to column-major
by Valerio De Benedetto 16 Nov '23

16 Nov '23

Thanks to everyone for your answers. I guess the conclusion is that changing the default ordering will do more harm than good. So, considering the C API, what do you advise to use to copy a (probably) row-major ndarray into a data structure that is always column-major? Like some kind of iterator that will jump across strides in the source array in the fastest way possible?

1 0

We've recevied a NumFOCUS SDG!
by kaistriega＠gmail.com 14 Nov '23

14 Nov '23

Hello NumPy community, I am thrilled to announce that I have been awarded a NumFocus Small Development Grant for my work on NumPy-Financial. This grant will enable me to enhance compatibility with NumPy 2.0, attract new contributors, improve testing and documentation, and perform the UFunc rework. I'm looking forward to contributing to the scientific Python community! As part of this grant, I am looking for any NumPy-Financial users input, especially in regard to setting up some benchmarks of real world scenarios. If you are currently using NumPy-Financial please get in touch. I hope everyone is going well Kai

4 3

NumPy 1.26. 2 released
by Charles R Harris 12 Nov '23

12 Nov '23

Charles R Harris <charlesr.harris(a)gmail.com> Sat, Oct 14, 3:03 PM to numpy-discussion, SciPy, bcc: python-announce-list Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 1.26.2. NumPy 1.26.2 is a maintenance release that fixes bugs and regressions discovered after the 1.26.1 release. The Python versions supported by this release are 3.9-3.12. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.26.2/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.26.2>. The release notes have documentation of the new meson functionality. *Contributors* A total of 13 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - @stefan6419846 - @thalassemia + - Andrew Nelson - Charles Bousseau + - Charles Harris - Marcel Bargull + - Mark Mentovai + - Matti Picus - Nathan Goldbaum - Ralf Gommers - Sayed Adel - Sebastian Berg - William Ayd + *Pull requests merged* A total of 25 pull requests were merged for this release. - #24814: MAINT: align test_dispatcher s390x targets with _umath_tests_mtargets - #24929: MAINT: prepare 1.26.x for further development - #24955: ENH: Add Cython enumeration for NPY_FR_GENERIC - #24962: REL: Remove Python upper version from the release branch - #24971: BLD: Use the correct Python interpreter when running tempita.py - #24972: MAINT: Remove unhelpful error replacements from ``import_array()`` - #24977: BLD: use classic linker on macOS, the new one in XCode 15 has... - #25003: BLD: musllinux_aarch64 [wheel build] - #25043: MAINT: Update mailmap - #25049: MAINT: Update meson build infrastructure. - #25071: MAINT: Split up .github/workflows to match main - #25083: BUG: Backport fix build on ppc64 when the baseline set to Power9... - #25093: BLD: Fix features.h detection for Meson builds [1.26.x Backport] - #25095: BUG: Avoid intp conversion regression in Cython 3 (backport) - #25107: CI: remove obsolete jobs, and move macOS and conda Azure jobs... - #25108: CI: Add linux_qemu action and remove travis testing. - #25112: MAINT: Update .spin/cmds.py from main. - #25113: DOC: Visually divide main license and bundled licenses in wheels - #25115: MAINT: Add missing ``noexcept`` to shuffle helpers - #25116: DOC: Fix license identifier for OpenBLAS - #25117: BLD: improve detection of Netlib libblas/libcblas/liblapack - #25118: MAINT: Make bitfield integers unsigned - #25119: BUG: Make n a long int for np.random.multinomial - #25120: BLD: change default of the ``allow-noblas`` option to true. - #25121: BUG: ensure passing ``np.dtype`` to itself doesn't crash Cheers, Charles Harris

1 0

Black style as applied to np.array(...) and the ruff formatter
by Peter Cock 03 Nov '23

03 Nov '23

Hello all, I imagine there are many people here using the black coding style as implemented by the tool black, albeit with reservations about how it lays out arrays by default (often therefore wrapped in a format off/on block to exclude the array from automatic layout to allow for manual column based layouts). You may already be aware of the tool ruff as a fast alternative to flake8, but it now has a formatter which implements the black format (with some minor divergences): https://astral.sh/blog/the-ruff-formatter The authors are open to exploring special casing how it autoformats arrays, and I think input now from the numpy community would be a good idea: https://github.com/astral-sh/ruff/discussions/8452 Kind regards, Peter

1 0

Windows default integer now 64bit in main
by Sebastian Berg 03 Nov '23

03 Nov '23

Hi all, just a heads up, the PR to change the default integer is merged on main. This may cause issues, especially with Cython code because `np.int_t` cannot be reasonably defined anymore. Other code may also want to vet usage of "long" in any variation. Much code (like SciPy) simply supports any integer input, although even there integer output may be relevant. New NumPy defines `NPY_DEFAULT_INT` to be able to branch at runtime for backward compatiblity you could use: #ifndef NPY_DEFAULT_INT #define NPY_DEFAULT_INT NPY_LONG #endif Unfortunately, I expect this to be a bit painful, please let us know if it is too painful for some reason. But OTOH it has been a recurring surprise and is a common reason for linux written software to not run on windows. - Sebastian

2 2

Function that searches arrays for the first element that satisfies a condition
by rosko37 01 Nov '23

01 Nov '23

I know this question has been asked before, both on this list as well as several threads on Stack Overflow, etc. It's a common issue. I'm NOT asking for how to do this using existing Numpy functions (as that information can be found in any of those sources)--what I'm asking is whether Numpy would accept inclusion of a function that does this, or whether (possibly more likely) such a proposal has already been considered and rejected for some reason. The task is this--there's a large array and you want to find the next element after some index that satisfies some condition. Such elements are common, and the typical number of elements to be searched through is small relative to the size of the array. Therefore, it would greatly improve performance to avoid testing ALL elements against the conditional once one is found that returns True. However, all built-in functions that I know of test the entire array. One can obviously jury-rig some ways, like for instance create a "for" loop over non-overlapping slices of length slice_length and call something like np.where(cond) on each--that outer "for" loop is much faster than a loop over individual elements, and the inner loop at most will go slice_length-1 elements past the first "hit". However, needing to use such a convoluted piece of code for such a simple task seems to go against the Numpy spirit of having one operation being one function of the form func(arr)". A proposed function for this, let's call it "np.first_true(arr, start_idx, [stop_idx])" would be best implemented at the C code level, possibly in the same code file that defines np.where. I'm wondering if I, or someone else, were to write such a function, if the Numpy developers would consider merging it as a standard part of the codebase. It's possible that the idea of such a function is bad because it would violate some existing broadcasting or fancy indexing rules. Clearly one could make it possible to pass an "axis" argument to np.first_true() that would select an axis to search over in the case of multi-dimensional arrays, and then the result would be an array of indices of one fewer dimension than the original array. So np.first_true(np.array([1,5],[2,7],[9,10],cond) would return [1,1,0] for cond(x): x>4. The case where no elements satisfy the condition would need to return a "signal value" like -1. But maybe there are some weird cases where there isn't a sensible return value, hence why such a function has not been added. -Andrew Rosko

7 13