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
Merged

Cleaned up Element range handling #1876

merged 1 commit into from Sep 13, 2017

Conversation

@philippjfr
Copy link
Member

@philippjfr 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
Copy link
Contributor

@jlstevens 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
Copy link
Member Author

@philippjfr 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
Copy link
Contributor

@jlstevens 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
Copy link
Member Author

@philippjfr 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
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
@philippjfr
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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants