-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data verify_out_shape not intuitive when there are implicit dims #1153
Comments
I'm thinking about whether this automatic introduction of implicit dims was a good idea. This original code really should work, as it would be quite confusing otherwise: x = nn.zeros((dim1, dim2))
x.verify_out_shape({dim1, dim2}) Maybe these implicit dims should actually be explicitly defined. We still would have them, but they are explicitly defined. E.g. a layer like |
@Zettelkasten what do you think about this? Specifically, here (#706 (comment)) you said:
|
We could also allow returnn-common to be a bit more relaxed about this and |
I did that now, just to fix rwth-i6/returnn_common#226 for now. However, I think this issue here remains, and we should think about it more. Maybe implement my suggestion here on handling it explicitly? |
(I use returnn-common code here but nothing is really specific about returnn-common.
nn.zeros
is justConstantLayer
.)Consider this code:
This is correct when
dim1
anddim2
are static dims.Once they are dynamic dims and introduce implicit dims, the
verify_out_shape
fails because it does not cover the implicit dims. E.g. whendim1
has adyn_size_ext
of shape[B]
, then currently you actually need:Or:
Because the batch dim is an implicit dim.
Why do we have implicit dims? What are those? They were introduced mostly for
CumConcatLayer
. See #391, #589.Example of such error: rwth-i6/returnn_common#226
See also the earlier discussion on the introduction of
out_shape
andverify_out_shape
: #706, #757The text was updated successfully, but these errors were encountered: