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

[BUG] Using array/list in line_dash for hspan doesn't work #13838

Open
huaracheguarache opened this issue Apr 25, 2024 · 7 comments
Open

[BUG] Using array/list in line_dash for hspan doesn't work #13838

huaracheguarache opened this issue Apr 25, 2024 · 7 comments

Comments

@huaracheguarache
Copy link

Software versions

Python version : 3.12.2 (main, Feb 21 2024, 00:00:00) [GCC 14.0.1 20240217 (Red Hat 14.0.1-0)]
IPython version : (not installed)
Tornado version : 6.4
Bokeh version : 3.4.1
BokehJS static path : /var/home/michael/src/koding/python/bokeh_hspan/.venv/lib/python3.12/site-packages/bokeh/server/static
node.js version : (not installed)
npm version : (not installed)
jupyter_bokeh version : (not installed)
Operating system : Linux-6.8.7-300.fc40.x86_64-x86_64-with-glibc2.39

Browser name and version

Firefox 125.0.2

Jupyter notebook / Jupyter Lab version

No response

Expected behavior

Specifying line_dash in hspan should produce an hspan line with the given dash pattern.

Observed behavior

Specifying line_dash as an array/list causes the plot to not display properly. I can't see the hspan line, and when I pan the plot it starts to slide down towards the lower right corner (see attached screencast).

Using string names such as "solid" and "dashed" works ok.

Example code

from bokeh.plotting import figure, show

plot = figure()
plot.line(x=[-5, 5], y=[-5, 5])
plot.hspan(y=0, line_dash=[5, 5])

show(plot)

Stack traceback or browser console output

No response

Screenshots

Screencast.from.2024-04-25.15-17-45.webm
@mattpap
Copy link
Contributor

mattpap commented Apr 25, 2024

plot.hspan(y=0, line_dash=[5, 5])

line_dash=[5, 5] is interpreted in this context as two data points with line_dash=5, which on its own doesn't make sense and lack of proper validation of scalar/vector properties allows this to be propagated to bokehjs. The best way to deal with array scalars is to use the following syntax:

from bokeh.core.properties import value
plot.hspan(y=0, line_dash=value([5, 5]))

This way no interpretation will be performed and the resulting plot will work as expected.

@bryevdv
Copy link
Member

bryevdv commented Apr 25, 2024

Is this something specific to hspan? Or a new development? I am nearly 100% certain that line_dash=[5, 5] has worked in other contexts in the past.

@huaracheguarache
Copy link
Author

line_dash=[5, 5] works with line, which is why I found it curious that it didn't work with hspan. It also doesn't work with vspan when I checked just now. @mattpap's suggested workaround fixes the issue for hspan and vspan.

@mattpap
Copy link
Contributor

mattpap commented Apr 26, 2024

line_dash=[5, 5] works with line

This works, because Line glyph uses scalar visual properties, i.e. you provide a single value for all data points, thus an array is interpreted as a value. HSpan and VSpan glyphs, however, use vectorized visual properties and thus the interpretation is different.

@mattpap
Copy link
Contributor

mattpap commented Apr 26, 2024

Is this something specific to hspan? Or a new development? I am nearly 100% certain that line_dash=[5, 5] has worked in other contexts in the past.

It always worked like this. Another similar prominent case is Figure.image_rgba(image=[img]) (or image=value(img)). As mentioned in my previous comment, the difference for line_dash comes from the difference in behavior between scalar and vector visual properties.

@mattpap
Copy link
Contributor

mattpap commented Apr 26, 2024

Alternatively one can also use this:

plot.hspan(y=0, line_dash=[[5, 5]])

@bryevdv
Copy link
Member

bryevdv commented Apr 26, 2024

I think this can be made to meet expectations, so I would suggest we triage as a bug. For specialized line-dash properties I think it would acceptable for a vector spec to inspect the entire given value to see whether it is a flat list, or a nested list, and act accordingly.

Edit: IIRC the original concern with image glyphs was the cost of inspecting potentially large data structures in the ragged array case, but now that we no longer accept ragged arrays as input maybe the image case could be similarly improved (but that deserves a separate issue)

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

No branches or pull requests

3 participants