You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ReturnnConfig in 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.)
The text was updated successfully, but these errors were encountered:
We are already changing some defaults. For example:
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?
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
ReturnnConfig
in 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.)The text was updated successfully, but these errors were encountered: