training module.training module in Avalanche is designed with modularity in mind. Its main goals are to:training module includes three main components:BaseSGDTemplate contains all the implemented methods to deal with strategies based on SGD).torch.nn.Module.torch.optim.Optimizer already initialized on your model.torch.nn.functional.train and eval. Both of them, accept either a single experience(Experience) or a list of them, for maximum flexibility.train_stream provided by the scenario.plugins that will be executed during the training/evaluation loops.plugins list to the SupervisedTemplate:Naive strategy). Therefore, the easiest way to define a custom strategy such as a regularization or replay strategy, is to define it as a custom plugin. The advantage of plugins is that they can be combined, as long as they are compatible, i.e. they do not modify the same part of the state. The disadvantage is that in order to do so you need to understand the strategy loop, which can be a bit complex at first.BaseTemplate, from which all the Avalanche's strategies inherit. Most template's methods can be safely overridden (with some caveats that we will see later).benchmarks, evaluation, and models without using Avalanche's strategies!SupervisedTemplate). These templates provide:before/after are the methods responsible for calling the plugins. Notice that before the start of each experience during training we have several phases:models tutorial) are updated by calling their adaptation method.self.clock: keeps track of several event counters.self.experience: the current experience.self.adapted_dataset: the data modified by the dataset adaptation phase.self.dataloader: the current dataloader.self.mbatch: the current mini-batch. For supervised classification problems, mini-batches have the form <x, y, t>, where x is the input, y is the target class, and t is the task label.self.mb_output: the current model's output.self.loss: the current loss.self.is_training: True if the strategy is in training mode.Naive strategy). This approach reduces the overhead and code duplication, improving code readability and prototyping speed.BasePlugin, BaseSGDPlugin, SupervisedPlugin) and implements the callbacks that you need. The exact callback to use depend on the aim of your plugin. You can use the loop shown above to understand what callbacks you need to use. For example, we show below a simple replay plugin that uses after_training_exp to update the buffer after each training experience, and the before_training_exp to customize the dataloader. Notice that before_training_exp is executed after make_train_dataloader, which means that the Naive strategy already updated the dataloader. If we used another callback, such as before_train_dataset_adaptation, our dataloader would have been overwritten by the Naive strategy. Plugin methods always receive the strategy as an argument, so they can access and modify the strategy's state.before/after) at the appropriate points. For example, train calls before_training and after_training before and after the training loops, respectively. The easiest way to avoid mistakes is to start from the template's method that you want to override and modify it to your own needs without removing the callbacks handling.EvaluationPlugin (see evaluation tutorial) uses the strategy callbacks.SupervisedTemplate, for continual supervised strategies, provides the global state of the loop in the strategy's attributes, which you can safely use when you override a method. For instance, the Cumulative strategy trains a model continually on the union of all the experiences encountered so far. To achieve this, the cumulative strategy overrides adapt_train_dataset and updates `self.adapted_dataset' by concatenating all the previous experiences with the current one.