:Author: <list of authors' real names and optionally, email addresses> :Status: <Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded> :Type: <Standards Track | Process> :Created: <date created on, in yyyy-mm-dd format> :Resolution: <url> (required for Accepted | Rejected | Withdrawn) Abstract We are moving the SIMD intrinsic framework, Universal Intrinsics, from C to C++. We are also moving to meson as a build system. The Google Highway intrinsics project is proposing we use Highway instead of our Universal Intrinsics as describe in NEP 38_. and this NEP is an attempt to describe what needs to be done. Motivation and Scope

Originally proposed in issue 5744, and on the mailing list. The motivation seem a bit unclear. There is a clear use case for this in simulating quantum systems. While 64 is better than 32, it is not clear that will be the end of this discussion. In the issue there is a suggestion to make the limit dynamic. In PyArrayObject the value is not used, but it is used heavily in the structs behind PyArrayIterObject. PyArrayMultiIterObject, PyArrayMapIterObject, PyArrayNeighborhoodIterObject. It is also used as a shortcut in code like npy_intp dimensions[NPY_MAXDIMS]; for (i=0; i<PyArray_NDIMS(arr); i++) { dimensions[i] = PyArrayDIMS(arr, i); } /* Some code that broadcasts or otherwise manipulates "dimensions" */ ret = new_array(..., dimensions, ...); SciPy has about 30 such uses.

Today np.int_ reflects the C long type, which is 32-bits for MSVC (windows) and 64-bits on all other 64-bit platforms, and 32-bits on 32-bit platforms. The relevant issues discussing this: 9464, 12332, 17531 (which points out that the canonical name for np.int32 on win64 is np.intc), 17640 18540 Implications for Array API compatibility Under Dtypes, the Array API spec says: The default integer data type should be the same across platforms, but the default may vary depending on whether Python is 32-bit or 64-bit. So this change would bring NumPy into compliance with the Array API Who is in favor?

Even with all the checks added for MaskedArrays inside NumPy code, there are still issues around properly propogating masks. In PR 22914, @greglucas proposed adding MaskedArray.__array_ufunc__ building on work done in other PRs that were subsequently reverted. On the mailing list, Allan Haldane announced a third-party implementation of MaskedArray using __array_function__ https://github.com/ahaldane/ndarray_ducktypes. The post mentions two open problems: what to do about the mask of arr.imag = MaskedArray([1,X,1]) how to ducktype scalars when using __array_function__ ? Do we always need an associated "MaskedScalar" type? In the PR, @greglucas says: My desires from a new class:

Using the Sail RISC-V model for emulation and testing currently has significant downsides compared to other existing emulators for RISC-V, such as Spike or QEMU. Specifically, the Sail-based emulators are 1000x-5000x slower, which makes them unworkable for many applications. This is one of the main pain-points of using the Sail model in RISC-V development. Pydrofoil (PyPy's Sail backend) [1] significantly increases the speed of the RISC-V Sail model. However, Pydrofoil is not currently easily usable by the RISC-V community: it is not documented and hard to use by anyone except the authors. In this work package we propose to provide build tooling,