Add an arithmetic_compat option to xr.set_options #10943
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This determines how non-index coordinates of the same name are compared for potential conflicts when performing binary operations.
The default is
arithmetic_compat='minimal', which matches the previous behaviour.I had originally planned to set this up to migrate the default to
arithmetic_compat='override'alongside the wider migration of default to `compat='override' elsewhere. However I've held off on this for now pending a decision on what to do anything about the original motivation of compat='minimal' here which was to drop clashing scalar coordinates that arise from things like arr[0] + arr[1].I think this is nice to have in general, complimenting the
arithmetic_joinsetting and making sure we have the same degree of control over this for arithmetic operations as we do for things likexr.merge. But the immediate motivation was#10924 where we need to skip equality checks on coordinates in situations where we want to JIT a function that uses jax arrays for coordinates.
whats-new.rst