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

[Fix] fix np.arange() output not stable error #1749

Open
wants to merge 4 commits into
base: dev-1.x
Choose a base branch
from

Conversation

KevinNuNu
Copy link
Contributor

@KevinNuNu KevinNuNu commented Feb 27, 2023

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.

Motivation

mmocr中pred_score_thrs生成的范围需要包含stop值,然而使用np.arange可能会因为浮点型数值精度问题导致不包含stop值。
image

https://numpy.org/doc/stable/reference/generated/numpy.arange.html
numpy官方也提示了这个潜在的问题是因为函数内部实现导致,并且建议如果要使用non-integer step最好还是使用numpy.linspace().

Modification

使用np.linspace(start, stop, int(np.round((stop - start) / step)) + 1, endpoint=True)替换np.arange(start, stop, step)

BC-breaking (Optional)

Does the modification introduce changes that break the backward-compatibility of the downstream repositories?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.

Use cases (Optional)

If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.

Checklist

Before PR:

  • I have read and followed the workflow indicated in the CONTRIBUTING.md to create this PR.
  • Pre-commit or linting tools indicated in CONTRIBUTING.md are used to fix the potential lint issues.
  • Bug fixes are covered by unit tests, the case that causes the bug should be added in the unit tests.
  • New functionalities are covered by complete unit tests. If not, please add more unit test to ensure the correctness.
  • The documentation has been modified accordingly, including docstring or example tutorials.

After PR:

  • If the modification has potential influence on downstream or other related projects, this PR should be tested with some of those projects.
  • CLA has been signed and all committers have signed the CLA in this PR.

@KevinNuNu
Copy link
Contributor Author

但个人感觉以这种方式解决问题self.pred_score_thrs获取值得代码没有之前的优雅

@codecov
Copy link

codecov bot commented Feb 27, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: -1.10 ⚠️

Comparison is base (9e713c6) 89.18% compared to head (8fc6201) 88.08%.

❗ Current head 8fc6201 differs from pull request most recent head 7eeb94d. Consider uploading reports for the commit 7eeb94d to get more accurate results

Additional details and impacted files
@@             Coverage Diff             @@
##           dev-1.x    #1749      +/-   ##
===========================================
- Coverage    89.18%   88.08%   -1.10%     
===========================================
  Files          193      176      -17     
  Lines        11316    11022     -294     
  Branches      1608     1558      -50     
===========================================
- Hits         10092     9709     -383     
- Misses         903     1022     +119     
+ Partials       321      291      -30     
Flag Coverage Δ
unittests 88.08% <100.00%> (-1.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
mmocr/evaluation/metrics/hmean_iou_metric.py 93.33% <100.00%> (ø)

... and 53 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Copy link
Collaborator

@gaotongxiao gaotongxiao left a comment

Choose a reason for hiding this comment

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

This PR also changes the definition of stop a bit by excluding it from the range, but I don't think it's a good idea.

  1. Breaking backward compatibility without sufficient reasons is not encouraged, since users might get a different result with the same config. And for now I don't see outstanding reasons for this change.
  2. If we apply this change, we have to manually shift the stop point a bit if we want to filter the results with the original ending threshold. This becomes weirder when we want the threshold to stop at 1.

Therefore, it's better to roll back this definition change and stick to the old behavior.

Comment on lines 76 to 78
int(
np.round((pred_score_thrs['stop'] - pred_score_thrs['start']) /
pred_score_thrs['step'])),
Copy link
Collaborator

Choose a reason for hiding this comment

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

How about int((pred_score_thrs['stop'] - pred_score_thrs['start']) // pred_score_thrs['step'])

Copy link
Contributor Author

@KevinNuNu KevinNuNu Apr 10, 2023

Choose a reason for hiding this comment

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

It still can not include "stop" when using "start=0.3, stop=0.9, step=0.1".
Using np.linspace(start, stop, int(np.round((stop - start) / step)) + 1, endpoint=True) can fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants