-
-
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
Use the same function to floatize coords in polyfit and polyval #9691
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I don't know this code well, but looks good to me...)
I guess I should also notice @Karl-Krauth. This changes code affected by your PR on how coordinates are transformed to float, but if I understand all of this correctly, it kinda "reverts" to the old result for datetime objects : 0 on 1970-01-01. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should get an entry in whats-new.
Possibly indicating a breaking change?
@headtr1ck I would argue that this is more a regression fix than a breaking change ? The behaviour for datetime coordinates changed in 2024.10.0 and broke the symmetry between |
Co-authored-by: Deepak Cherian <[email protected]>
<!--Please ensure the PR fulfills the following requirements! --> <!-- If this is your first PR, make sure to add your details to the AUTHORS.rst! --> ### Pull Request Checklist: - [ ] This PR addresses an already opened issue (for bug fixes / features) - This PR fixes #xyz - [ ] Tests for the changes have been added (for bug fixes / features) - [ ] (If applicable) Documentation has been added / updated (for bug fixes / features) - [x] CHANGELOG.rst has been updated (with summary of main changes) - [ ] Link to issue (:issue:`number`) and pull request (:pull:`number`) has been added ### What kind of change does this PR introduce? * Pins `xarray` such that version 2024.10.0 is not compatible with `xclim`. ### Does this PR introduce a breaking change? Yes. `xarray` v2024.10.0 is considered to be broken according to our configurations. The pin will stay in place until we drop `xarray` newer than this version. ### Other information: pydata/xarray#9690 pydata/xarray#9691 The issue is currently fixed upstream, so the next release of `xarray` should have no issues.
* main: Refactor out utility functions from to_zarr (pydata#9695) Use the same function to floatize coords in polyfit and polyval (pydata#9691)
* main: (85 commits) Refactor out utility functions from to_zarr (pydata#9695) Use the same function to floatize coords in polyfit and polyval (pydata#9691) Add `DataTree.persist` (pydata#9682) Typing annotations for arithmetic overrides (e.g., DataArray + Dataset) (pydata#9688) Raise `ValueError` for unmatching chunks length in `DataArray.chunk()` (pydata#9689) Fix inadvertent deep-copying of child data in DataTree (pydata#9684) new blank whatsnew (pydata#9679) v2024.10.0 release summary (pydata#9678) drop the length from `numpy`'s fixed-width string dtypes (pydata#9586) fixing behaviour for group parameter in `open_datatree` (pydata#9666) Use zarr v3 dimension_names (pydata#9669) fix(zarr): use inplace array.resize for zarr 2 and 3 (pydata#9673) implement `dask` methods on `DataTree` (pydata#9670) support `chunks` in `open_groups` and `open_datatree` (pydata#9660) Compatibility for zarr-python 3.x (pydata#9552) Update to_dataframe doc to match current behavior (pydata#9662) Reduce graph size through writing indexes directly into graph for ``map_blocks`` (pydata#9658) Add close() method to DataTree and use it to clean-up open files in tests (pydata#9651) Change URL for pydap test (pydata#9655) Fix multiple grouping with missing groups (pydata#9650) ...
whats-new.rst
api.rst
The coordinate on which the fit is computed in
da.polyfit
is transformed into afloat
using the same function as inxr.polyval
. This ensures a symmetry between the two operations. Fixes a bug whereda.polyfit
would transform datetime coordinate to nanoseconds, but starting at 0 on the first element, while inpolyval
the transformation puts the 0 on 1970-01-01.This solution seemed the most easiest to me, but I can see how importing a private function from a sub-module to another might not be the best. Maybe,
_ensure_numeric
could be moved elsewhere ?duck_array_ops.py
?