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

feat: added range onnx import #1834

Merged
merged 4 commits into from
May 31, 2024

Conversation

JachymPutta
Copy link
Contributor

@JachymPutta JachymPutta commented May 28, 2024

Checklist

  • Confirmed that run-checks all script has been executed.
  • Made sure the book is up to date with changes in this PR.

Changes

Add the range import to onnx

Testing

cargo test range

Related Issue

#1714

@JachymPutta JachymPutta force-pushed the jp/range_onnx_import branch 2 times, most recently from 62ae485 to dfd0290 Compare May 28, 2024 21:51
@JachymPutta JachymPutta force-pushed the jp/range_onnx_import branch from dfd0290 to 99f0f56 Compare May 29, 2024 16:51
@JachymPutta JachymPutta marked this pull request as ready for review May 29, 2024 16:53
@JachymPutta JachymPutta force-pushed the jp/range_onnx_import branch from a8787df to d1f883a Compare May 29, 2024 17:03
@JachymPutta JachymPutta force-pushed the jp/range_onnx_import branch from d1f883a to 9dcc11a Compare May 29, 2024 17:33
Copy link

codecov bot commented May 29, 2024

Codecov Report

Attention: Patch coverage is 98.38710% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 86.44%. Comparing base (13a6f84) to head (0a2530c).
Report is 1 commits behind head on main.

Files Patch % Lines
crates/burn-import/src/onnx/dim_inference.rs 91.66% 1 Missing ⚠️
crates/burn-import/src/onnx/to_burn.rs 95.65% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1834      +/-   ##
==========================================
+ Coverage   86.42%   86.44%   +0.02%     
==========================================
  Files         761      762       +1     
  Lines       87987    88111     +124     
==========================================
+ Hits        76041    76166     +125     
+ Misses      11946    11945       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@antimora antimora requested review from laggui and antimora May 29, 2024 18:04
Copy link
Member

@laggui laggui left a comment

Choose a reason for hiding this comment

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

Good job! 🙂

I have one minor request over form when checking the types, otherwise looks good to me.

Comment on lines 27 to 49
let start = match &self.start {
Type::Scalar(s) => {
let name = s.name.clone();
quote! { #name }
}
_ => panic!("Start must be a scalar"),
};

let end = match &self.end {
Type::Scalar(s) => {
let name = s.name.clone();
quote! { #name }
}
_ => panic!("End must be a scalar"),
};

let step = match &self.step {
Type::Scalar(s) => {
let name = s.name.clone();
quote! { #name }
}
_ => panic!("Step must be a scalar"),
};
Copy link
Member

Choose a reason for hiding this comment

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

If the three fields are all supposed to be scalar, I suggest we change the node fields to:

pub struct RangeNode {
    pub start: ScalarType,
    pub end: ScalarType,
    pub step: ScalarType,
    pub output: TensorType,
}

and the logic to check the extract the scalar types can go in the range_conversion.

Copy link
Member

@laggui laggui May 30, 2024

Choose a reason for hiding this comment

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

Well yes, scalars are simply represented as 0-dim tensors. Basically what I am suggesting is just to move the type handling outside of the forward node method to the range_conversion function instead, a bit like this:

  fn range_conversion(node: Node) -> RangeNode {
      let output = node.outputs.first().unwrap().to_tensor_type();
      let start = node.inputs.first().unwrap().to_type();
      let end = node.inputs.get(1).unwrap().to_type();
      let step = node.inputs.get(2).unwrap().to_type();

      // Check/convert start, end & step to ScalarType just as it was done in the forward method
      // ...

      RangeNode::new(start, end, step, output)
  }

@JachymPutta
Copy link
Contributor Author

Should be good

Copy link
Member

@laggui laggui left a comment

Choose a reason for hiding this comment

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

LGTM! 🚀

@JachymPutta JachymPutta force-pushed the jp/range_onnx_import branch from 00f70a9 to 0a2530c Compare May 31, 2024 21:06
Copy link
Collaborator

@antimora antimora left a comment

Choose a reason for hiding this comment

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

LGTM

Thank you for your contribution!

@antimora antimora merged commit 44f1053 into tracel-ai:main May 31, 2024
14 checks passed
LilDojd pushed a commit to LilDojd/burn that referenced this pull request Jun 5, 2024
* feat: added range onnx import

* fix: range input types
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.

3 participants