Ouranosinc / xscen / 11668375738

87%

push

github

Choose which dimensions are reduced in `measures_improvement` (#416)

<!-- 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
- [x] (If applicable) Documentation has been added / updated (for bug
fixes / features).
- [x] (If applicable) Tests have been added.
- [x] This PR does not seem to break the templates.
- [x] CHANGELOG.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?

* `measures_improvement` has an extra kwarg: `dim`, which allows to
control on which dimensions we compute the percentage of improvement.

### Does this PR introduce a breaking change?

Default behaviour `None` is the same as before, reduce all dimensions. I
thought it made sense to put `dim` as the first kwarg, so this is not
breaking per-se, but still somewhat semi-breaking for scripts inputting
`to_level` positionnally e.g. `measures_improvement([ds1,ds2],
to_level)`, so I can move down `dim` if it's preferrable.

There is a small breaking change: `ds1-ds2` is used instead of `ds2` to
find non-null values and compute the pct of improvement. This may result
in less non-null values. I think it's the right thing to do though.

### Other information:

My example is that I had a dataset with (rlat, rlon, period), I want
improvement percentages for each period. I realize now this is an
unconventional dataset in the xscen philosophy, I should have had
separate dataset, when using `properties_and_measure` I should have used
`period` etc etc. and have multiple catalog entries. But, for properties
using `group=time.season, time.month`, we would have an extra dimension
`season, month` that w... (continued)

11 of 12 new or added lines in 1 file covered. (91.67%)

3584 of 4403 relevant lines covered (81.4%)

4.79 hits per line