numpy 2.0 possible type change for codegen

[ptheywood]

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.

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 numpytypes in codegen.py, conditional on the numpy version, possibly just int_ mapping to a different value.

FLAMEGPU2/swig/python/codegen/codegen.py

Lines 45 to 77 in b5173e7

	numpytypes = {"byte": "char",
	"ubyte": "unsigned char",
	"short": "short",
	"ushort": "unsigned short",
	"intc": "int",
	"uintc": "unsigned int",
	"uint": "unisgned int",
	"longlong": "long long",
	"ulonglong": "unsigned long long",
	"half": "half", # cuda supported
	"single": "float",
	"double": "double",
	"longdouble": "long double",
	"bool_": "bool",
	"bool8": "bool",
	# sized aliases
	"int_": "long",
	"int8": "int8_t",
	"int16": "int16_t",
	"int32": "int32_t",
	"int64": "int64_t",
	"intp": "intptr_t",
	"uint_": "long",
	"uint8": "uint8_t",
	"uint16": "uint16_t",
	"uint32": "uint32_t",
	"uint64": "uint64_t",
	"uintp": "uintptr_t",
	"float_": "float",
	"float16": "half",
	"float32": "float",
	"float64": "double"
	}

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?