-
Notifications
You must be signed in to change notification settings - Fork 23.3k
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
[JIT] add sorted keyword for lists and dicts #23274
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these should be implemented in operators instead of adding another SugaredValue
, or we should add some mechanism to make composing operators together easier. The ad-hoc schema matching here isn't really a sustainable pattern and this kind of this will probably come up again in the future
|
||
if (inputs.size() != 1) | ||
throw ErrorReport(loc) | ||
<< "sorted currently only accept any keyword arguments"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"only accepts 1 positional argument"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i didn't want to repeat all the code & ad-hoc schema checking that exists for aten::sort
. i think it is more maintanable to compose this in terms of aten::sort
I agree this isn't the most desirable end state, however this is a very special case of a builtin keyword. I don't think there are any other higher-order builtin functions in python. We've had a number of users internally & externally request |
@pytorchbot rebase this please |
@@ -29,6 +29,42 @@ std::shared_ptr<SugaredValue> PrintValue::call( | |||
return std::make_shared<NoneValue>(); | |||
} | |||
|
|||
std::shared_ptr<SugaredValue> SortedValue::call( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think most of this can be implemented in operators as @driazati suggested, you can just modularized/refactor the functions in register_prim_ops and implement the same thing for sorted
as a builtinFunction
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it were implemented in operators i would have to re-implement all of the schema checking within register_prim_ops
that exists for aten::sort
here which isn't very maintainable and should be avoided.
I also implemented it this way because I would like to add support for iterables, which isn't possible if it's not a sugared value. Or if it is i'm not sure how. |
@pytorchbot rebase this please |
@driazati @wanchaol i re-implemented it as a builtin operator. while on some level it would be nice to support dict, i think it would give user confusing belief that we support iterable arguments. since i'm no longer supporting dict (or plan to support iterables specifically through this operator) i did it as a builtin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why we should drop dict
support for this and keep list
support since they're both actual values. Most users understand iterables to be a more advanced feature, but if we're doing lists we should do dicts as well.
int listCopyAndSort(Stack& stack) { | ||
c10::List<T> list = pop(stack).to<c10::List<T>>(); | ||
auto list_copied = list.copy(); | ||
std::sort(list_copied.begin(), list_copied.end(), [](const T& a, const T& b) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the closure really necessary if it's just doing a < b
?
} | ||
|
||
template <typename T> | ||
int listCopyAndSort(Stack& stack) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naming these something like listSort
and listSort_
would be more in line with existing torch naming on in place / out of place ops
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a copy and a mutation, which isn't the same thing as an in place op
bool has_reverse_arg, | ||
bool copy_return_list) { | ||
return [lt_func, has_reverse_arg, copy_return_list](Stack& stack) { | ||
bool reverse = has_reverse_arg ? pop(stack).toBool() : false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The list of bool
args for sort_op
is confusing, this could be handled when the actual op is returned (i.e. here) instead of here which would clean things up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not sure what you mean
listSort<bool>, | ||
aliasAnalysisFromSchema()), | ||
Operator( | ||
"aten::sorted(int[](a) input) -> (int[])", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference between sort
and sorted
isn't very obvious, how about aten::sort
and aten::sort_
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a mapping to a python builtin. It would also be confusing because you would assume aten::sort_
mutates the input, whereas sorted
copies the input and sorts it
The reason |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eellison is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Summary: Add `sorted` keyword to JIT for lists and dicts. This desugars to a list copy and a call to `list.sort()`. Since we don't have interfaces yet I implement it in terms of `list.sort()`. When we do we can re-visit implementing this op in a different manner. The test fails bc of a fix to specialized lists which is landing here: pytorch/pytorch#23267 Ignore the first commit because it is formatting, plz use clang_format ppl :'( Pull Request resolved: pytorch/pytorch#23274 Differential Revision: D16527323 Pulled By: eellison fbshipit-source-id: aed8faef23cb790b9af036cd6c1b9b1d7066345d
Add
sorted
keyword to JIT for lists and dicts. This desugars to a list copy and a call tolist.sort()
. Since we don't have interfaces yet I implement it in terms oflist.sort()
. When we do we can re-visit implementing this op in a different manner.The test fails bc of a fix to specialized lists which is landing here: #23267
Ignore the first commit because it is formatting, plz use clang_format ppl :'(