Re-think the notion of Task

[MarcCote]

We should discuss the interface of Task and what are the common/utility tasks we need to provide.

Definitions (to be added in a wiki)

• Task: offers a way to perform some computation before/after training, before/after epochs and before/after updates.
• OccasionalTask: a task that will be trigger only once in a while. The constructor accepts two new parameters: each_update=X and each_epoch=Y where the task will be call each X updates and Y epochs.
• View: computes one or multiple values (e.g. classification error on the validset). It also offers a way to cache computed values (reducing the overhead when called multiple times during the same update).
• StoppingCriterion: tells the trainer when to stop training (e.g. MaxEpoch, EarlyStopping, etc.)

Some questions

• Is the intended behaviour of a task clear enough?
• Should a task be always (each update/epoch) executed?
• Is ItemGetter really necessary or we should make more precise Tasks. Right now, ItemGetter is used to retrieve the views mean and stderror from the view ClassificationError. Should ItemGetter returns a View that can also be used (recursively) by ItemGetter?

Suggestions

• Task to print a symbolic variable.
• Task to set a breakpoint (for debugging purpose).
• A task to track time (training, updating, etc...)
• A task to track statistic (average loss across the epoch, etc.)