Skip to content
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.

Fix InferType logic - add backward inference for some ops #16817

Closed
wants to merge 2 commits into from
Closed

Fix InferType logic - add backward inference for some ops #16817

wants to merge 2 commits into from

Conversation

anirudh2290
Copy link
Member

Description

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

  • The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
  • Changes are complete (i.e. I finished coding on this PR)
  • All changes have test coverage:
  • Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
  • Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
  • Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
  • Code is well-documented:
  • For user-facing API changes, API doc string has been updated.
  • For new C++ functions in header files, their functionalities and arguments are documented.
  • For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
  • Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
  • To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

  • Feature1, tests, (and when applicable, API doc)
  • Feature2, tests, (and when applicable, API doc)

Comments

  • If this change is a backward incompatible change, why must this change be made.
  • Interesting edge cases to note here

ptrendx
ptrendx reviewed Nov 16, 2019
View reviewed changes
src/operator/contrib/deformable_convolution-inl.h
}
}
out_type->clear();
out_type->push_back(dtype);
Copy link
Member

Choose a reason for hiding this comment

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

Wow, this would just discard the type inferred by the other operators...

Copy link
Member Author

Choose a reason for hiding this comment

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

yep, many operators behave this way. probably more than what we have captured in the issue list :)

Copy link
Member

Choose a reason for hiding this comment

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

Seems that the logic for type/shape inference in operators really needs to be looked at. I have another issue (and PR with a fix) coming today about how it is currently possible to not let the operator check their input and output attributes (and there should be also another how operators lie in their infertype/shape about whether they successfully inferred everything or not).

@anirudh2290
Copy link
Member Author

closing this, since I am not working on this currently. If someone is interested in picking this up, please go ahead.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@ptrendx ptrendx ptrendx left review comments

@szha szha Awaiting requested review from szha szha is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Infer Type issue when dtype passed is None
2 participants
@anirudh2290 @ptrendx