Is this really desirable?

>>> np.can_cast(np.int64, np.float64, casting='safe')
True

‘safe’ means only casts which can preserve values are allowed.

Clearly though, in our case the value was not preserved

Note that uint64 + int64 returns float64. That is an old decision/compromise due to the fact that no numpy integer type can contain both. I suppose that other options would be to return object arrays containing Python ints or at least raise a warning. Python ints convert as signed, which adds to the problem.

The compromise does seem particularly broken for comparison operators, since for those there is no need to upcast to get the correct answer. @eric-wieser - possibly here too one might want a separate uint, int inner loops?

possibly here too one might want a separate uint, int inner loops?]

Can we just do this everywhere? Obvious candidates:

• power(uint, int) -> uint and power(int, uint) -> int (BUG: Prevent power(uint64, int64) casting to float #8853)
• some_comparison(uint,int) -> bool (and swapped)
• true_divide(uint, int) -> float (and swapped) - why waste memory copying and casting an array to double first?

I guess it's not clear whether int64 + uint64 should be signed or unsigned.

I'd be in favor of disabling safe casting from u?int64 -> float64 everywhere, and adding explicit loops in the few cases where we decide conversion to float is desirable

Similar: #5746

I'd like to have a look at how to patch comparisons for uint64 and int64 (this would be a cleaner solution to the bug I'm patching in #8846). Where is that code located?

Okay, it's going to be somewhat trickier than I thought. The code for creating ufunc objects in numpy is generated, and that logic is quite complex. You can start here:

https://github.com/numpy/numpy/blob/master/numpy/core/code_generators/generate_umath.py#L407-L442

You will see that all of the comparisons have a simple type_resolver function that you will likely need to replace. They also have a single TD() (a convenience function that makes TypeDescription objects) that encompasses all of the dtypes. You will need to add some more TypeDescriptions that deal with the mixed signedness of the integers. I think you can just add them after the TD() that's there; the order is important, but I think that appending the new mixed-sign functions at the end will do the job. You can look at the specifications for add and multiply, etc. to see how it deals with mixed-type binary operations for the datetime dtypes.

The functions that you actually implement are here:

https://github.com/numpy/numpy/blob/master/numpy/core/src/umath/loops.c.src#L916-L932

As you can see, they are also generated through an ad-hoc templating system. I'm not sure if you'll be able to make much use of the templating system; I expect the code will look different for each of the cases. In any case, make sure the functions you add are also declared in loops.h.src.

The TypeDescriptions that you add will have to use FuncNameSuffix(...) to specify each function for obscure reasons. You can't just specify the name of the function, because that's interpreted as specifying a function that gets called with each scalar operand rather than specifying one of these loop functions. You can't use the FullTypeDescr sentinel value like the datetime TypeDescriptions do because that expects the function names to look like LONG_lL_?_equal() (that is, the nominal type name, the input typecodes, and the output typecode) because ? is not a valid character to use in a C function name. So use something like FuncNameSuffix('mixedsign') and name your functions LONG_equal_mixedsign, ULONG_equal_mixedsign, etc.

Or you can add a new branch in this bit of code here to deal with whatever new scheme you come up with: https://github.com/numpy/numpy/blob/master/numpy/core/code_generators/generate_umath.py#L919-L964

@gfyoung: Take a look at #8853 for an example of adding these loops. Everything @rkern said above should apply too. It might be worth adding some special handling to make ? map the the word bool so that FullTypeDescr works as expected

Of particular note - you need to handle both LONG op ULONG and LONGLONG op ULONGLONG, because both of these are sometimes 64 bits.

Is anyone still working on this?

>>> np.can_cast(np.int64, np.float64, casting="safe")
True

@umanwizard , I filed #13733 for that separately.

@dcolascione FWIW it's discussed in this present thread, in Eric's comment

Ah, okay. Thanks!

Closing in favor of gh-12525, but stealing the clearer title :).