Skip to content

Conversation

@jhamman
Copy link
Member

@jhamman jhamman commented Sep 12, 2017

cc @shoyer, @darothen, @arbennett, @vnoel

return result


def dask_rolling_wrapper_without_min_count(moving_func, a, window, axis=-1):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we use the default parameter value rather than writing this twice?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we update the minimum support bottleneck version to 1.1, we can do away with this special case (also present for the non-dask case) all together.

has_bottleneck = False

try:
import dask.array as da
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved he dask array related code to duck_array_ops. That's probably a more natural place for this.

Actually: maybe we should have another module for dask array operations, and then put the duck type functions in dask_array_ops.

@shoyer
Copy link
Member

shoyer commented Sep 12, 2017 via email

@jhamman
Copy link
Member Author

jhamman commented Sep 12, 2017

I went ahead and changed the bottleneck version. It really cleans up the all the rolling methods and the testing so I think this is an overall nice change.

try:
import bottleneck as bn
if LooseVersion(bn.__version__) < LooseVersion('1.1'):
raise ImportError
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add a descriptive error message here?

rolling_obj = da_dask.load().rolling(time=7, min_periods=min_periods)
expected = getattr(rolling_obj, name)()

# using all-close becuase rolling over ghost cells introduces some
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because

@pytest.mark.parametrize('min_periods', (1, None))
def test_rolling_wrapped_bottleneck_dask(da_dask, name, center, min_periods):
pytest.importorskip('dask.array')
pytest.importorskip('bottleneck', minversion="1.1")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't these tests now work regardless of whether bottleneck is installed? (obviously performance will be better with bottleneck)

try:
import bottleneck as bn
if LooseVersion(bn.__version__) < LooseVersion('1.1'):
warnings.warn(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we trigger this warning lazily (e.g., when calling actually resample)? If we do this at import time we are going to get a lot of complaints from users using bottleneck < 1.1 about irrelevant warnings.

@jhamman
Copy link
Member Author

jhamman commented Sep 13, 2017

Can we trigger this warning lazily (e.g., when calling actually resample)? If we do this at import time we are going to get a lot of complaints from users using bottleneck < 1.1 about irrelevant warnings.

@shoyer - I'm not exactly sure how to do this consistently throughout the package. In d532a1f
I removed the warning and we fall back to numpy silently. Here's some ideas of what we could do:

  1. Raise an error/warning when an unsupported version of bottleneck is imported
  2. Not check the version of bottleneck at all and live with some harder to predict behavior on rolling.meadian()
  3. Silently fall back to numpy when an unsupported version of bottleneck is imported...and for rolling methods, raise a warning at either import (easy) or runtime (harder).

I'm actually leaning toward 2 right now. We don't enforce strict minimum versions on other dependencies so it seems like what we're trying to do may be a bit overkill.

@shoyer
Copy link
Member

shoyer commented Sep 13, 2017

Not check the version of bottleneck at all and live with some harder to predict behavior on rolling.meadian()

Sounds good to me.

@jhamman
Copy link
Member Author

jhamman commented Sep 14, 2017

any final comments here?

@jhamman jhamman merged commit ae4df1d into pydata:master Sep 14, 2017
@jhamman jhamman deleted the feature/rolling_dask branch September 14, 2017 17:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants