Enhancement proposal: reduce code complexity, improve legends, allow non-incremental plots (for grouped bar) about algebraofgraphics.jl HOT 16 CLOSED

Really nice work! I think it's great to simplify the underlying mechanisms of AlgebraOfGraphics. It also could use some decoupling between syntax, data manipulations, and rendering (IMO, rendering is the one that should be factored out).

I would propose the following way to move forward:

• your rewrite could live in its own experimental package (let's call it AoGBackend for now)
• AlgebraOfGraphics could switch to using that as a backend (but users who don't like the syntax can still use AoGBackend directly)

I believe that things like grouping should not really be in AoGBackend, which should receive the data already grouped (that is, as a list of tables, each with their own key), so that other grouping strategies become possible (multidimensional slices for instance).

Analysis are not really a problem, because that's done before plotting by AlgebraOfGraphics, so you shouldn't worry about those.

The other thing is the + to combine different plots. For example, to do something like

geom = visual(Scatter) + linear
data(df) * style(x, y; kwargs...) * geom

using AoGBackend, we would need to have some sort of "incremental mode" for geometries (not within a single geometry). In particular, it needs to be able to plot! the second series on top of the first one, which may not be completely trivial in the presence of a layout. Do you think that's feasible in your implementation?

from algebraofgraphics.jl.

The whole purpose of the Tables interface is not having to restrict people to Dataframes, though, right?

from algebraofgraphics.jl.

It's about the dependency, and making the same things work with any arbitrary other datatype that satisfies the table interface.

Especially since I usually avoid Dataframes in my projects... Not because I dislike it, but just because it's quite a lot to learn and my data wrangling is usually super simple :D
I just dislike learning & loading the Dataframes package, just to do a simple stacked barplot :D
But I can understand, that this may make the implementation harder, especially since it becomes much harder to dispatch on a type. But I'd definitely try to make all recipes inside AbstractPlotting Dataframes free...And if there are strong reasons to use it, it should likely go into a package for now ;)

from algebraofgraphics.jl.

@SimonDanisch I would probably leave it outside AbstractPlotting for now, because developing is simpler using DataFrames. When we've made some progress we can still get rid of the dependency and port it to AbstractPlotting.

@mkborregaard that's probably true.

@jkrumbiegel Concerning return type: I agree. I think there should be two interfaces. One which looks like standard Makie and returns something that looks like standard Makie. And a second that returns legends, colorbars, etc for easy customization. (In fact there are already two different plotting functions in TabularMakie for this reason.)

Concerning input type: What about the StatsMakie approach of having a custom type Data that wraps a table object that we can dispatch on?

Thanks a lot for this discussion.

from algebraofgraphics.jl.

Having a TableLike type in AbstractPlotting, that wraps any datatype that conforms the Table interface in AbstractPlotting would be great, and a good dispatch target for any other library (e.g. TabularMakie could define converts for Dataframes to such a type).

from algebraofgraphics.jl.

It's about the dependency, and making the same things work with any arbitrary other datatype that satisfies the table interface.

I have secretly hidden inside StructArrays enough table manipulations machinery as to not need DataFrames. In particular, grouping can be done using just StructArrays, which is a dependency already. There is a StructArrays.finduniquesorted that iterates unique values and their indices of a StructArray, and it can be used for groupby.

If yes, I wouldn't oppose to have this directly in AbstractPlotting ;)

IMO, there are four distinct things:

1. A descriptive format (kind of like the TracesScalesLabels discussed above) for these types of plot, where the data is already grouped
2. A sensible way to render this format (allowing to tweaks the layout and what not)
3. A way to generate this format from a table using StatsMakie-like or TabularMakie-like syntax
4. A way to generate this format from a table using AoG syntax

I guess 1 and 2 can happily live in AbstractPlotting. 3. is probably simple enough to implement using the "data wrapper" (I'm happy to help switch from DataFrames.groupby to StructArrays.finduniquesorted if we go in that direction). 4. could probably stay in AlgebraOfGraphics, which would become a purely "syntactical" package (which would help me a lot with maintenance).

from algebraofgraphics.jl.

Thanks for your feedback!

I'll think about the +. I think what it'll boil down to is to add the layout positions to group_dict and figure out a way to merge group_dict and style_dict for multiple plots.

I'll comment here once I've created the package. Are there any other ideas for such a package? If we want to make it usable without AlgebraOfGraphics syntax then we probably don't want to have its abbreviation in the name, do we?

Probably TabularMakie.jl or DataMakie.jl, or so?

Any ideas @SimonDanisch, @jkrumbiegel, @mkborregaard (tagging you as my perceived spokesperson for JuliaPlots)?

from algebraofgraphics.jl.

I went for https://github.com/greimel/TabularMakie.jl

from algebraofgraphics.jl.

Cool! My plan is as follow. I will try to work on a simplified AlgebraOfGraphicsLight that only does the conversion from the AoG language to the TracesScalesLabels format, which consists of three things:

• A list of traces (in "data coordinates")
• A set of scales (discrete and continuous, I assume a unique scale across all traces for now, already "fitted" with the unique values and ranges)
• A set of labels

Then there should be somewhere an implementation on plot for the TracesScalesLabels that does something sensible, and an easy way to get the legend from it (the "fitted scales" and labels should be enough to generate it).

I suspect the TabularMakie package could come very handy to render the TracesScalesLabels object and could potentially have its own way of generating that object.

from algebraofgraphics.jl.

Sounds good!

from algebraofgraphics.jl.

Is it possible to use the Tables.jl interface instead of full blown DataFrames? If yes, I wouldn't oppose to have this directly in AbstractPlotting ;)

from algebraofgraphics.jl.

It might be possible yes.

I think I only need DataFrames-specific stuff twice (operation on grouped data). I could try to make it work with SplitApplyCombine.jl instead.

What's your objection to DataFrames.jl? It's almost 1.0 and it makes things really convenient.

from algebraofgraphics.jl.

Is it about the restriction of inputs (I could just transform it internally) or taking the dependency?

If we use it internally we could use the DataFrames mini language for free (I think). That is we can just allow :var or :var => :new_name or :var => ByRow(log) => :log_var as arguments and DataFrames would handle it for us.

from algebraofgraphics.jl.

Wouldn't transforming internally also lead to copying input data in many cases?

from algebraofgraphics.jl.

I think this should have its own function and not sit in the same recipe pipeline as everything else. First because table-like is not a type and Simon is right that dispatching would be hard. Second because certain recipes might want to define methods for table-like types and that would conflict. Third because the default plotting commands all return FigureAxisPlot, AxisPlot or Plot and returning a Figure with many plots and legend and colorbar breaks that default interface.

from algebraofgraphics.jl.

Closed by #155

from algebraofgraphics.jl.