-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integer /: restrict fallback to same-type case (fix #19714) #19779
Conversation
test case? |
087e4b0
to
2166ec6
Compare
Now with 100% more test case. |
Not to be too pedantic, but if there were zero test cases before, 100% more test cases would still be zero. |
In case this might have performance consequences (probably shouldn't but never know) @nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels |
Performance intuition is hard. Those regressions all look like mixed-type cases with |
The BigInt regression here makes sense, I think, since it constructs an extra BigInt before going to float/float division. I assume the complex division case is also due to the non-complex regression. |
The principle here is that if there's an implementation of a promoted operator for some type and promotions for that type, unless other methods are defined, the operation should always be "funnelled" through the core operator definition for that type. The method for `/(::Integer, ::Integer)` violated that principle since it would take precedence in mixed-integer-type division cases even in the presence of a same-type method definition for a custom integer type and the appropriate promotion rules.
2166ec6
to
d62fe5a
Compare
@nanosoldier |
Your benchmark job has completed - no performance regressions were detected. A full report can be found here. cc @jrevels |
That's nice. |
I probably shouldn't have restarted that CI job since I think this is independent breakage. |
The principle here is that if there's an implementation of a promoted operator for some type and promotions for that type, unless other methods are defined, the operation should always be "funnelled" through the core operator definition for that type. The method for
/(::Integer, ::Integer)
violated that principle since it would take precedence in mixed-integer-type division cases even in the presence of a same-type method definition for a custom integer type and the appropriate promotion rules.