create testing.py with ttest and multipletest

[aaronspring]

Description

• added an xr implementation of from statsmodels.stats.multitest import multipletests
• create testing.py and move ttest also there

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. This could point to a cell in the updated notebooks. Or a snippet of code with accompanying figures here.

Checklist (while developing)

• [x] I have added docstrings to all new functions.
• [x] I have commented my code, particularly in hard-to-understand areas
• [ ] Tests added for pytest, if necessary.
• [x] I have updated the sphinx documentation, if necessary.

Pre-Merge Checklist (final steps)

• [x] I have rebased onto master or develop (wherever I am merging) and dealt with any conflicts.
• [x] I have squashed commits to a reasonable amount, and force-pushed the squashed commits.
• [x] I have run make html on the documents to make sure example notebooks still compile.

References

Wilks, D. S. “‘The Stippling Shows Statistically Significant Grid Points’: How Research Results Are Routinely Overstated and Overinterpreted, and What to Do about It.” Bulletin of the American Meteorological Society 97, no. 12 (March 9, 2016): 2263–73. https://doi.org/10/f9mvth.

[bradyrx]

@aaronspring I just modified this directly to clean it up a bit since you're on vacation. Give it a look and let me know what you think before I merge. Was there any reason to write that unstack function and copy values over? Using .values would load into memory which I want to avoid at all costs now so everything is dask-compatible.

Just using the standard .unstack() seems to work.

[bradyrx]

Thanks! This finally encourages me to read the Wilks paper you cited. It seems important. We should also potentially include these things in climpred. Or maybe that's up to user-defined metrics.

[aaronspring]

climpred can just import this from esmtools

[bradyrx]

climpred can just import this from esmtools

Agreed. I am working on porting all standard stats over to esmtools via https://github.com/bradyrx/esmtools/pull/70 that will all be dask compatible. Then we can just have esmtools as a dependency on climpred and call the dask-aware things like rm_trend.