Discussion: constructors for HLine, VLine and ErrorBars

[ea42gh]

would it be worthwhile to allow constructors for HLine, VLine that

• accept a list of values
• do not cycle colors

e.g, allow replacing

%%opts VLine (color='black')
curve * hv.Overlay([hv.VLine(k) for k i vline_list])

with curve*hv.VLine( vline_list )

[ea42gh]

ErrorBars: allow an option to specify that ErrorBars are given as actual values rather than offsets, e.g. given a pandas DataFrame df with columns v,v_low, and v_high, allow something like hv.ErrorBars(df, vdims=['v','v_low','v_high'], relative_offset=False) rather than require a user code level computation of the relative offsets from v

[jlstevens]

Thanks for the suggestions!

The idea of adding HLine and VLine that accept lists of values is a good one. I think we want to move away from annotations so maybe we might want to add HLines and VLines (now plural) as 'real' elements in an analogous way to how we want to generalize the Text annotation.

I'm not sure about suppressing the color cycle as that would happen anyway if a single element is used to draw multiple lines at once. In other words, your second bullet point automatically follows from your first one but maybe you you know this and that is what you meant!

[ea42gh]

Another thought: could there be a flag to suppress the automatic range adjustment for Elements in an Overlay? I find myself repeatedly adding lines, sectors, other Curves and then having to call redim.range() to reset it to what it would have been in the absence of those elements.

Is there an easy way to retrieve a "current range" on an Overlay that would simplify this?

[jlstevens]

@philippjfr What do you think? Interesting suggestion but I think it would be for a separate issue.

[philippjfr]

Allowing a list to be passed to HLine and VLine seems sensible. I'm not sure I want HLines and VLines as well though as things will start getting confusing and cluttered. I'd probably just prefer allowing both and wrapping scalars supplied to HLine and VLine in a list (I think I feel the same way about Text, instead of adding a MultiText element or similar).

[jlstevens]

I agree with the potential for confusion - I'm thinking we would deprecate the old annotation elements in version 2.0. I suppose we could easily generalize HLine and VLine though handling Text seems a lot trickier.

I'll assign myself the task of extending the constructor and hooking it into the plotting code.

[jbednar]

I vote for just making each of them handle multiple items, rather than create any new Element types.