2**63 is converted to a numpy uint64. The comparison int64 < uint64 is undefined, so it promotes to float64 < float64, and the precision is reduced, making them equal.

Perhaps we ought to deprecate the promotion from integers to floats, and just switch to object arrays instead.

Comparison int64 with uint64 sounds at least semantically well-defined to me.

Sure, in this case I simply meant "we don't define it (yet)". uint64 + int64 is a similar case that is actually ill-defined

Well, addition is ambiguous in case of overflow, but comparison is not ;-)

My guess is that numpy is just looking at the types on either side of the operator, and finding a common type to promote them to. Numpy could have been smarter, noticed that this was a comparison operator, and not done that, but, hey, none of us are smart all of the time.

addition is ambiguous in case of overflow

Worse than that, the type of uint + int is ambiguous in all cases.

You're correct that comparison can be perfectly well-defined, but the C compiler won't define it for us sadly.

Closing this one in favor of the related gh-12525. Keeping that open since comparisons are maybe a special case compared to the general promotion problem in gh-20905.