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

Add control over tolerance for failed amortized computations #64

Closed
wants to merge 30 commits into from

Conversation

runame
Copy link
Contributor

@runame runame commented Dec 19, 2024

No description provided.

@runame runame added the enhancement New feature or request label Dec 19, 2024
@runame runame requested a review from tsunghsienlee December 19, 2024 11:42
@runame runame self-assigned this Dec 19, 2024
@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Dec 19, 2024
@runame runame requested a review from tsunghsienlee December 19, 2024 20:54
@facebook-github-bot
Copy link
Contributor

@tsunghsienlee has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@facebook-github-bot
Copy link
Contributor

@tsunghsienlee merged this pull request in 0921f45.

@runame runame deleted the fail-counter-v2 branch December 22, 2024 00:44
Comment on lines +110 to +129
class ShampooPreconditionerConfigTest(
AbstractPreconditionerConfigTest.PreconditionerConfigTest[
Type[ShampooPreconditionerConfig]
]
):
def _get_preconditioner_config_type(
self,
) -> Type[ShampooPreconditionerConfig]:
return ShampooPreconditionerConfig


class EigenvalueCorrectedShampooPreconditionerConfigTest(
AbstractPreconditionerConfigTest.PreconditionerConfigTest[
Type[EigenvalueCorrectedShampooPreconditionerConfig]
]
):
def _get_preconditioner_config_type(
self,
) -> Type[EigenvalueCorrectedShampooPreconditionerConfig]:
return EigenvalueCorrectedShampooPreconditionerConfig
Copy link
Contributor

Choose a reason for hiding this comment

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

Hi @runame ,

It seems these two tests do not discovered by the test discovery; if you check the CI before and after this pull request, the total number of tests ran does not change, and I believe this is due to those two classes here are still considered as abstract class so they don't get instantiated at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think the two tests are actually discovered and run by the CI. Note that the "before" CI does not actually reflect the state before the two tests are added, since it is merely the PR that was created before it (#63 before #64). See the commit history for the actual order in which the PRs were merged. Now we can compare the CI before and after the two tests were added and see that the number of tests increased from 23 to 25.

Finally, I also verified locally that commenting out the two tests results in two less tests being run.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. I check the commit history, and you are right the two tests are discovered in here.

Now it seems the issue is happened in the the Meta internal test discovery could not find those two tests so I was wondering the current setup is the culprit. If I run the shampoo_types_test.py in Meta internal, it will only discover 5 test cases, but it should be 7 test cases.

Screenshot 2024-12-24 at 8 04 25 AM

We might need a different setup to accommodate this unfortunately.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh interesting. Do you have any idea why the tests are not discovered internally?

Copy link
Contributor

Choose a reason for hiding this comment

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

Generic is the reason because if we don't use that, it will be discovered. However, how and why are something I don't know, I will create a minimum example with Generic to verify this.

Copy link
Contributor

Choose a reason for hiding this comment

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

#72 is a better design to resolve this but we might want to figure this out in the future for curiosity sake.

tsunghsienlee added a commit to tsunghsienlee/optimizers that referenced this pull request Dec 26, 2024
Summary:
Current tests on the configs with subclasses relied on explicit instantiating subclasses to test it. There are some limitations on this approach:
1. It is hard to catch newly added subclasses.
2. Due to some unknown interactions with `typing.Generic`, [the current `buck` test discovery mechanism is not able to discover the tests in it](facebookresearch#64 (comment)).

To resolve this, this diff refactors those tests with [`type.__subclasses()`](https://docs.python.org/3/reference/datamodel.html#type.__subclasses__) to tests the configs with subclasses.

Differential Revision: D67652761
tsunghsienlee added a commit to tsunghsienlee/optimizers that referenced this pull request Dec 26, 2024
)

Summary:

Current tests on the configs with subclasses relied on explicit instantiating subclasses to test it. There are some limitations on this approach:
1. It is hard to catch newly added subclasses.
2. Due to some unknown interactions with `typing.Generic`, [the current `buck` test discovery mechanism is not able to discover the tests in it](facebookresearch#64 (comment)).

To resolve this, this diff refactors those tests with [`type.__subclasses()`](https://docs.python.org/3/reference/datamodel.html#type.__subclasses__) to tests the configs with subclasses.

Reviewed By: anana10c

Differential Revision: D67652761
tsunghsienlee added a commit to tsunghsienlee/optimizers that referenced this pull request Dec 26, 2024
)

Summary:

Current tests on the configs with subclasses relied on explicit instantiating subclasses to test it. There are some limitations on this approach:
1. It is hard to catch newly added subclasses.
2. Due to some unknown interactions with `typing.Generic`, [the current `buck` test discovery mechanism is not able to discover the tests in it](facebookresearch#64 (comment)).

To resolve this, this diff refactors those tests with [`type.__subclasses()`](https://docs.python.org/3/reference/datamodel.html#type.__subclasses__) to tests the configs with subclasses.

Reviewed By: anana10c

Differential Revision: D67652761
facebook-github-bot pushed a commit that referenced this pull request Dec 27, 2024
Summary:
Pull Request resolved: #72

Current tests on the configs with subclasses relied on explicit instantiating subclasses to test it. There are some limitations on this approach:
1. It is hard to catch newly added subclasses.
2. Due to some unknown interactions with `typing.Generic`, [the current `buck` test discovery mechanism is not able to discover the tests in it](#64 (comment)).

To resolve this, this diff refactors those tests with [`type.__subclasses__`](https://docs.python.org/3/reference/datamodel.html#type.__subclasses__) to tests the configs with subclasses.

Reviewed By: anana10c

Differential Revision: D67652761

fbshipit-source-id: 58d3131052f0f0d01e37c49506761209f069e38a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. enhancement New feature or request Merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants