Skip to content
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

Drop "one of" default attribute check in LabelEncoder #5673

Merged
merged 5 commits into from Oct 16, 2023

Conversation

adityagoel4512
Copy link
Contributor

@adityagoel4512 adityagoel4512 commented Oct 16, 2023

Description

Drop "one of" checking on the default value in the LabelEncoder.

Motivation and Context

When implementing LabelEncoder in onnxruntime (for the upcoming ai.onnx.ml opset 4), it became clear that the implemented type inference for LabelEncoder would not work well in practice - specifically, the type inference pass ensures that only one of the default_* attributes is set. Since some of these are optional with default values, this is not very workable in practice. This PR addresses this by dropping this check. Notice that this was not checked in previous opsets anyway.

Signed-off-by: Aditya Goel <agoel4512@gmail.com>
@codecov
Copy link

codecov bot commented Oct 16, 2023

Codecov Report

All modified lines are covered by tests ✅

📢 Thoughts on this report? Let us know!.

Signed-off-by: Aditya Goel <agoel4512@gmail.com>
Signed-off-by: Aditya Goel <agoel4512@gmail.com>
@adityagoel4512 adityagoel4512 changed the title Drop default type check Drop "one of" default attribute check in LabelEncoder Oct 16, 2023
@adityagoel4512 adityagoel4512 marked this pull request as ready for review October 16, 2023 07:03
@adityagoel4512 adityagoel4512 requested a review from a team as a code owner October 16, 2023 07:03
@@ -413,6 +391,21 @@ ONNX_ML_OPERATOR_SET_SCHEMA(
" must be the same in the LabelEncoder.");
}

auto default_attr = ctx.getAttribute("default_tensor");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new test just ensures the consistency of the operator when default_tensor is set. According to the description of the PR, it was failing in any other case. No unit test is failing, so I assume it was not tested. Is it possible to fix the behaviour and add unit test to check it is doing as expected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not quite that. When implementing the operator in ORT, I was finding the type inference fails even if I have only specified one of the default_* attributes. There seems to be to do with the fact that the default_* attributes tend to have values specified since they are optional.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some failure cases are checked here. Is there something you think is missing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All tests involve default_tensor, there is no test to check that a default value is not defined or defined with an unexpected attribute such as (value_int64s, default_floats). A test like that would have failed with your change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no test to check that a default value is not defined

I don't think that is something we want, since the default value has a fallback (e.g. -1 for int64_t) specified in the specification. This is why it is not tested in the previous implementation I believe.

defined with an unexpected attribute such as (value_int64s, default_floats)

I think this will run into the same issues with ORT unfortunately, but I can check.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify Aditya's point (in answer to Xavier's question): since the op-spec specifies a default-value for the various attributes, we need to be careful when flagging an error here: we cannot do that unless we can distinguish whether an attribute-value was explicitly specified in the node, or whether it is getting a default-value from the op-spec. (We should not be flagging an error when we get a default-value from the op-spec.) At the root of this, we have the issue that shape-inference works with the InferenceContext abstract interface, which exposes the getAttribute method. If we want to do such error-checking, we need to extend the interface to distinguish between the two cases mentioned above.)

So, undoing this check makes sense to me. My two cents.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explained much better than me! Thanks

Signed-off-by: Aditya Goel <agoel4512@gmail.com>
@gramalingam
Copy link
Contributor

Just to make sure I understand: I guess the root-cause is some ambiguity in whether ctx.getAttribute automatically handles default-values or not? (I am guessing the behavior is slightly different in onnxruntime.)

@liqunfu liqunfu added this to the 1.15 milestone Oct 16, 2023
@adityagoel4512
Copy link
Contributor Author

adityagoel4512 commented Oct 16, 2023

Just to make sure I understand: I guess the root-cause is some ambiguity in whether ctx.getAttribute automatically handles default-values or not? (I am guessing the behavior is slightly different in onnxruntime.)

When implementing the operator in ORT, I was finding the type inference fails even if I have only specified one of the default_* attributes. I assume this has something to do with the fact that these attributes have default values if not set.

@gramalingam
Copy link
Contributor

@liqunfu : we may need this patch for the ONNX release.

@justinchuby justinchuby added this pull request to the merge queue Oct 16, 2023
Merged via the queue into onnx:main with commit 5f908a9 Oct 16, 2023
37 checks passed
@adityagoel4512 adityagoel4512 deleted the fix-shape-inference branch October 16, 2023 20:38
@liqunfu
Copy link
Contributor

liqunfu commented Oct 16, 2023

Just to make sure I understand: I guess the root-cause is some ambiguity in whether ctx.getAttribute automatically handles default-values or not? (I am guessing the behavior is slightly different in onnxruntime.)

When implementing the operator in ORT, I was finding the type inference fails even if I have only specified one of the default_* attributes. I assume this has something to do with the fact that these attributes have default values if not set.

@adityagoel4512 , I will cherry-pick this pr and a few others to make a rc2. It will take some time to have ort use the rc2. In the meantime you may apply your change local to see if the fix solves your issue in ORT. I know that you are working on quit a few ops in ORT. Please let me know if you see any other issues that need to be fixed before onnx 1.15.0 release. Thank you.

liqunfu pushed a commit that referenced this pull request Oct 17, 2023
### Description
Drop "one of" checking on the default value in the `LabelEncoder`.

### Motivation and Context
When implementing `LabelEncoder` in onnxruntime (for the upcoming
ai.onnx.ml opset 4), it became clear that the implemented type inference
for LabelEncoder would not work well in practice - specifically, the
type inference pass ensures that only one of the default_* attributes is
set. Since some of these are optional with default values, this is not
very workable in practice. This PR addresses this by dropping this
check. Notice that this was [not
checked](https://github.com/onnx/onnx/blob/f556cffc40dc769a2c8e3bb5fd9a90f1e7fbb7eb/onnx/defs/traditionalml/old.cc#L277-L338)
in previous opsets anyway.

---------

Signed-off-by: Aditya Goel <agoel4512@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants