HoloViews Backend

[so-rose]

Hello,

I've just been starting to use spb, and it's absolutely wonderful.

I was wondering if you've made any considerations of "HoloViews" (https://holoviews.org) as a backend. It is itself a data-focused abstraction on top of Bokeh, Plotly and MPL, with several wonderful ease-of-use features:

• Very easy composition (+ for side-by-side, * for overlay): https://holoviews.org/user_guide/Composing_Elements.html
• Consistent data labeling: https://holoviews.org/user_guide/Annotating_Data.html
• Consistent styling with .opts() called on plots: https://holoviews.org/user_guide/Applying_Customizations.html#core-concepts
• ...and more.

Such a backend would enable

• Effortless plot composition with any library that also produces HoloView plots, also with interactivity.
• Consistent backend-abstracted styling (ex. a PDF w/matplotlib and a HTML w/plotly would be comparable), including colormaps, labeling, etc. .

For example, combining symbolic mathematics with experimental data (ex. to show a least-squares fit) could just be (allowing for misunderstandings in how I think these things work):

## 'data' is a Pandas dataframe.
## hvplot <https://hvplot.holoviz.org/> easily creates HV plots from Pandas dataframes
## c0..c3 predefined, x is a sympy symbol

data.hvplot.scatter(
	x="x",
	y="y",
	label="Experimental Data",
).opts(
	color="black",
	ylabel="Value",
) * spb.plot(
    (c0 + c1*x + c2*sp.sin(x) + c3*sp.cos(x)),
    backend = spb.HV,  ## Theoretical HoloViews Backend
).opts(
	color="red",
	ylabel="Value",
)

Challenges might include:

• 3D plotting support in HV is very limited; only really MPL support. Insofar as it exists, however, it is precisely as ergonomic as the 2D support.
• Implicit regions may take some finagling in HV; these are quite important to get right for a sympy plotting backend.
• HV has strong support for interactivity, but mapping SPB parameters to HV parameters may not be a simple task.
• An abstract backend involves more moving parts that are harder to predict, and might incur extra maintenance burden.
• HV is very much a "give me data and tell me what to do with it" plotlib, which is an approach that may produce friction with SPB's "tell me what you are and I'll make it look ideal".

I hope the suggestion is appreciated; the use case of easily visually layering data with symbolic expressions is one I deal with a lot.

Anyway, this library is an absolute joy to use; thank you for writing it, and I wish you a great day!

[Davide-sd]

Hello @so-rose , thanks for opening this issue.

Holoviews was the first thing I considered even before creating the first version of this package. It would have been a natural choice, after all interactivity (with parameters) was the main goal and motivation for me to implement a "new plotting library", and I was already using Holoviz Panel. So, making the jump to Holoviews would have been relatively simple.

However, 3D capabilities and implicit plotting are both very important to me. Matplotlib's 3D capabilities are limited, and Plotly 3D charts were slow to generate (this was the situation as of April 2021). The open source community offered other plotting libraries, like K3D-Jupyter which is amazing for 3D plots with 1:1:1 aspect ratio, as well as Aysmptote for publication-quality plots. This alone made me opt-out from the idea of using Holoviews, because it would have prevented me from using other libraries.

Also, the idea was to keep the API back-compatible with what was already available in SymPy, in order to get an easier merging process. Great effort went into making this plotting module back-compatible, only to find out that some SymPy devs are against the idea of having a decent plotting module, so I'm afraid it will never get merged :|

These considerations led me to the actual implementation.

HV has strong support for interactivity, but mapping SPB parameters to HV parameters may not be a simple task.

Theoretically, it's should not be that hard. Numerical data is generated by data series using the get_data(params) method, where params is a dictionary mapping symbols to the numerical values of widgets. Ideally, one would build a wrapper function to create this dictionary, then generate numerical data with get_data(params), and give it to holoviews.

Unfortunately I don't have time to work on this. I'll leave this issue open: if you or anybody else would like to attempt to adapt the module to work with Holoviews, I'm fine with that, as long as the current implementation keeps working (there are a great number of tests that assures that).

Anyway, this library is an absolute joy to use; thank you for writing it, and I wish you a great day!

Thank you for your kind words and for opening this issue :)