coveralls
commented
4 months ago Pull Request Test Coverage Report for Build 8426226675
Details
- 169 of 381 (44.36%) changed or added relevant lines in 3 files are covered.
- 1 unchanged line in 1 file lost coverage.
- Overall coverage decreased (-0.06%) to 51.751%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
|---|---|---|---|---|---|
| avalanche/models/dynamic_optimizers.py | 119 | 135 | 88.15% | ||
| tests/test_optimizer.py | 48 | 244 | 19.67% | ||
| <!-- | Total: | 169 | 381 | 44.36% | --> |
| Files with Coverage Reduction | New Missed Lines | % | ||
|---|---|---|---|---|
| avalanche/models/dynamic_optimizers.py | 1 | 88.46% | ||
| <!-- | Total: | 1 | --> |
| Totals | |
|---|---|
| Change from base Build 8098020118: | -0.06% |
| Covered Lines: | 14863 |
| Relevant Lines: | 28720 |
AlbinSou
AntonioCarta
Hey, I just put a prototype for now of the kind of changes I want to bring.
First of all, quick reminder of why it's not as easy as it seems to support multiple parameter groups:
1) In continual learning, it is common to add parameters to the model upon encountering new data, but if the user adds parameters, it is not easy to know in what parameter group this new parameter should be assigned to, because the parameter group information is contained inside the optimizer whereas the added parameters are added to the model without additional info on what parameter group they should be in.
2) Now, although the default way to make changes in the model parameters in avalanche is to use DynamicModules, it is technically possible to manually add parameters to nn.Modules, which makes tracking of new parameters even harder.
3) To complexify the things a bit, pytorch optimizer like to store the parameters in a very unconvenient datastructure which is a list of parameters, not linking directly each parameter to it's name
How I plan to remedy to that:
Ideally, we want to have native support for a normal use of multiple parameter groups. If the user puts different parameter groups into the optimizer, he should not have to worry about them being broken. Of course, right now it's not the case and what we do is just to reset the optimizer at the start of training to setup the name, param_id mapping later used for update, and we put an assertion saying that if the optimizer has more than one param group it fails and it requires the user to implement it's own make_optimizer function (which is a pity because then using an existing method with different parameter groups requires to copy the strategy or create a new plugin).
Since users can add parameters both through DynamicModules and Manually, it's better to use a general method that works with any nn.Module object
Provide an automatic and natural way based on the natural module hierarchy to assign parameter groups to new parameters. Leaving more complex logic (which should not happen so often ?) to custom implementations.
The idea is the following, we let the user define it's optimizer with it's own param groups. Then we go over the model named_parameters() and store each name into a tree structure (which is a copy of the torch module tree structure). Each node (not necessarily parameter, a parameter is a leaf node) will contain information about a set of parameter groups that it's children nodes belong to. Then, when a new node is added (new parameter), it's group is inferred based on the group of it's parent node. If his parent node has multiple groups, it means that this node's parameter group cannot be inferred and returns an error asking the user to either change the module creation process or implement his own optimizer update logic.
@AntonioCarta I just provide for now a playground in test/test_optimizer.py that you can run as-is to see how it will work, I will implement the actual thing later. Let me know if you agree on the idea first