Repository navigation
Add numpy argpartition function support - #8732
Conversation
There was a problem hiding this comment.
Hi @rragundez , Thank you for the PR 😄 . Your contributions to Numba are highly appreciated.
I gave the PR an initial review and it mostly LGTM!
A few points to note:
-
The logic does seem a bit off within the
_partition_factory/_partition, but as you mentioned and from a maintainer's point of view, it's less code to manage and reuses existing logic so it does makes sense to keep it this way. -
The
np.argpartition, based on the existingnp.partitionlogic does seem to deviate from NumPy behaviour, they are implemented using different algorithms (see #3320 (comment) for originalnp.partitionimplementation discussion) and whilst this might seem a bit implicit, since the ordering of the elements in the two partitions is supposed to be undefined, but it might be a good idea to mention the behaviour in the docs that the outputs may deviate from NumPy.
kc611
left a comment
There was a problem hiding this comment.
A small suggestion regarding default function arguments.
On this note is there any particular reason you went with the default argument for idx being np.arange(0) ?
|
@kc611 Thanks for your review and feedback. |
|
@kc611 Hi, did you have time to check my remark? perhaps I am wrong but that behaviour I describe is what I noticed when developing the PR. |
|
Hi @rragundez, apologies for the delay. Following a small internal discussion, it'd be better for us to go with Additionally, the type inference within Numba is expected to figure out if the argument type is |
|
@kc611 Yeap, agree with the Python anti-pattern. I will make the changes and let's see what the the CI says, hopefully I made come mistake when testing and it will be able to resolve the |
|
@kc611 done, please review. I think the CI is failing with an issue related to what I mentioned above, let me know what should I do to solve it or if I should revert back. Thanks. |
|
@kc611 By the way I just remembered that indeed is a bad practice to set default parameters that are mutable but even though numpy arrays are mutable, an array of size 0 is immutable because it has no elements to change, and numpy arrays are of fixed size, therefore the default value of an int array of size zero is immutable. Let me know if this makes sense and how you would like me to proceed. |
There was a problem hiding this comment.
Hi @rragundez , Thank you for making the changes. 😃 . I think the reason for failure is that Numba isn't able to infer I as None during compile time and ends up trying to lower the branches with argpartition boolean. A way around this would be to make argpartition a compile time constant instead of runtime, this would make sure branch pruner absolutely removes the branches with the given boolean so that they aren't lowered into IR.
I agree that an array of size 0 is immutable because it has no elements to change, but we can actually change it's attributes making it a 'mutable as a structure'. 🙂 However, the issue at hand is that this practice is generally not recommended and even more so in Numba because it might lead to weird and unexpected IR issues down the line, even if it seems to work just fine right now.
|
@kc611 thanks for the feedback. I made the requested changes and the CI is passing now. Please review. |
kc611
left a comment
There was a problem hiding this comment.
Thanks @rragundez, these changes LGTM!
|
@kc611 Thanks for the approval. I cannot merge though, still says "Merging is blocked Merging can be performed automatically with 1 approving review." |
|
Hi @kc611, can you help me understand if this PR will be able to be merged? Thanks. |
Add numpy argpartition function support.
I used some of the implementation of
partition. Something to note it that I modified the already existing_partition_factoryto add an optional argument if the user would neednp.argpartitioninstead ofnp.partition, as you will see in the code it doesn't look the most pretty, but it was either that or write a_argpartition_factoryfunction which has exactly the same logic it just swaps index elements at the same time it swaps the array with the values being sorted.Let me know if you prefer to leave it as is or go the duplication route. I think this is the best compromise to not repeat code and have a single source of truth of partition logic.
Solves #2445
#4074 would need to be updated.
cheers