Comparison to ipywidgets#
ipywidgets already provides both an
interact and an
interactive_output function, so why use mpl_interactions instead? There are three reasons: performance, portability, and convenience.
This explanation is built on the description here: matplotlib/ipympl#36 (comment)
The ipywidgets functions expect the entire output to be regenerated every time a slider value changes. This means ipywidgets functions will work best with the
inline backend. In fact, some special casing is even available to better support the inline backend. Unfortunately this process does not work well with the interactive
ipympl backend. The
ipympl backend expects to be shown only once, then updated with Matplotlib methods as controls change. What results is you needing to make multiple new figures—or recreate the entire plot—every time a slider value changes.
It is possible to get around these performance issues by using the
interact function and setting the called function to use Matplotlib updating methods (such as
set_data()). However in this case, not only do you need to remember how to do this, but over time you will find you are repeating yourself. Reducing these performance barriers was the initial motivation for the
mpl_interactions library, and also brings us to the reason of convenience.
mpl_interactions will make use of the widgets provided by ipywidgets if they are available. Unlike interactive output, it will still work if called from a script or an (i)python REPL by falling back to the built in Matplotlib widgets.
With the interact function (ipywidgets.interact) you are responsible for generating the data to plot, and for handling the logic to update the plot.
f(x,...) => y
Plotting logic (
mpl_interactions only requires you specify the data you want to plot and will handle the plot creation and updating for you.
Additionally, there are multiple valid strategies for choosing what selection widgets to create for a parameter. As a general framework the choices made by ipywidgets are not always ideal for plotting scientific data. Unencumbered by generality,
mpl_interactions makes several slightly different choices that are more plotting focused.
Differences in generated widgets#
Here is a comparison of the generated widget for
two_tuple = (1., 5) and
three_tuple = (0., 1250, 100):
ipywidgets will assume a NumPy array or list are categoricals.
mpl_interactions will attempt to make a slider for the values.
For example, here is what ipywidgets and
mpl_interactions will create for
In the context of a single number, for example,
param = 10.:
Treats the parameter as fixed.
Creates a slider with a range of