BUG: Remove complex floor divide#19135
Conversation
…rts for divmod and remainder
| dtype=float_dtype) | ||
| assert_equal(zm.min(), float_dtype(-np.inf-1j)) | ||
| assert_equal(zm.max(), float_dtype(np.inf+2j)) | ||
There was a problem hiding this comment.
I really need to change my .vimrc one day
32582d8 to
d4765ee
Compare
|
@kaivu1999 didn't cross my mind to check with you before raising this. If you see this before the review for this code is done, please feel free to re-open your PR and add the extra changes I have made to fix the tests. |
BvB93
left a comment
There was a problem hiding this comment.
There are a couple of places in the stub files that still contain references to complex floordivision:
Lines 2310 to 2311 in 9fcc132
Lines 2338 to 2339 in 9fcc132
Lines 3258 to 3259 in 9fcc132
The same holds for the typing tests in reveal/arithmetic.py and pass/arithmetic.py.
|
Thanks @BvB93, I'll remove those as well. I wanted to understand how and where the three references in |
Yeah, that makes sense actually. Each of these Complex is at the end of this tree though (as it cannot be safely cast into any other type), so removing it means that complex operations are no longer allowed. Lines 2016 to 2021 in 9fcc132 |
|
Thanks! Always wondered where the casting order is taken care for arrays. |
672fb9f to
f59e225
Compare
|
Hey folks, any changes needed here? |
mattip
left a comment
There was a problem hiding this comment.
Do we know if this will have implications for scipy/astropy/pandas?
|
Will building them with this branch of NumPy help? Will be happy to do so. |
|
Thanks @ganesh-k13 .Lets get this in for testing at least. |
Changes:
floor_dividefor all complex typesfloor_divdeTC to check forTypeError. Added same for divmod and remainder.test_coreto checkTypeErrorraised for unsupported types.TODO:
closes: #13236
finishes: #13245 (work done by @kaivu1999)