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

adopt torch.testing.assert_close #1031

Merged
merged 5 commits into from Jun 27, 2021
Merged

Conversation

pmeier
Copy link
Contributor

@pmeier pmeier commented May 24, 2021

Closes #1029. torch.testing.assert_close will only be shipped with torch==1.9. Thus, this PR should not be merged before.

All files except for test/utils.py are 1-to-1 ports and probably do not need special review, but I let you be the judge of that.

test/utils.py Outdated Show resolved Hide resolved
@shijianjian
Copy link
Member

Just one quick question, would it break the backward compatibility in the CI?

@pmeier
Copy link
Contributor Author

pmeier commented May 25, 2021

Just one quick question, would it break the backward compatibility in the CI?

No, it won't. I've backported it using torch.testing.assert_allclose in case torch.testing.assert_close is not available.

@edgarriba
Copy link
Member

thanks @pmeier ! this is a great contribution from the pytorch team :)

@edgarriba edgarriba added enhancement 🚀 Improvement over an existing functionality 2 Priority 2 😅 Medium priority code heatlh 💊 Improvement the package code health labels May 31, 2021
@Borda
Copy link
Contributor

Borda commented Jun 1, 2021

No, it won't. I've backported it using torch.testing.assert_allclose in case torch.testing.assert_close is not available.

so is torch.testing.assert_close missing in torch<1.9?

@pmeier
Copy link
Contributor Author

pmeier commented Jun 1, 2021

so is torch.testing.assert_close missing in torch<1.9?

Yes. It will be shipped the first time with torch==1.9.0.

@Borda
Copy link
Contributor

Borda commented Jun 1, 2021

so is torch.testing.assert_close missing in torch<1.9?

Yes. It will be shipped the first time with torch==1.9.0.

co can you run all these updated tests in past PT 1.7 for example?

@pmeier
Copy link
Contributor Author

pmeier commented Jun 1, 2021

The CI already does that, doesn't it?

@Borda
Copy link
Contributor

Borda commented Jun 1, 2021

The CI already does that, doesn't it?

that is something that makes me suspicious, how it can use a future function which is not existing in that codebase? 😕

well, the multi-version is not running on PR so that is why it is passing...

on:
push:
branches:
- master
# pull_request:
schedule:
- cron: "0 4 * * *"

@edgarriba
Copy link
Member

@pmeier @Borda we disabled mult-version in the CI to lighten the load

@pmeier
Copy link
Contributor Author

pmeier commented Jun 1, 2021

@Borda See #1031 (comment)

torch.testing.assert_close will only be shipped with torch==1.9. Thus, this PR should not be merged before.

I've just prepared the PR so this is ready when kornia officially supports torch==1.9. I can confirm that it runs fine with the pre-release, but we need for CI to confirm that as soon as it is able to.

@edgarriba
Copy link
Member

I guess that the point of @Borda is that will this PR won't have backward compatibility

@pmeier
Copy link
Contributor Author

pmeier commented Jun 1, 2021

Why wouldn't it? CI is green right now for all the older versions.

@edgarriba
Copy link
Member

edgarriba commented Jun 1, 2021

@pmeier you are right. Was confused by a moment with @Borda comment. The PR runs on a lighter version of the full version matrix. See: https://github.com/kornia/kornia/blob/master/.github/workflows/tests_cpu.yml#L50

@Borda what was your point here ? 🤔

@Borda
Copy link
Contributor

Borda commented Jun 1, 2021

I've just prepared the PR so this is ready when kornia officially supports torch==1.9.

But we cannot use it till Kornia will set 1.9 as min version...

@Borda what was your point here ? 🤔

As mentioned, the CI for PR will pass but not on mater, and you can't test any older PT versions anymore...

The PR runs on a lighter version of the full version matrix.

So how is it possible that your tests are using function that shall not exist in the particular PT version?

@pmeier
Copy link
Contributor Author

pmeier commented Jun 2, 2021

@Borda before we continue this cycle, please have a look at the file test/utils.py that will be added by this PR.

I've just prepared the PR so this is ready when kornia officially supports torch==1.9.

But we cannot use it till Kornia will set 1.9 as min version...

We can use it for all CI runs that run on torch>=1.9. Currently, there is no such run, but there will be in the near future.

@Borda what was your point here ? thinking

As mentioned, the CI for PR will pass but not on mater, and you can't test any older PT versions anymore...

Of course it will pass on master. I did not touch the minimum requirement of torch and the CI is green.

The PR runs on a lighter version of the full version matrix.

So how is it possible that your tests are using function that shall not exist in the particular PT version?

The tests aren't doing that. As I have explained in #1031 (comment) I've added a minimal backport of torch.testing.assert_close in case it is not available. So all our current tests are using this backport.

@Borda
Copy link
Contributor

Borda commented Jun 2, 2021

@Borda before we continue this cycle, please have a look at the file test/utils.py that will be added by this PR.

yeah, I missed this part, and in fact, I was just backing about this point, sorry for the confusion... 🐰

@edgarriba
Copy link
Member

@pmeier @Borda actually forgot that we run against nightlies in daily basis and everything seems fine
https://github.com/kornia/kornia/runs/2724828690?check_suite_focus=true

@pmeier
Copy link
Contributor Author

pmeier commented Jun 16, 2021

@edgarriba @Borda please let me know when the CI includes torch>=1.9 so I can update the PR.

@edgarriba
Copy link
Member

@pmeier #1120 all yours !

@edgarriba
Copy link
Member

@pmeier I think you need to rebase so that can trigger 1.9 tests

@pmeier
Copy link
Contributor Author

pmeier commented Jun 25, 2021

Yes, but I didn't have time yet to do so. I'll request another review when the PR is ready.

@pmeier
Copy link
Contributor Author

pmeier commented Jun 25, 2021

One thing that is different from the old assert_allclose to the new assert_close is the default tolerance. We run some diagnostics and set the new tolerances a little stricter than the old ones. The current adoption reuses the old tolerances. If we were to use the new ones, these tests would fail.

test/augmentation/test_augmentation_mix.py::TestRandomCutMix::test_random_mixup_beta0
test/augmentation/test_random_generator.py::TestRandomPerspectiveGen::test_random_gen
test/augmentation/test_random_generator.py::TestRandomPerspectiveGen::test_same_on_batch
test/augmentation/test_random_generator.py::TestRandomRotationGen::test_random_gen
test/augmentation/test_random_generator.py::TestRandomRotationGen::test_random_gen
test/augmentation/test_random_generator.py::TestRandomRotationGen::test_same_on_batch
test/color/test_hls.py::TestRgbToHls::test_unit
test/color/test_hls.py::TestHlsToRgb::test_unit
test/color/test_hsv.py::TestRgbToHsv::test_unit
test/enhance/test_adjust.py::TestAdjustSaturation::test_saturation_one
test/enhance/test_adjust.py::TestAdjustSaturation::test_saturation_one_batch
test/enhance/test_adjust.py::TestAdjustHue::test_hue_one
test/enhance/test_adjust.py::TestAdjustHue::test_hue_one_batch
test/feature/test_matching.py::TestMatchSMNN::test_matching1
test/filters/test_sobel.py::TestSobel::test_magnitude
test/filters/test_sobel.py::TestSobel::test_magnitude
test/geometry/transform/test_imgwarp.py::TestWarpPerspective::test_crop_center_resize
test/geometry/transform/crop/test_crop3d.py::TestCropAndResize3D::test_crop
test/geometry/transform/crop/test_crop3d.py::TestCropAndResize3D::test_crop_batch
test/integration/test_conversions.py::TestAngleOfRotations::test_matrix_angle
test/utils/test_metrics.py::TestConfusionMatrix::test_three_classes_normalized

@edgarriba could you have a look if there is anything special to these tests? If not can I just crank up the tolerances in there and use the new defaults everywhere else?

@pmeier pmeier marked this pull request as ready for review June 25, 2021 18:02
@edgarriba
Copy link
Member

One thing that is different from the old assert_allclose to the new assert_close is the default tolerance. We run some diagnostics and set the new tolerances a little stricter than the old ones. The current adoption reuses the old tolerances. If we were to use the new ones, these tests would fail.

test/augmentation/test_augmentation_mix.py::TestRandomCutMix::test_random_mixup_beta0
test/augmentation/test_random_generator.py::TestRandomPerspectiveGen::test_random_gen
test/augmentation/test_random_generator.py::TestRandomPerspectiveGen::test_same_on_batch
test/augmentation/test_random_generator.py::TestRandomRotationGen::test_random_gen
test/augmentation/test_random_generator.py::TestRandomRotationGen::test_random_gen
test/augmentation/test_random_generator.py::TestRandomRotationGen::test_same_on_batch
test/color/test_hls.py::TestRgbToHls::test_unit
test/color/test_hls.py::TestHlsToRgb::test_unit
test/color/test_hsv.py::TestRgbToHsv::test_unit
test/enhance/test_adjust.py::TestAdjustSaturation::test_saturation_one
test/enhance/test_adjust.py::TestAdjustSaturation::test_saturation_one_batch
test/enhance/test_adjust.py::TestAdjustHue::test_hue_one
test/enhance/test_adjust.py::TestAdjustHue::test_hue_one_batch
test/feature/test_matching.py::TestMatchSMNN::test_matching1
test/filters/test_sobel.py::TestSobel::test_magnitude
test/filters/test_sobel.py::TestSobel::test_magnitude
test/geometry/transform/test_imgwarp.py::TestWarpPerspective::test_crop_center_resize
test/geometry/transform/crop/test_crop3d.py::TestCropAndResize3D::test_crop
test/geometry/transform/crop/test_crop3d.py::TestCropAndResize3D::test_crop_batch
test/integration/test_conversions.py::TestAngleOfRotations::test_matrix_angle
test/utils/test_metrics.py::TestConfusionMatrix::test_three_classes_normalized

@edgarriba could you have a look if there is anything special to these tests? If not can I just crank up the tolerances in there and use the new defaults everywhere else?

@pmeier probably it's worth opening an issue and mention that we should take a look at this tests and their implementations.

@edgarriba edgarriba added 1 Priority 1 🚨 High priority and removed 2 Priority 2 😅 Medium priority labels Jun 26, 2021
@edgarriba edgarriba merged commit 04a6ad1 into kornia:master Jun 27, 2021
@pmeier pmeier deleted the adopt-assert-close branch June 27, 2021 12:57
edgarriba pushed a commit to edgarriba/kornia that referenced this pull request Jul 6, 2021
* adopt torch.testing.assert_close

* use torch.testing.assert_close

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* add TODO

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 Priority 1 🚨 High priority code heatlh 💊 Improvement the package code health enhancement 🚀 Improvement over an existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Be an early adopter of torch.testing.assert_close
4 participants