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

[feat] Add flexible step-wise LR scheduler with minimum changes #256

Merged

Conversation

nabenabe0928
Copy link
Contributor

Since this PR is urgent now, I made another PR to quickly merge the feature.
The original PR is available here.

@codecov
Copy link

codecov bot commented Jun 16, 2021

Codecov Report

Merging #256 (551666e) into development (999f3c3) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@               Coverage Diff               @@
##           development     #256      +/-   ##
===============================================
- Coverage        81.62%   81.62%   -0.01%     
===============================================
  Files              150      151       +1     
  Lines             8625     8646      +21     
  Branches          1325     1328       +3     
===============================================
+ Hits              7040     7057      +17     
- Misses            1108     1111       +3     
- Partials           477      478       +1     
Impacted Files Coverage Δ
...pipeline/components/setup/lr_scheduler/__init__.py 74.32% <ø> (ø)
...h/pipeline/components/training/trainer/__init__.py 70.81% <ø> (ø)
...components/setup/lr_scheduler/CosineAnnealingLR.py 96.15% <100.00%> (-0.15%) ⬇️
.../setup/lr_scheduler/CosineAnnealingWarmRestarts.py 96.42% <100.00%> (-0.13%) ⬇️
...pipeline/components/setup/lr_scheduler/CyclicLR.py 91.42% <100.00%> (-5.80%) ⬇️
...ine/components/setup/lr_scheduler/ExponentialLR.py 96.15% <100.00%> (-0.15%) ⬇️
...eline/components/setup/lr_scheduler/NoScheduler.py 95.00% <100.00%> (-0.24%) ⬇️
...components/setup/lr_scheduler/ReduceLROnPlateau.py 96.66% <100.00%> (-0.11%) ⬇️
...h/pipeline/components/setup/lr_scheduler/StepLR.py 96.42% <100.00%> (-0.13%) ⬇️
...ne/components/setup/lr_scheduler/base_scheduler.py 86.20% <100.00%> (+7.25%) ⬆️
... and 10 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 999f3c3...551666e. Read the comment docs.

Copy link
Contributor

@ravinkohli ravinkohli left a comment

Choose a reason for hiding this comment

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

Hey, Thanks for this PR. The changes look good. However, I still don't see where epoch or batch is passed by an LR scheduler. So basically, how does the fit dictionary 'X' get updated to contain the step unit? To that end, could we add a test where we run a few schedulers in a training and we verify that the step was made at the appropriate time. This can be achieved by using the internal parameters of the torch scheduler for example, in CosineAnnealingWarmRestarts we have T_0 or T_curr which contains the epochs since the last step. And we can verify if it is done epoch wise or batch wise there.

@nabenabe0928
Copy link
Contributor Author

However, I still don't see where epoch or batch is passed by an LR scheduler. So basically, how does the fit dictionary 'X' get updated to contain the step unit?

I will check promptly and give another commit soon

To that end, could we add a test where we run a few schedulers in a training and we verify that the step was made at the appropriate time.

Should I do it separetly as in the latest commit of test codes by me or should I really run it from API?
I think the former is sufficient and faster, but if something wrong happens in the system, we cannot potentially detect the errors.
But in my opinion, when you make tests, they should test speicific parts, so the former is enough.
What do you think?

@ravinkohli
Copy link
Contributor

However, I still don't see where epoch or batch is passed by an LR scheduler. So basically, how does the fit dictionary 'X' get updated to contain the step unit?

I will check promptly and give another commit soon

To that end, could we add a test where we run a few schedulers in a training and we verify that the step was made at the appropriate time.

Should I do it separetly as in the latest commit of test codes by me or should I really run it from API?
I think the former is sufficient and faster, but if something wrong happens in the system, we cannot potentially detect the errors.
But in my opinion, when you make tests, they should test speicific parts, so the former is enough.
What do you think?

yeah so the idea is to train a pipeline with the different schedulers and make sure that the step is made at the right time. The code you added in itself might run, but the tests I would like to see would ensure that proper information is passed by the chosen lr scheduler and it is able to take a step at the appropriate time. This will ensure that CosineAnnealing or some other scheduler if selected in a configuration is able to take the appropriate step

Since we would like to merge this feature promptly, I cut this new branch
from the branch hot-fix-adapt... and narrowed down the scope of this PR.
The subsequent PR addresses the issues, epspecially the format and mypy
typing.
The intention behind the change from torch.tensor to torch.Tensor is that
since I got an error NoModuleFound `import torch.tensor`.
Plus, the torch.tensor is not a TensorType class, but torch.Tensor is.
Therefore, I changed the torch.tensor to torch.Tensor.
Since the previous version always use batch-wise update, I added the
step_unit = batch and then avoid the errors I got from pytest.
Since the latest version only supports the batch-wise update,
I just inserted step_unit == "batch" to be able to run greedy portfolio
selection.
@ravinkohli ravinkohli merged commit 76bdde7 into automl:development Jun 23, 2021
github-actions bot pushed a commit that referenced this pull request Jun 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants