Consistent default integer and floating-point types

In today’s call we discussed that the current Array API standard does not regulate the default integer and floating-point types across all implementations, only that each implementation should pick one, document clearly and stick to it. However, this is not strong enough, as there could be cross-platform/portability issues.

For example, NumPy is inconsistent in handling the Python integers between Windows and Linux:

import numpy as np
a = np.arange(10, dtype=int)
a.dtype  # np.int32 on Windows, np.int64 on Linux

Similar issues can be found in other APIs.

It’s worth noting that as pointed out by @kgryte, the standard does not permit passing dtype=int to most of the functions, so this could eliminate a large class of such inconsistencies. But it’s still good to be explicit in the standard to ensure portability.

[rgommers]

This should be addressed in gh-167. I did put in one exception for default integers: for 32-bit vs. 64-bit Python. It’s possible to avoid too of course, but it’d be a fairly large change for limited benefit. So “may vary” on 32-bit seems okay.

[asmeurer]

No, I think asarray(1) should definitely have an integer dtype. But which integer dtype should it be? All it says is “If dtype is None, the output array data type must be inferred from the data type(s) in obj” which isn’t clear. To me it even leaves open the possibility of value-based casting, which I think we want to avoid.