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
There are still a number of open issues which should be done for the first "official" release (or at least addressed, or maybe deliberately postponed) (#32).
Even before that, I think the current functionality is already in a usable state which could simplify certain things for some applications. E.g. some part of your model or maybe of the loss could already be implemented using RETURNN common.
So, what things are currently blocking us from already using it that way?
Somewhat stable API. It should not break much anymore. I think we already have this, at least for the model definition. (Although, please keep in mind it is still experimental, and not guaranteed.)
Partial serialization of sub network dicts including dim tags. Currently it's only for the full network. Although you could also wrap your existing raw net dict and then it would work already, so maybe not really needed? Edit Not really needed.
How to handle Sisyphus hashes #51? We can already do experiments without this and rely on the basic net dict for the hash. However, I expect that the produced net dict will still change, so this will probably cause you some trouble.
I think this can be closed for now. It can already be used, even when not having the Sisyphus hashes solved yet (although you should keep that in mind of course). E.g. you could just handle that manually. Or just use the net dict as hash but then take into consideration that the hash likely will change in the future.
There are still a number of open issues which should be done for the first "official" release (or at least addressed, or maybe deliberately postponed) (#32).
Even before that, I think the current functionality is already in a usable state which could simplify certain things for some applications. E.g. some part of your model or maybe of the loss could already be implemented using RETURNN common.
So, what things are currently blocking us from already using it that way?
TransformerDecoder
as an example for search. Or stochastic layers (Stochastic depth #99) as an example for using the train flag.What else?
I now just picked things which I see critical before this can be really used. For further things, see #32.
The text was updated successfully, but these errors were encountered: