Updatable objects

[AntonioCarta]

attempt at #1611.

Right now there is:

• a single API for objects that require pre/post training experience hooks (models, optimizers, losses, buffers..)
• everything is encapsulated in the Agent object, which keeps track of CL state and provides some basic utilities to update them or add functional hooks
• MetricCollector: a new object to manage metrics. This is needed because the current metric system is tightly coupled to the templates. MetricCollector is a simplified metric system but it should provide the basic functionality with a simpler API.
• everything is "documented" via the updatable_objects.py example.

I'm opening the PR for comments right now, just to understand if this may be useful or not. I'm finding it conveniente for some simple experiments that I'm running.

Regarding compatibility, I didn't find any major roadblocks. Everything seems easy to integrate, though some things may need to be adapted. For example, some methods like GEM may be rewritten as optimizer to make their use transparent with this API.

[coveralls]

Pull Request Test Coverage Report for Build 8892479082

Details

• 248 of 436 (56.88%) changed or added relevant lines in 20 files are covered.
• 9 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.05%) to 51.805%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
avalanche/evaluation/plot_utils.py	15	16	93.75%
avalanche/training/losses.py	8	9	88.89%
avalanche/training/storage_policy.py	22	23	95.65%
avalanche/training/regularization.py	15	17	88.24%
tests/training/test_losses.py	0	2	0.0%
tests/training/test_regularization.py	1	3	33.33%
tests/evaluation/test_plots.py	6	9	66.67%
tests/models/test_models.py	0	3	0.0%
avalanche/core.py	40	46	86.96%
tests/evaluation/test_functional.py	9	18	50.0%

Files with Coverage Reduction	New Missed Lines	%
avalanche/training/regularization.py	9	88.19%

Totals
Change from base Build 8453173939:	0.05%
Covered Lines:	15081
Relevant Lines:	29111

---

💛 - Coveralls

[AlbinSou]

Looks good so far. I was a bit concerned wether some objects would need to implement something else than "before_training_exp" and "after_training_exp" but I don't think so. For instance for optimizers the "before_backward" call would be replaced by overriding the step() method. In general I think before_training_exp and after_training_exp are sufficient to account for every cases.

[AlbinSou]

As a side comment. Do you think it can happen that one updatable object depends on another ? I am thinking in particular about the optimizer. If we want to use the existing functions for updating optimizer we would need to encapsulate the optimizer into an Updatable object, but then it would need to be updated after the model. In that case we could add some dependency system to each object to make sure they are updated in the correct order.

[AntonioCarta]

@AlbinSou I added the custom weights mode for the MetricCollector and a wrapper for the optimizers. I think the PR is ready to be merged if you agree.