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
Conversation
Just one quick question, would it break the backward compatibility in the CI? |
No, it won't. I've backported it using |
thanks @pmeier ! this is a great contribution from the pytorch team :) |
so is |
Yes. It will be shipped the first time with |
co can you run all these updated tests in past PT 1.7 for example? |
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... kornia/.github/workflows/tests_cpu_versions.yml Lines 3 to 9 in f182c58
|
I've just prepared the PR so this is ready when |
I guess that the point of @Borda is that will this PR won't have backward compatibility |
Why wouldn't it? CI is green right now for all the older versions. |
@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 ? 🤔 |
But we cannot use it till Kornia will set 1.9 as min version...
As mentioned, the CI for PR will pass but not on mater, and you can't test any older PT versions anymore...
So how is it possible that your tests are using function that shall not exist in the particular PT version? |
@Borda before we continue this cycle, please have a look at the file
We can use it for all CI runs that run on
Of course it will pass on
The tests aren't doing that. As I have explained in #1031 (comment) I've added a minimal backport of |
yeah, I missed this part, and in fact, I was just backing about this point, sorry for the confusion... 🐰 |
@pmeier @Borda actually forgot that we run against nightlies in daily basis and everything seems fine |
@edgarriba @Borda please let me know when the CI includes |
@pmeier I think you need to rebase so that can trigger 1.9 tests |
Yes, but I didn't have time yet to do so. I'll request another review when the PR is ready. |
One thing that is different from the old
@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. |
* 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>
Closes #1029.
torch.testing.assert_close
will only be shipped withtorch==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.