Stack and unstack periods

[aulemahal]

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)
• CHANGES.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?

New stack_periods and it's reverse unstack_periods.

The basic idea is to have da.rolling(time=window).construct(dim, stride=stride), but with window and stride given as a multiple of a given freq, allowing the use of non-uniform temporal periods (like years or months). And to have a reverse method to go back to the linear timeseries.

We had sdba.construct_moving_yearly_window, this is the generalization of that logic for:

• other frequencies than 'YS'
• periods of different lengths (MS, QS)
• non-uniform calendars
  Of course, the two latter points will generate an output where the "fake" time axis makes no sense at all, so this is to be use with precaution.

Does this PR introduce a breaking change?

Yes.

sdba.construct_moving_yearly_window is transparently sent to stack_periods with a warning.

sdba.unpack_moving_yearly_window also warns and calls unstack_periods but the append_ends argument is not available on the latter. The behaviour is that same as append_ends=True.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[coveralls]

coverage: 89.686% (-0.8%) from 90.447%
when pulling 40e1d9f on sdba-better-names
into b905e55 on master.

[coxipi]

Nice job. I think this kind of logic could be useful to replace map_blocks/map_groups operations if it can help some computations. Either to create arrays we directly work on, or to deduce time indices that can be used with the philosophy of groupies.