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

Allow * to work on an NdLayout (and more) #2075

nleclercq opened this Issue Nov 2, 2017 · 2 comments


None yet
3 participants

nleclercq commented Nov 2, 2017

The story began with the following use case: how to overlay a selection box on images attached a to hv.NdLayout?

Implementing such a feature with a hv.Holomap is quite trivial and would only require 5 lines of code:

images = {en:hv.Image(ed) for en, ed in xrarray_dataset.data_vars.items()}
box = hv.streams.BoundsXY(source=hm, bounds=(0,0,0,0))
bounds = hv.DynamicMap(selection_callback, streams=[box])
hv.HoloMap(images, kdims=['img']) * bounds

Accordingly, one would legitimately expect the same approach to work with a hv.NdLayout:

images = {en:hv.Image(ed) for en, ed in xrarray_dataset.data_vars.items()}
box = hv.streams.BoundsXY(source=hm, bounds=(0,0,0,0))
bounds = hv.DynamicMap(selection_callback, streams=[box])
hv.NdLayout(image).cols(2) * bounds

Unfortunately, with holoviews <= 1.9, the overlay operator * doesn’t work with hv.NdLayout.
The main feature request would consequently be to allow the overlay operator to work with hv.NdLayout.

@philippjfr and @jlstevens already had a short discussion about this feature request on gitter. @jlstevens suggested to extend support to the hv.Layout. Here is the main part of that discussion:

a feature request to allow * to work on an NdLayout seems sensible.

I'm not sure I recommend that
the code for mul is spread out and pretty impenetrable imho!

Yeah, I don't expect it to be too hard, the main issue arises from the fact that NdLayout lives in core/layout which can't import from core/overlay, may have to move it to core/spaces before doing that.

one thing though…if * works for hv.NdLayout, why not hv.Layout?
isn't it the same semantics?
which I haven't yet figured out btw
is it a layout * element where the element is broadcast to all the parts of the layout?
or layout * layout where you overlay pairwise....though that if they have different lengths?

I don't have any major objection to that, the difference is that hv.NdLayout is a homogeneous collection so wanting to overlay something on all the components is more common.
I wouldn't go so far as support hv.layout * hv.layout

I'm just saying that I don't see why to make hv.NdLayout a special case if the semantics also apply equally to hv.Layout
I have mixed feelings then... if we want * on layout I would like it to be as general as * everywhere else

I have no objection to hv.layout * hv.element, matching up potentially heterogeneous collections of things as in layout * layout is not a rabbithole I necessarily want to go down.

I think hv.layout * hv.layout sort of makes sense... you overlay the zip portion and append what is left from the longer one

I suppose, can't see myself wanting that very much but those semantics are easy to implement at least.

hv.Layout([(el1 * el2) for el1, el2 in zip(layout1, layout2) ]) + hv.Layout(remaining_items)
it isn't something I would necessarily encourage or use much myself
but I think that is conceptually simple enough


This comment has been minimized.


jbednar commented Nov 3, 2017

Seems like a reasonable request with clear semantics to me, more or less like NumPy broadcasting for elementwise operations. I wouldn't want to have to implement it, though!

@philippjfr philippjfr added this to the v1.10 milestone Nov 3, 2017

@philippjfr philippjfr self-assigned this Feb 20, 2018


This comment has been minimized.


philippjfr commented Mar 22, 2018

Looking back at this I have to say I'm not a huge fan of implementing this for Layout, since they are heterogeneous collections, while NdLayout is a clear cut homogeneous collection where this should be supported for consistency with GridSpace, which already works.

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