-
Notifications
You must be signed in to change notification settings - Fork 186
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
Raise error on invalid input shape in Map #5180
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Maximilian Linhoff <maximilian.linhoff@tu-dortmund.de>
Thanks @maxnoe ! I agree it is rather strange to silently re-order the data (and a relief it does not affect any major results!) I think it might still be useful to allow for broadcastable shapes instead of the hard equality you introduced. |
Thanks @maxnoe, I agree this is the safer behavior! I'm not sure when this was introduced, but it must have been there for many years already. This tells us at least that it did not lead to frequent problems and people possibly relied on it without issues (we don't know...). So I am rather inclined to formally deprecate this behavior instead. On the other hand it seems the behavior is not documented either... |
@adonath does this need to be deprecated? Adding quality checks on input data is more of a new feature/clean up, no? |
@AtreyeeS I don't have a strong opinion here, but the fact that this went without complaint for such a long time might mean that some users rely on the behavior (as I said...we don't really know). In any case it will be only a very tiny fraction, so we can change without deprecation. |
I allowed broadcasting now, but the tests still fail on shapes that we might think of as compatible but are not to the numpy broadcasting rules:
as numpy only allows broadcasting on the left side, the last dimensions have to match. I.e. (3, 100) is not broadcastable to (3, 100, 1, 1), but would be to (1, 1, 3, 100). |
Ah, btw.: I should mention that these are only the tests failing in |
These are the unique shape combinations that make the tests fail:
I don't see only a few that are not additional size 1 dimensions:
|
Thanks @maxnoe . I think the reshape was added when |
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
…DMap.to_table Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Signed-off-by: Régis Terrier <rterrier@apc.in2p3.fr>
Description
Connected to #5179 I wanted to see what fails if instead of silently converting the input data into the expected shape, an error is raised.
It seems most cases where this fails is just tests "being lazy" with toy data not in the correct shape and relying on this reshaping, not any actual data files being loaded that require this treatment.