Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleaned up Element range handling #1876

Merged
merged 1 commit into from Sep 13, 2017

Conversation

Projects
None yet
2 participants
@philippjfr
Copy link
Contributor

philippjfr commented Sep 12, 2017

As described in #1870, QuadMesh is currently not handling explicitly set dimension ranges. This PR adds a utility to combine the data range with the dimension ranges and uses it in various Element.range implementations.

@philippjfr philippjfr force-pushed the quadmesh_range branch 2 times, most recently from 643fa8f to 5c493a4 Sep 12, 2017

"""
Computes the range along a dimension by combining the data range
with the Dimension soft_range and range.
"""

This comment has been minimized.

@jlstevens

jlstevens Sep 12, 2017

Contributor

I would be surprised if we don't have very similar logic to this somewhere else in holoviews already...

This comment has been minimized.

@jlstevens

jlstevens Sep 12, 2017

Contributor

I see you replaced two chunks of code with this utility below, is that everywhere this utility could be used?

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Sep 12, 2017

Looks good.

It would be good if you could check that dimension_range can't be used in more places (I suspect so, but I might be wrong!). Otherwise happy to merge.

@philippjfr philippjfr force-pushed the quadmesh_range branch 2 times, most recently from 35e02c3 to 6a0ab9b Sep 12, 2017

@philippjfr philippjfr changed the title Cleaned up Element range handling and fixed QuadMesh range Cleaned up Element range handling Sep 12, 2017

@philippjfr

This comment has been minimized.

Copy link
Contributor Author

philippjfr commented Sep 12, 2017

I think this was long overdue tbh, there were various inconsistencies in the implementations.

@philippjfr philippjfr force-pushed the quadmesh_range branch 4 times, most recently from 09a5fb1 to 0c76497 Sep 12, 2017

@philippjfr philippjfr force-pushed the quadmesh_range branch from 0c76497 to 35bbc26 Sep 13, 2017

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Sep 13, 2017

Tests are green, if you think you've used this new utility everywhere that makes sense, I'm happy to merge.

@philippjfr

This comment has been minimized.

Copy link
Contributor Author

philippjfr commented Sep 13, 2017

Yes, that's every single range implementation now.

@jlstevens jlstevens merged commit 204941a into master Sep 13, 2017

4 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage increased (+1.3%) to 79.601%
Details
s3-reference-data-cache Test data is cached.
Details

@philippjfr philippjfr deleted the quadmesh_range branch Sep 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.