Scaled sliders - convergence with bqplot and altair

SylvainCorlay commented 7 years ago

The convergence of `altair`, `bqplot` and `Jupyter interactive widgets`

A quick unordered list of issues that seem unrelated at first but will all come together nicely with this proposal

@jdemeyer, in his work on Sage integration, fixed some semantics on our use of isinstance. He suggested that instead of having separate IntSlider and FloatSlider, we merge in a single numeric slider.

The implementation of Jupyter widgets for manipulating integers and floats are essentially the same since everything maps to the same front-end implementation, especially since we rely on d3.format mini-language for the readout format. The difference between the integral and continuous variants is merely the default value for the display format.

Note: in another unrelated discussion, (selection widgets), he taught me to type ABCs) I think that we could try to use a hierarchy of trait types mapping the types ABCs such as [PEP 3141] https://www.python.org/dev/peps/pep-3141/), the type hierarchy for numbers.
There has been discussions on how we could move away from the current implementation of the Jupyter-widgets slider.
- We want to get rid of jquery-ui, which is terrible and is not a good citizen of the browser.
- We want ticks to indicate the current level of the slider, and move the readout so that it does not eat too much of the available length for the slider.
- @jasongrout was proposing the super-lean no-ui slider as a replacement.
bqplot users have created helper functions that result in flat figures with brush or index selectors, that they use to select single values or intervals on date scales, logscales, with graduation.
How current bqplot sccales wrap d3 scales in a meaningful fashion: A d3 scale is typically a mapping between a domain (the data) and a range (the visual quantity that it is being mapped to). A bqplot scale is a jupyter widget that does not have a visual representation.
- The model holds the domain information and has no information about the range.
- The view is typically instanciated as a child view of another widget (e.g. a figure). So it know the actual dimension of the parent view, and can deduce the range.
- The view is the object holding the d3 scale, since it has all the information about domain and range.

Proposal

We introduce bqplot-like scales as jupyter widget scales (linear, dates, ordinal, color), and maybe refactor the ones of bqplot to use those.
sliders and progress bars will hold a scale. A linear slider will simply have a linear scale. A selection slider will have an ordinal scale etc.
d3 will be used to render the widgets, so that we will be able to get rid of the jquery-ui implementation, and have all the benefits from d3 (tick formatting, minor / major tick marks / slider on color scales etc...)
This will not require a lot of code from d3, since the project went through a split in multiple standalone projects. In fact, we already use d3.format for the readout.
The scales would also be used by other projects that need mapping to colors / dates. @maartenbreddels is looking into convergence between bqplot, ipyvolume, pythreejs, and factoring out some these abstractions would help.

SylvainCorlay commented 7 years ago

cc @ellisonbg @jasongrout @maartenbreddels @jakevdp

This is still being edited.

dmadeka commented 7 years ago

cc @ssunkara1 @dmadeka @rmenegaux @ccherukuri? People that might be affected - i.e. the core bqplot team?

maartenbreddels commented 7 years ago

👍 good timing, I'm at the stage where I am about to add ticks to ipyvolume, and I will use d3 for that, so I'll be ready to adapt to using future scales. This would make linking bqplot axes, ipyvolume axes, and sliders possible, I like the proposal. Even starting out with just linear scales will help, that's I guess 80% of the use cases.

jdemeyer commented 7 years ago

He proposed that instead of having separate IntSlider and FloatSlider, we adopt trait types that map to PEP 3141, the type hierarchy for numbers.

For the record: this is not what I proposed. I simply proposed that IntSlider and FloatSlider should be part of some common base class, say NumericSlider, but I never said that this should relate to PEP 3141. I do want sliders which work for any numeric type and I don't see how PEP 3141 could help with that.

jdemeyer commented 7 years ago

See #721 for that discussion.

SylvainCorlay commented 7 years ago

The PEP 3141 was mentioned in another discussion with you about our use of isinstance #236. There was also your PR about using the collections ABC in #722.

ellisonbg commented 7 years ago

Thanks for getting this started...

The lack of solid scale implementations in Python is a huge issue that keeps showing up all over the place:

Pandas has the ability to color/size/style cells based on data. They had to sort of fake invent scales...
Libraries such as Matplotlib, Boken, Seaborn have poor handling of non quantitative data types (nominal, ordinal, date-time, etc). This is largely due to the fact that they don't have a full set of scales that can map between different data types to the different visual properties (shape, size, color, position, etc.)
We would like to implement a Matplotlib renderer for Altair. The main barrier for that is the lack of solid Python based scales.
Scales are definitely needed to map data to sliders and progress bars...

The thing that I think would be most useful:

A fully declarative set of scales.
A Pure Python (traitlets) implementation of those scales.
A Pure Python implementation of those scales that are widgets and sync to JS.

Using widgets alone for this won't work as there are multiple Python libraries (Pandas, Matplotlib) that need Python scales and don't ever know about JS. Doing this would mostly involve porting the ds scales to Python...

Cheers, Brian

jdemeyer commented 7 years ago

The PEP 3141 was mentioned in another discussion with you about our use of isinstance #236. There was also your PR about using the collections ABC in #722.

Right, but I never proposed to use the numbers ABC (PEP 3141) for sliders. So I would appreciate it if you fix the issue description :-)

Would this proposal affect SelectionSlider in any way?

SylvainCorlay commented 7 years ago

The PEP 3141 was mentioned in another discussion with you about our use of isinstance #236. There was also your PR about using the collections ABC in #722.

Right, but I never proposed to use the numbers ABC (PEP 3141) for sliders. So I would appreciate it if you fix the issue description :-)

OK, since you taught me about type ABCs, I mixed the two issues (collections and numbers). I edited the description. There was no intention of misrepresenting what you have said.

So regarding the selection slider, this could be based on a d3 ordinal scale.

SylvainCorlay commented 7 years ago

The thing that I think would be most useful:

A fully declarative set of scales.

A Pure Python (traitlets) implementation of those scales.

A Pure Python implementation of those scales that are widgets and sync to JS.

For a pure backend implmentation of scales, we will probably need a formal spec, otherwise, we will end up having inconsistencies between the different implementations.

jasongrout commented 7 years ago

This is related to #1134.

vidartf commented 7 years ago

I've made a very humble beginning for this in https://github.com/vidartf/ipyscales. Any and all input is welcome 👍

jupyter-widgets / ipywidgets