-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Scalar coords vs. concat #1151
Comments
I agree -- we really should do an outer join of variables/coordinates in |
I wrote down this.
|
I updated the code and tested it in my project - it works fine.
|
@crusaderky I don't understand the distinction between ambiguous/unambiguous coords -- can you clarify? Also, why treat scalar coordinates differently? Most xarray machinery doesn't special case arrays of a certain dimensionality. |
@shoyer the end goal is to replicate in concat() the same behaviour you already hav in __add__ and __mul__.
a+b -> y is propagated to the result (unambiguous) I suppose I could look at how this happens in __add__ and move the logic up into broadcast() (which __add__ should already invoke)? |
@crusaderky Ah, I understand now. I agree that this makes sense for concatenating along an existing dimension (e.g., For concatenating along a new dimension (e.g., |
I just realised that xarray today already implements meaningful logic when concatenating between a and c in my example above - both on an existing dimension as well as on a new one. It's just a and b that don't work. I agree that defaulting to NaN would be a good option (regardless if the dimension is new or existing). So to recap, when concatenating [a, b, c], where b does not have the y coord:
Correct? |
Yes, indeed. |
In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity |
This issue is still valid as of xarray 0.11.0 |
|
Why does this work:
But this doesn't?
It doesn't seem coherent to me...
The text was updated successfully, but these errors were encountered: