You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sub-function _boundary_run uses rle, but it could use _cumsum_reset_on_zero, effectively avoiding these two steps in rle:
cs_s=cs_s.where(da.shift({dim: -1}, fill_value=0) ==0)
out=cs_s.where(da==1, 0) # Reinsert 0's at their original place
These steps are probably much less demanding than the cumsum operations, but still, it's worth considering. I think there could be merit in keeping things as they are if we feel it makes the code more understandable, but I'm not sure about this, and also the run_length functions are somewhat at a low level in the code, so I have the feeling that performance should be prioritized here.
Side note about return type of first_run
I currently have to convert the result of first_run to be able to use it for time selection. There is no reason really for the output not to be already a int (of course, in the case where coord is False or None)
<!--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:
- [x] This PR addresses an already opened issue (for bug fixes /
features)
- This PR fixes#1405
- [ ] Tests for the changes have been added (for bug fixes / features)
- [ ] (If applicable) Documentation has been added / updated (for bug
fixes / features)
- [x] CHANGES.rst has been updated (with summary of main changes)
- [x] Link to issue (:issue:`number`) and pull request (:pull:`number`)
has been added
### What kind of change does this PR introduce?
* Use an intermediate step instead of `rle` in first/last run
computations
### Does this PR introduce a breaking change?
No
### Other information:
Generic Issue
Sub-function
_boundary_run
usesrle
, but it could use_cumsum_reset_on_zero
, effectively avoiding these two steps inrle
:These steps are probably much less demanding than the
cumsum
operations, but still, it's worth considering. I think there could be merit in keeping things as they are if we feel it makes the code more understandable, but I'm not sure about this, and also therun_length
functions are somewhat at a low level in the code, so I have the feeling that performance should be prioritized here.Side note about return type of
first_run
I currently have to convert the result of
first_run
to be able to use it for time selection. There is no reason really for the output not to be already aint
(of course, in the case wherecoord
is False or None)This could be fixed by adding a
else
statement incoord_transform
:Code of Conduct
The text was updated successfully, but these errors were encountered: