# Upcoming AlgebraOfGraphics release

**URL:** <https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968>\
**Category:** Package Announcements\
**Tags:** announcement, plotting, data, algebraofgraphics\
**Created:** [May 11, 2021, 4:47pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968 "2021-05-11T16:47:54Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![piever](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/piever/32/1815_2.png) [@piever](https://discourse.julialang.org/u/piever)\
**Post date:** [May 11, 2021, 4:47pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/1 "2021-05-11T16:47:54Z")

</div>

This is a pre-announcement about an upcoming release of [AlgebraOfGraphics](https://github.com/JuliaPlots/AlgebraOfGraphics.jl):

 ![logo_aog](https://global.discourse-cdn.com/julialang/original/3X/e/2/e2260d2eeab059cd130acf20a6541a5e284ba065.png)

AlgebraOfGraphics defines a language to make data visualizations by combining basic building blocks with `*` and `+`. It is based on [Makie](https://github.com/JuliaPlots/Makie.jl) to actually draw the plots.

The code base had grown a bit out of hand and has mostly been rewritten to make sure that the library works robustly. It still will take a little bit of work before tagging the next release, but it’s probably a good time for users to try out the unreleased version (with `] add AlgebraOfGraphics#master`) to give feedback. There are many planned features and it would be useful to get a sense of which are most needed.

To get a sense of how the next release will work, you can try out the brand new [penguin tutorial 🐧](http://juliaplots.org/AlgebraOfGraphics.jl/dev/generated/penguins/) or read the [philosophy](http://juliaplots.org/AlgebraOfGraphics.jl/dev/philosophy/) section of the docs.

## Demo

```julia
axis = (width = 225, height = 225)
penguin_bill = data(penguins) * mapping(
    :bill_length_mm => (t -> t / 10) => "bill length (cm)",
    :bill_depth_mm => (t -> t / 10) => "bill depth (cm)",
)
layers = linear() + mapping(col = :sex)
plt = penguin_bill * layers * mapping(color = :species)
draw(plt; axis)

```

 ![penguin_bill](https://global.discourse-cdn.com/julialang/original/3X/d/d/ddac138e79cf9d3b8432884bb9d20db5028bb8be.png)

---

<div class="post-metadata">

**Author:** ![sijo](https://avatars.discourse-cdn.com/v4/letter/s/da6949/32.png) [@sijo](https://discourse.julialang.org/u/sijo)\
**Post date:** [May 11, 2021, 6:49pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/2 "2021-05-11T18:49:46Z")

</div>

This looks extremely promising! I like the composition design that encourages variables with useful names and reuses the DataFrames mapping syntax. Using distributivity for shared configuration seems just right. Also impressed by your theme… pleasant and very readable.

Small feedback on the API: are you sure about abbreviations such as “col” and “wts”? I think they hurt accessibility for new users, and readability in general, which outweighs the modest gain in keystrokes. Subjective matter of course 🙂

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [May 11, 2021, 7:15pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/3 "2021-05-11T19:15:45Z")

</div>

I’m looking forward to using this.

* * *

> [@sijo](#):
>
> are you sure about abbreviations such as “col” and “wts”? I think they hurt accessibility for new users, and readability in general, which outweighs the modest gain in keystrokes.

I agree that abbreviations make reading harder. It can make writing harder too since I have to remember the word _and_ its abbreviation.

* * *

A separate issue:

```julia
mapping(
    :bill_length_mm => (t -> t / 10) => "bill length (cm)",
    :bill_depth_mm => (t -> t / 10) => "bill depth (cm)",
)

```

This API seems to resemble `DataFrames.transform()`, but it’s not quite the same; in Dataframes we would have `ByRow`:

```julia
transform(
    :bill_length_mm => ByRow(t -> t / 10) => "bill length (cm)",
    :bill_depth_mm => ByRow(t -> t / 10) => "bill depth (cm)",
)

```

whereas in the proposal here the row-wise operation is implicit.

Explicit `ByRow` allows me to do column-wise operations by not using the `ByRow`. For example, I can take z-score transformation of the whole column, which I can’t do if I only have access to one element at a time because it needs to take the mean and standard deviation of the column. I can also use broadcasting to act on each element more concisely: `=> x -> x ./ 10 => `.

* * *

I’m guessing

```julia
draw(plt; axis)

```

mutates its `axis` argument? If so, I’d expect it to be `draw!(axis, plt)` with the `!` to indicate argument-mutation and the reversed argument order following the common convention that the container argument comes first.

* * *

The facet section [http://juliaplots.org/AlgebraOfGraphics.jl/dev/generated/gallery/#Faceting](http://juliaplots.org/AlgebraOfGraphics.jl/dev/generated/gallery/#Faceting) says " The “facet style” is only applied with an explicit call to `facet!` ." but the examples don’t show that.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [May 11, 2021, 11:18pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/4 "2021-05-11T23:18:39Z")

</div>

Beautiful!

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [May 12, 2021, 12:07am UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/5 "2021-05-12T00:07:27Z")

</div>

Due to the dependence on Makie the following question is crucial: has it become any easier  
to make Makie run on systems people use, including Windows?

Last time I tried I couldn’t get it to work.

---

<div class="post-metadata">

**Author:** ![ArchieCall](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/archiecall/32/206_2.png) [@ArchieCall](https://discourse.julialang.org/u/ArchieCall)\
**Post date:** [May 12, 2021, 3:47am UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/6 "2021-05-12T03:47:27Z")

</div>

I had the same issue with not being able to run Makie on and old Windows laptop. After upgrading to a new laptop this year it ran OK.

---

<div class="post-metadata">

**Author:** ![Jakob](https://avatars.discourse-cdn.com/v4/letter/j/71c47a/32.png) [@Jakob](https://discourse.julialang.org/u/Jakob)\
**Post date:** [May 12, 2021, 11:04am UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/7 "2021-05-12T11:04:51Z")

</div>

I’m running all makie backends on a 4 year old dell xps13 and a desktop PC with a nvidia GPU, both with windows 10 and it all runs without issue.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [May 12, 2021, 11:40am UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/8 "2021-05-12T11:40:01Z")

</div>

The api looks convenient and easy to use, so I have the following questions.  
Does/will AoG work in jupyter and pluto notebooks, and can it be saved as raster (png) and vector (pdf) plots? I could not find such examples in the linked docs.  
Is interactivity considered to be in scope? E.g., something simple like selections in vegalite, for cross-panel highlights.

---

<div class="post-metadata">

**Author:** ![sijo](https://avatars.discourse-cdn.com/v4/letter/s/da6949/32.png) [@sijo](https://discourse.julialang.org/u/sijo)\
**Post date:** [May 12, 2021, 1:40pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/9 "2021-05-12T13:40:33Z")

</div>

> [@jzr](#):
>
> I’m guessing `draw(plt; axis)` mutates its `axis` argument?

No `axis` is just a named tuple (see the first line) so this is equivalent to `draw(plt, axis=(width=225, height=225)`. There is also a `draw!` function.

> [@aplavin](#):
>
> Does/will AoG work in jupyter and pluto notebooks, and can it be saved as raster (png) and vector (pdf) plots?

Yes using CairoMakie you can show plots in notebooks and save to PDF and PNG.

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [May 12, 2021, 5:56pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/10 "2021-05-12T17:56:06Z")

</div>

> [@sijo](#):
>
> No `axis` is just a named tuple (see the first line) so this is equivalent to `draw(plt, axis=(width=225, height=225)` . There is also a `draw!` function.

Thanks for the correction. Since `Axis` already has a meaning in Makie, I might use a different name for that.

---

<div class="post-metadata">

**Author:** ![piever](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/piever/32/1815_2.png) [@piever](https://discourse.julialang.org/u/piever)\
**Post date:** [May 13, 2021, 10:30am UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/11 "2021-05-13T10:30:01Z")

</div>

Thanks for the feedback and nice words!

> [@sijo](#):
>
> Small feedback on the API: are you sure about abbreviations such as “col” and “wts”? I think they hurt accessibility for new users, and readability in general, which outweighs the modest gain in keystrokes. Subjective matter of course

I think `row / col` is reasonable, as it is consistent with `eachrow / eachcol` in Base, `nrow / ncol` in DataFrames, and `Row / Col` in GridLayoutBase, which AlgebraOfGraphics uses for layouting. On `wts` on the other hand I completely agree with you. It came from `GLM.lm`, but it looks like [they also plan on changing to `weigths`](https://github.com/JuliaStats/GLM.jl/issues/350). I’ll change it before releasing.

> [@jzr](#):
>
> A separate issue:
> 
> ```julia-auto
> mapping(
> :bill_length_mm => (t -> t / 10) => "bill length (cm)",
> :bill_depth_mm => (t -> t / 10) => "bill depth (cm)",
> )
> 
> ```
> 
> This API seems to resemble `DataFrames.transform()` , but it’s not quite the same; in Dataframes we would have `ByRow` :
> 
> ```julia-auto
> transform(
> :bill_length_mm => ByRow(t -> t / 10) => "bill length (cm)",
> :bill_depth_mm => ByRow(t -> t / 10) => "bill depth (cm)",
> )
> 
> ```
> 
> whereas in the proposal here the row-wise operation is implicit.

I should probably add a FAQ section and add this to the FAQs. The operation is row-wise by design, and operations that take the whole column are not supported on purpose. My reasoning to prefer row-wise operations (other than performance) is that whole-column operations are error prone, especially when

1. the data is grouped or
2. different datasets are used.

The issue with 1. is that it is no longer completely clear whether you should apply the operation by group or globally.

To exemplify 2., in AlgebraOfGraphics you can do things like `(data(df1) * visual(color = :red) + data(df2) * visual(color = :blue)) * mappings`. If you were to eg `zscore` here, you would be normalizing differently and then plotting together, which could be questionable.

I think it’s best if the user does whole-column operations beforehand and simply adds the resulting column to the dataset.

> [@jzr](#):
>
> The facet section [Example gallery · Algebra of Graphics](http://juliaplots.org/AlgebraOfGraphics.jl/dev/generated/gallery/#Faceting) says " The “facet style” is only applied with an explicit call to `facet!` ." but the examples don’t show that.

Well spotted, that was a leftover from a previous version, I’ve fixed it.

> [@jzr](#):
>
> Since `Axis` already has a meaning in Makie, I might use a different name for that.

I’m just using Makie syntax to pass attributes to the axis, see [Plot Method Signatures · Makie Plotting Ecosystem (juliaplots.org)](https://makie.juliaplots.org/dev/plot_method_signatures.html#Special-Keyword-Arguments). One way to think of it is that `axis` and `figure` are not axis and figure objects, but rather axis and figure settings.

> [@PetrKryslUCSD](#):
>
> Due to the dependence on Makie the following question is crucial: has it become any easier  
> to make Makie run on systems people use, including Windows?

I am on Windows and I haven’t experienced any issues. The CairoMakie backend (which I use for clean vector graphics) might well be the most robust, as it does not rely on the GPU.

> [@aplavin](#):
>
> Does/will AoG work in jupyter and pluto notebooks, and can it be saved as raster (png) and vector (pdf) plots? I could not find such examples in the linked docs.

See [Backends & Output · Makie Plotting Ecosystem (juliaplots.org)](https://makie.juliaplots.org/dev/backends_and_output.html). You could probably also try WGLMakie in Pluto to have interactive plots in the browser (zooming and panning).

> [@aplavin](#):
>
> Is interactivity considered to be in scope? E.g., something simple like selections in vegalite, for cross-panel highlights.

It’s not a high-priority item for me (I’d like to make sure the “bases” are completely solid first), but it’s definitely possible. It’ll be interesting to see what possibility Makie opens for this type of interactivity.

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [May 13, 2021, 11:27am UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/12 "2021-05-13T11:27:58Z")

</div>

I think your reasoning about why to avoid column-wise operations makes sense, but I feel like the very similar syntax but different semantics from the DataFrames DSL will be confusing / error-prone. I wonder if ByRow could move to DataAPI and then AoG could just require it? Like one would write it as

```julia
:bill_length_mm => ByRow(t -> t / 10) => "bill length (cm)"

```

always even though there’s no column operations supported?

Also, something that I think is cool about the this `Pair` based syntax used in both packages is that you can save it as a variable and re-use it, like

```julia
bill_length_cm = :bill_length_mm => ByRow(t -> t / 10) => "bill length (cm)"

```

If the semantics were the same between AofG and DataFrames, you could actually reuse transformations between the packages as well! So you can have not only column-names as re-usable variables to programmatically generate things, but also transfromations.

by the way, the new release looks awesome! Love the penguin tutorial as well.

---

<div class="post-metadata">

**Author:** ![pdeffebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pdeffebach/32/10320_2.png) [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)\
**Post date:** [May 13, 2021, 12:06pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/13 "2021-05-13T12:06:33Z")

</div>

@piever There is an un-exported macro in DataFramesMeta for creating `src => fun => dest` syntax called `@col`. It’s unexported for now, for no real reason I guess. [here](https://github.com/JuliaData/DataFramesMeta.jl/blob/master/src/macros.jl).

It might be of interest to you for testing your implementation of `src => fun => dest` and might be a convenient macro in general if more packages copy that API.

---

<div class="post-metadata">

**Author:** ![ElOceanografo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eloceanografo/32/624_2.png) [@ElOceanografo](https://discourse.julialang.org/u/ElOceanografo)\
**Post date:** [May 13, 2021, 1:02pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/14 "2021-05-13T13:02:20Z")

</div>

This looks like a great package! Looking through the penguins tutorial, I was wondering why the continuous colormap (e.g. for the density plots) is different than the default in Makie (Viridis, I think)?

---

<div class="post-metadata">

**Author:** ![piever](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/piever/32/1815_2.png) [@piever](https://discourse.julialang.org/u/piever)\
**Post date:** [May 13, 2021, 1:59pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/15 "2021-05-13T13:59:16Z")

</div>

Viridis is definitely a good choice. AlgebraOfGraphics theme uses Batlow. See [The misuse of colour in science communication (nature.com)](https://www.nature.com/articles/s41467-020-19160-7.pdf) for a nice read about color maps, or the first author’s website [Colour maps (fabiocrameri.ch)](https://www.fabiocrameri.ch/colourmaps/), which also has a few other nice options.

My main reason for not using the default Viridis is that AoG uses the same color palette both for heatmaps and scatter plot (coloring the “fill” of the markers, which in AoG have no stroke). While Viridis works well for heatmaps, I find that the “upper range” of Viridis (green and especially yellow) is a bit problematic for markers on a light background, see for example [the scatters in this blog post](https://www.r-bloggers.com/2018/07/ggplot2-welcome-viridis/).

Theming attributes for plots (if I understand correctly) requires a little bit of cleanup on the Makie side, but then it should be easy to make these choices fully customizable for users.

---

<div class="post-metadata">

**Author:** ![piever](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/piever/32/1815_2.png) [@piever](https://discourse.julialang.org/u/piever)\
**Post date:** [May 13, 2021, 2:27pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/16 "2021-05-13T14:27:58Z")

</div>

> [@ericphanson](#):
>
> I think your reasoning about why to avoid column-wise operations makes sense, but I feel like the very similar syntax but different semantics from the DataFrames DSL will be confusing / error-prone. I wonder if ByRow could move to DataAPI and then AoG could just require it?

The pair syntax actually originated in JuliaDB, and there it is row-wise (JuliaDB tables are distributed, so there row-wise is a very natural choice). `TableOperations.transform` also is row-wise, I suspect for similar reasons (the whole columns are not available in general). But your point still stands, as I suspect many more users are familiar with DataFrames than with JuliaDB.

This definitely requires some thinking. I wonder whether DataFrames plans to have some other functions with “row-wise” semantics, eg `map(df, :x => f => "f(x)")`, or whether they’ll use the whole-column approach uniformly. Recycling “pairs” across packages would indeed be nice.

> [@pdeffebach](#):
>
> @piever There is an un-exported macro in DataFramesMeta for creating `src => fun => dest` syntax called `@col` . It’s unexported for now, for no real reason I guess. [here](https://github.com/JuliaData/DataFramesMeta.jl/blob/master/src/macros.jl).

That looks pretty interesting! Esp. for automated naming (and automatically creating anonymous functions) a macro can be pretty powerful.

---

<div class="post-metadata">

**Author:** ![pdeffebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pdeffebach/32/10320_2.png) [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)\
**Post date:** [May 13, 2021, 2:31pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/17 "2021-05-13T14:31:01Z")

</div>

One difference is that DataFrames needs to support grouped operations, where you want to act on the whole column, otherwise the grouping would be meaningless. So DataFrames chose by column as the default to avoid introducing a whole other syntax for grouped operations.

---

<div class="post-metadata">

**Author:** ![ElOceanografo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eloceanografo/32/624_2.png) [@ElOceanografo](https://discourse.julialang.org/u/ElOceanografo)\
**Post date:** [May 13, 2021, 3:10pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/18 "2021-05-13T15:10:13Z")

</div>

Got it. I wasn’t familiar with Batlow, and couldn’t tell if it was perceptually uniform at first glance, so thanks for the reference!

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [May 14, 2021, 8:36pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/19 "2021-05-14T20:36:24Z")

</div>

Is there an equivalent of coord\_flip? Maybe there’s an abstraction that works better in 3D.

> **[Cartesian coordinates with x and y flipped — coord\_flip](https://ggplot2.tidyverse.org/reference/coord_flip.html)**
>
> Flip cartesian coordinates so that horizontal becomes vertical, and
> vertical, horizontal. This is primarily useful for converting geoms and
> statistics which display y conditional on x, to x conditional on y.

---

<div class="post-metadata">

**Author:** ![sijo](https://avatars.discourse-cdn.com/v4/letter/s/da6949/32.png) [@sijo](https://discourse.julialang.org/u/sijo)\
**Post date:** [May 15, 2021, 12:21pm UTC](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968/20 "2021-05-15T12:21:13Z")

</div>

> [@piever](#):
>
> I think `row / col` is reasonable, as it is consistent with `eachrow / eachcol` in Base, `nrow / ncol` in DataFrames, and `Row / Col` in GridLayoutBase, which AlgebraOfGraphics uses for layouting.

That’s true, but on the other hand AlgebraOfGraphics has `color` which makes it ambiguous (I was actually confused by this initially, that’s what prompted me to suggest a change). I also think the API would feel more consistent without this single abbreviation but that’s a very minor point.

[Next page](https://discourse.julialang.org/t/upcoming-algebraofgraphics-release/60968.md?page=2)
