I think this is by design, things like indices / strides / repeat numbers are expected to be of type intp, and anything else is cast. In this case, the casting is "safe", meaning it refuses to cast uint64 to int64 as it would corrupt values >= 2**63.

Performing the cast yourself with a less strict casting rule (such as .astype(np.intp)) would solve your issue, while performing the same number of casts.

I can't comment on Python/Numpy design preferences, I just thought uint could be used for repeats, this would have to bypass the check for negative values, and there would be no need for casting, since uint64 is already the same (on many architectures) as the uintptr_t from stdint.h.

I already used .astype(np.int) for casting and I will consider using 'intp`.

Feel free to close this issue.

You should never use np.int, as it's just a really bad spelling of int (#6103). If you mean the C long type, use np.int_ (which is the complement to np.uint, the C unsigned long type).

Internally, numpy has chosen to use intptr_t (np.intp) almost everywhere, staying away from uintptr_t (np.uintp). This is partially motivated by the need for negative strides, but probably mostly just for simplicity.

I don't want to close this issue just yet, I agree your use-case is fairly reasonable.

this would have to bypass the check for negative values

Right, but you wouldn't actually get an efficiency gain here because instead we'd need to perform a check that all values are less than 2**63 before casting internally to intp.

In most of these places we do use same kind casting. That is arguably incorrect of course, but unfortunately not being able to index e.g. with a uint64 would be strange as well. The only fix would be to have a whole code path(s) around bounds-checking for different integer types.