BUG: <```uint64 dtype``` is broken for ```Max```> about pytensor

[aseyboldt]

Consider me intrigued...
Sounds like somewhere there is a conversion to float64, because that exact number is one bigger than the largest integer a float64 can represent exactly:
np.float64(9223372036854775).astype(np.int64) is our magic 9223372036854776.

[aseyboldt]

This seems to have been around for a long time.
The maximum and minimum are implemented as CAReduction (pytensor.scalar.basic.ScalarMaximum). There seem to be two problems with this implementation: Both scalar Ops specify inf and -inf as identity element, but if we are working with integer types, those do not even have an identity.
But the direct source of the bug seems to be this generated C-Code:

        return f"{z} = (({y})>({x})? ({y}): " f'(({x})>=({y})? ({x}): nan("")));'

It tries to ignore nans, but by doing so it implicitly converts the intermediate values to floats.

I guess it might make sense to split the ScalarOps: One for floats (where we have an identity) and one for ints (where we don't). And then use the nan-check only for floats.

edit

This was introduced here: aesara-devs/aesara#297

[ricardoV94]

The conversion story makes sense. Regarding infty, the code actually initializes those to zero when it's (u)integers.

The number thing was not a hard cutoff. It starts working with larger values and then fails again. In case that helps.

And yes this bug is likely there for a while but was hidden when the max/min could be constant folded, triggering the C implementation of MaxAndArgmax instead which just calls numpy C code and handles it correctly.