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

Implemented correct Raster.range #1255

Merged
merged 1 commit into from Apr 10, 2017

Conversation

Projects
None yet
2 participants
@philippjfr
Member

philippjfr commented Apr 8, 2017

Fix for #1020, it wasn't accessing the masked array directly and hence was returning inconsistent results with Image, which does.

%%opts Raster Image [colorbar=True]
tmp = np.random.rand(10,10)-0.5
tmp = np.ma.masked_where(tmp<=0, tmp)

hv.Image(tmp)+hv.Raster(tmp)

image

As we can see the masked values are no longer included in the range but are still indicated via the colorbar and the behavior is now consistent between Raster and Image.

@philippjfr philippjfr added the bug label Apr 8, 2017

@jlstevens

This comment has been minimized.

Member

jlstevens commented Apr 8, 2017

Looks good. Any tests we can add to make sure we don't lose the new (desired) behavior?

Otherwise happy to merge.

@philippjfr

This comment has been minimized.

Member

philippjfr commented Apr 10, 2017

Ready, merge when tests pass.

@jlstevens

This comment has been minimized.

Member

jlstevens commented Apr 10, 2017

Tests are passing. Merging.

@jlstevens jlstevens merged commit 9fcf1ee into master Apr 10, 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 First build on fix_raster_range at 78.897%
Details
s3-reference-data-cache Test data is cached.
Details

@philippjfr philippjfr deleted the fix_raster_range branch Apr 11, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment