Numpy 2.0 is scheduled for release on 2024-06-16, with a number of breaking changes.
From a quick skim of the migration guide the only stand out potentially relevant bit to pyflamegpu is a tweak to the default interger type.
The default integer used by NumPy is now 64bit on all 64bit systems (and 32bit on 32bit system). For historic reasons related to Python 2 it was previously equivalent to the C long type. The default integer is now equivalent to np.intp.
...
Libraries interfacing with compiled code that are written in C, Cython, or a similar language may require updating to accommodate user input if they are using the long or equivalent type on the C-side. In this case, you may wish to use intp and cast user input or support both long and intp (to better support NumPy 1.x as well). When creating a new integer array in C or Cython, the new NPY_DEFAULT_INT macro will evaluate to either NPY_LONG or NPY_INTP depending on the NumPy version.
This might require no changes, but at a glance it might require changes to numpytypes in codegen.py, conditional on the numpy version, possibly just int_ mapping to a different value.
Additionally, we may need to check on our use of char in numpy mappings, as char is implementation defined to be either signed char (i.e. x86_64) or unsigned char (i.e. aarch64, excluding apple).
I.e. we should probably change byte in numpytypes to be an explicit signed char for correct behaviour on aarch64. (i.e. grace hopper).
We might need to do wider char checks in general.
uint is also mapped to long not unsigned long currently which might be incorrect?
Numpy 2.0 is scheduled for release on 2024-06-16, with a number of breaking changes.
From a quick skim of the migration guide the only stand out potentially relevant bit to pyflamegpu is a tweak to the default interger type.
The current (2024-06-03) dev docs has a table
https://numpy.org/devdocs/user/basics.types.html#relationship-between-numpy-data-types-and-c-data-data-types
This might require no changes, but at a glance it might require changes to
numpytypesin codegen.py, conditional on the numpy version, possibly justint_mapping to a different value.https://github.com/FLAMEGPU/FLAMEGPU2/blob/b5173e78765d03be8d1b393f8a037499b064b676/swig/python/codegen/codegen.py#L45-L77
Additionally, we may need to check on our use of
charin numpy mappings, ascharis implementation defined to be eithersigned char(i.e. x86_64) orunsigned char(i.e. aarch64, excluding apple).I.e. we should probably change
byteinnumpytypesto be an explicitsigned charfor correct behaviour on aarch64. (i.e. grace hopper).We might need to do wider
charchecks in general.uintis also mapped tolongnotunsigned longcurrently which might be incorrect?