Flexible access to state

The introduction of State (#80, #83) which is passed to event handlers is very welcome as it is a critical requirement. The flexibility with which state is passed around, however, could still be improved. Currently:

1. Event handlers can only access the state of the engine issuing the event.
2. There is no access to the state in the training and validation functions.

An argument against making state a member of the engine was that in so not doing, the state is explicitly ephemeral. However, this enforces the assumption that an engines state should only every be accessed by that engine’s event handlers.

One example of where (1) is an obstacle is on attempting to identify current epoch during training. It is useful to read the current epoch on completion of validation when saving a checkpoint, in order to record the epoch. However, the current epoch is a state attribute of the training engine; currently, there is no way to access that state, except when handling a signal emitted by the training engine.

It would be convenient to have state exposed in Trainer and Evaluator as self.state so that a user may have direct access to it, outside of callbacks that are specific to the calling engine.

If state is thus exposed, it may be cleaner to also not pass engine state by default to handlers; the user could pass any state (eg. trainer.state) through the *args or **kwargs of add_event_handler, instead – if some state is needed by the event handler.

[jasonkriss]

Just to summarize, my vote is for the following changes:

1. attach state to engine
2. pass engine as the only argument to all event handlers
3. pass engine, batch to update functions

What do you all think?

[veugene]

Do you have a use-case for when you’d want to access the state in the update function?

That really has to do with the discussion in #118 which it appears you’ve seen now.

would you be able to send a PR?

Yes, it shouldn’t take long once I get around to it.