Shortcuts for commonly used compound charts such as pairplot from Seaborn

[ChristopherDavisUCI]

One of the first functions I learned in Seaborn was pairplot and I still use it frequently. Would there be interest in sneaking a version of this function into Altair? We could borrow from @joelostblom's pair function in Altair Ally (although I personally am more used to the redundancy in the Seaborn version, where each quantitative variable gets assigned to the x-axis and also assigned to the y-axis).

Any thoughts on this? Sometimes I make something similar using alt.repeat, but the diagonal charts (where the same variable gets encoded simultaneously in both the x channel and the y channel) make the whole thing look less nice to me.

[joelostblom]

I personally think it would be great with another level of charts in altair that are simpler to make and have specific functions, but less customizability. For me this is mostly for Exploratory Data Analysis when we are not looking to carefully craft each chart but quickly get an accurate overview of the data (this is currently somewhat laborsome with the repeat operators). I am mostly thinking about compound plots (such as "pairplot") and purpose-specific plots (such as a NaN plot or correlation plot), where the syntax to create these in altair directly is rather verbose (often because it requires repeating or transformations). I think the altair syntax is already terse enough for e.g. scatter plot, line plots etc and don't think we need a higher level layer for those.

This would diverge from the spirit of Altair only doing what VegaLite does, but I think it would also be tremendously helpful and it is present in other similar package such as seaborn, plotly express, holoviz, etc. For me, these functions are many of the ones I have included in altair ally and maybe when they become more mature we could move the most relevant into the core of altair under a altair.eda submodule (or similar)?

[ChristopherDavisUCI]

Thanks a lot @joelostblom, that sounds good to me. No need for this to be prioritized, but I think it would be very helpful for Altair "beginners".

My intuition is that Altair is a good place for this, but if you think that Vega-Lite would instead be a more reasonable place, let me know and I can post something there (or go ahead if you want to).

[joelostblom]

I also think altair would be a good place for this, but it is always good to hear if they are planning something similar in Vega-Lite, even in the long-term, so feel free to open an issue there as well to ask.

[ChristopherDavisUCI]

@joelostblom I will take a closer look at what you have in https://github.com/joelostblom/altair_ally My biggest priority is including something like pairplot from Seaborn. Do you think any of the other chart types from Altair Ally would be good to prioritize? I support anything that we think would be used frequently. (And conversely, if people don't think a pairplot function would be used often in Altair, then I'm happy to drop it as an idea.)

[joelostblom]

My hope would be to eventually implement everything from https://joelostblom.github.io/altair_ally/examples.html (and possibly others). The approach I have taken for the functionality in pairplot is via aly.pair + aly.dist. I personally think the mirrored scatters are unnecessary and it is less confusing to just have the corner. I also don't really see the benefit of the diagonal distributions versus just putting them under that pairwise scatter plot.

Also please note that although the library works largely, there has definitely not been any robustness tests (or code tests at all), and some things are just hacked together for now so I think some solid work would be needed before it being considered in a library at altair (but at the same time we need people to use it to experience exactly where it breaks, so maybe an experimental altair.eda submodule or something like that 🤷

[joelostblom]

Coming back to this, reflecting on some recent occurrences where people have reached for other tools than Altair, I do find that maybe the most common scenario is when they are doing EDA and need to create charts of repeated columns quickly. repeat can get quite verbose and sometimes these "all columns" chart also involve a transform_fold and it often become too much to type for a quick check of the data, particularly when looking for a specialized repeated chart that it seems like Altair might not have (like a chart of missing values, a correlation, or parallel coordinates). These are charts that are included in other common libraries such as seaborn and plotly express, whereas e.g. ggplot keeps them in separate packages.

This was a reminder about our discussion here and it makes me inclined to want to include the type of charts that I have in https://joelostblom.github.io/altair_ally/examples.html (plus more heatmap seriation/ordering) directly into a submodule to Altair. I will try to do some work in that package over the summer, but I wanted to check already if you @mattijn @binste and @ChristopherDavisUCI think this could be a viable option for inclusion in Altair or if it deviates too much from the package's purpose (which I think has already expanded beyond a simple vega-lite wrapper, but this inclusion of specialized charts would still be a notable step). The immediate upside is discoverability and ease of use for end-users (which I do think is quite important), but one immediate downside I can think of is that it would give less flexibility in terms of dependencies since I think e.g. scipy would become a dependency of altair_ally when I add heatmap ordering (but this could be made an optional dependency). I also think this fits nicely as part of Altair's mission to "empower you to spend less time writing code and more time exploring your data."

[binste]

Thank you for bringing it up again! I do like the idea of having an easy way to do some common more complex charts to quickly explore data and as long as they are placed into a separate submodule (such as eda which you proposed) I think it's a great convenience feature without it impacting the rest of the library as long as we don't have to add required dependencies. If it requires multiple additional dependencies, it would hinge for me on if we are ok with making them optional or if this gets too confusing if a submodule requires 2+ additional packages. In that case we could also promote altair_ally in the official Altair docs with a separate section in the user guide referencing the package and showing some examples? Curious to hear more inputs.

Regarding customisation, maybe we could include some examples of how to access and modify the individual charts of a returned multi-view chart. Or even provide a convenience method on the .concat and .layer attributes or even on any arbitrary top-level Altair chart to retrieve the subchart by name (name being the name attribute which can be passed to alt.Chart(name=...):

nan_chart = aly.nan(penguins)
right_bar_chart = nan_chart.get_chart("bars")  # This does a lookup on nan_chart.concat and retrieves the chart with .name == "bars"

[joelostblom]

If it requires multiple additional dependencies, it would hinge for me on if we are ok with making them optional or if this gets too confusing if a submodule requires 2+ additional packages. In that case we could also promote altair_ally in the official Altair docs with a separate section in the user guide referencing the package and showing some examples?

Yeah, I think this sounds like a reasonable approach. I think it would only be scipy that would be added as an optional dependency (for now at least, and I will think about it I could remove it or if more would be added in the future). Promoting in the official docs sounds like a good solution if there ends up being too many optional dependencies (I will explore this more over the summer), but being part of the official Altair package always has the upside of it being more discoverable.

Regarding customisation, maybe we could include some examples of how to access and modify the individual charts of a returned multi-view chart.

Yes, definitely. This is one of the things I have wanted to add for some time but not gotten too yet. I also want to add a more consistent way of making the plots (e.g. always using concat or faceting), with the purpose of making the configure_* methods work to customize the subplots (not sure yet if this is possible).