-
Notifications
You must be signed in to change notification settings - Fork 4
Description
We are already changing some defaults. For example:
- BlstmEncoder allow_pool_last, change default to True? #246
- Conformer: Missing dropout after the self-attention #245
- Weight decay API maybe unintuitive #241
- Create good Conformer baselines #233
- Conformer frontend should fix dimensions, be more standard #219
As we do not have a stable version yet, this is maybe ok. But we might already think about how to deal with these cases later.
For RETURNN, we have the solution of the behavior version. Specifically, returnn.util.basic.BehaviorVersion in the code, behavior_version flag in the config. See rwth-i6/returnn#508 for some discussions.
We can just introduce the same for returnn-common. Some questions:
-
Should it somehow share something with RETURNN?
- Even the same global setting? I.e. it means when we need a new behavior version in returnn-common, we need to increase the RETURNN behavior version, and also document it on RETURNN side?
- Just some code?
Or alternatively, we would make it decoupled from each other.
-
How would it be configured? There is no config for returnn-common. RETURNN-common can also be executed in various ways, for example inside the Sisyphus manager, or alternatively inside of RETURNN.
Maybe if inside of RETURNN, we can still set some flag in the RETURNN config for this and use this. So it is part of
ReturnnConfigin Sisyphus i6 experiments.Otherwise, we can make an assertion that it is explicitly set by the user, via some call
returnn_common.set_behavior_version? Or by default it would be behavior version 0 always? (In RETURNN, we made the strong argument that it should not be the latest version by default, otherwise it will break user configs all the time.)