fix a bug in infer method #1340
Conversation
jlsong01
requested review from
workingloong,
samplise,
BalaBalaYi and
majieyue
as code owners
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1340 +/- ##
==========================================
- Coverage 81.15% 81.11% -0.04%
==========================================
Files 231 231
Lines 21965 21965
==========================================
- Hits 17825 17817 -8
- Misses 4140 4148 +8 ☔ View full report in Codecov by Sentry. |
| @@ -46,7 +46,7 @@ def infer(self) -> List[Inference]: | |||
| operator = self.get_operator(inference) | |||
| if not operator: | |||
| continue | |||
| infs = operator.infer(inferences) | |||
| infs = operator.infer([inference]) | |||
There was a problem hiding this comment.
This implementation will be more accurate in some cases. For example, we have observed two problems a and b during training. We want to identify the root causes for problem a. However, the final results may differ for only observed a from observed a and b together. Therefore we have all problems as the input for more accurate analysis.
There was a problem hiding this comment.
Thanks for the comments.
-
I agree having all problems is better for more accurate analysis.
-
the further question is, instead of passing all problems in a list, maybe it's better to separate the current problem with the other problems. Because the current operator cares more about the current problem than the others. If we pass them all in one list, the above information will be lost
-
Currently some infer() implementation ALWAYS refer to problems list[0] only, this isn't what we expected, right?
There was a problem hiding this comment.
@samplise how about the comment?
What changes were proposed in this pull request?
a bugfix
Why are the changes needed?
the parameter of operator.infer() SHOULD be a list with one element [inference], while NOT the whole list of inferences, because inferences may include the inference which does not match the currrent operator.
Does this PR introduce any user-facing change?
No
How was this patch tested?
pre-commit test and unittest both passed