What will happen with complex input?

@mattip this only promotes integer inputs (Python scalar integer, actually), so the rest would stay the same?

Thanks a for looking at this, this is very cool to see this use!

I am curious if we can push this further and actually use the promoter always. That is, we:

• Set the first and last dtype to PyArray_CommonDType(first_dtype, AbstractFloatDType):
  • If the last was forced, we just set the first to that instead.
  • Yes, we ignore the second (integer) argument here considering how it is currently defined.
• Set the second dtype to PyArray_CommonDType(second_dtype, int_dtype). That just seems like it always works in practice, so I don't really feel a need to do something more complicated.

Thanks, that extension makes a lot of sense!

I tried implementing this, but it causes a segmentation fault. It seems to be due to the fact that common_dtype is not defined on FloatPyArray_FloatAbstractDType (in the dtypemeta declaration). I'm wondering if the abstract classes support the common dtype operation yet? (I assume the python integers won't be the ones casting up to floats)

Edit: that does seem to be it; reverting the operation for the first dtype and setting the others in this way doesn't crash (though of course the promotion doesn't work properly)

Oh, hmmm, the pyfloat one should work ok probably, although the abstract version woukd be nicer.

PyFloat doesn't seem to work well oddly, but Float does. I've pushed that, but yeah it's not as nice. It could be interesting to look into supporting common_dtype more fully for the abstract types if you'd like!