before_first_epoch callback never fires

[dwf]

Rather, it fires, but is incorrectly identified as before_epoch.

[dwf]

Looks like this is caused by being a bit too clever and handling "before_first_epoch" as before_epoch with a predicate.

At the very least this needs to be documented. I'm also tempted to simply add a before_first_epoch callback explicitly as this creates a weird corner case and pushes the burden of special handling of this to the extension author. The "just another callback" implementation is simpler and also requires no explanation.

[dwf]

@rizar @dmitriy-serdyuk Any thoughts on this issue? if my fix sounds reasonable I'll go ahead and implement it.

[dmitriy-serdyuk]

I'm not sure that we should add a new callback. Blocks now have the same situation with every_n_epochs, for example, it turns into after_epoch inside the callback. I vote to document this behaviour as a "feature".

[rizar]

I agree with Dima S. This is by design, there are locations in the code from which a callback may be called, and there are conditions which should be met for the call to happen. before_epoch is a location, before_first_epoch is a condition. Perhaps before_training is what you need.

On Mon, 1 Aug 2016 at 12:49 dmitriy-serdyuk [email protected] wrote:

I'm not sure that we should add a new callback. Blocks now have the same situation with every_n_epochs, for example, it turns into after_epoch inside the callback. I vote to document this behaviour as a "feature".

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/mila-udem/blocks/issues/1133#issuecomment-236687020, or mute the thread https://github.com/notifications/unsubscribe-auth/AAn8Ysr3TwSsuYUTupMPTTG_2JbHAD2Rks5qbk3GgaJpZM4JY9ck .

[dwf]

Sorry for letting this drop.

@rizar before_training is not what I need. I need a callback that fires after setup has been completed as it operates on StepRule buffers, which haven't been created when before_training fires. That's why I discovered this, as the before_training name is somewhat misleading for that reason.

There are two sane options, then: a) rename the current before_training callback before_initialization or before_setup and add a real before_training callback that is executed after init, a) better document the way it works now (what which_callback string will be passed in which condition, specifically the special cases like before_first_epoch) as @dmitriy-serdyuk suggested.