Skip to content

Behavior version? #247

@albertz

Description

@albertz

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?

    • 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.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions