Finer control over aesthetic evaluation #3534

thomasp85 · 2019-09-19T18:43:59Z

This PR implements a parallel to stat(), called mod() that allows you to mark aesthetics for evaluation just before they are send to the draw method in the geom. At this point the data has been mapped so expressions inside mod() will work with mapped data.

The prime use case for this is for tying colour and fill values together:

library(ggplot2)
library(colourspace) # for lighten()
p <- ggplot(mpg, aes(class, hwy))
p + geom_boxplot(aes(colour = class, fill = mod(lighten(colour, 0.4))))

As can be seen the legend needs some work, but I open now so we can discuss this feature

hadley

Seems fine to me, except that mod() is too short; it's too likely to conflict with other packages and it's not going to be used that commonly so it doesn't need to be really short.

R/aes-calculated.r

thomasp85 · 2019-09-19T19:38:17Z

any good suggestions on name? mapped() or modify_mapped() springs to mind. The former is a bit more in line with stat()

clauswilke · 2019-09-19T20:28:07Z

I like mapped(). I wouldn't use modify_mapped() because the mapping doesn't have to be modified. Sometimes it may be a good idea to just reuse a mapping, for example because it is quite complex. E.g., in the example below, being able to reuse the colour mapping without retyping everything might be nice. As an alternative to mapped(), you could also consider remap().

library(ggplot2)

ggplot(mpg, aes(class, hwy)) +
  geom_boxplot(aes(colour = ifelse(class %in% c("pickup", "suv", "minivan"), "large car", "small car"))) +
  scale_color_discrete(name = NULL)

^{Created on 2019-09-19 by the reprex package (v0.3.0)}

thomasp85 · 2019-09-20T07:31:50Z

changed name to mapped() but if anything better comes along I'm not married to that name. Fixed legend so the updated aesthetics get reflected:

ggplot(mpg, aes(class, hwy)) +
  geom_boxplot(aes(colour = class, fill = mapped(alpha(colour, 0.4))))

yutannihilation · 2019-09-21T09:49:59Z

Cool, this solves the frequent request like #3485.

Minor question, do we need to be tolerant for color here?

ggplot(mpg, aes(class, hwy)) +
  geom_boxplot(aes(color = class, fill = mapped(alpha(color, alpha))), alpha = 0.4)
#> Error in as.character(col) %in% "0": object 'color' not found

thomasp85 · 2019-09-21T10:23:25Z

Yeah — I thought about that as well. I think we should

clauswilke · 2019-09-21T13:38:34Z

That's an excellent point. Aesthetics names get standardized as described/implemented here:

ggplot2/R/aes.r

Lines 150 to 163 in b560662

    
           #' This function standardises aesthetic names by converting `color` to `colour` 
        
           #' (also in substrings, e.g. `point_color` to `point_colour`) and translating old style 
        
           #' R names to ggplot names (eg. `pch` to `shape`, `cex` to `size`). 
        
           #' @param x Character vector of aesthetics names, such as `c("colour", "size", "shape")`. 
        
           #' @return Character vector of standardised names. 
        
           #' @keywords internal 
        
           #' @export 
        
           standardise_aes_names <- function(x) { 
        
             # convert US to UK spelling of colour 
        
             x <- sub("color", "colour", x, fixed = TRUE) 
        
             # convert old-style aesthetics names to ggplot version 
        
             revalue(x, ggplot_global$base_to_ggplot) 
        
           }

Ideally the same rules should apply inside mapped(). Maybe it's possible to apply standardise_aes_names() to all symbols inside the mapped() expression?

…c names

thomasp85 · 2019-09-23T07:38:27Z

I have implemented a way to recurse through aesthetic expressions ago substitute names to standard aesthetic nomenclature. We should consider this carefully though as I don't think many people are aware of the old-style support and may be surprised that their variables are getting renamed..?

thomasp85 · 2019-09-23T10:01:28Z

So... this PR has experienced a little feature creep 🙂

I've added a new control function as well called stage() which effectively lets you remap aesthetics between stat, geom, and mapped. This address recurring needs to decouple the output of stats from the mapping of geoms. The stat() and mapped() functions persists as shortcuts when multiple mappings are not needed.

API (continuing with the same example):

ggplot(mpg, aes(x = stage(stat = class, geom = x + 0.5), y = hwy)) +
  geom_boxplot(aes(colour = class, fill = mapped(alpha(color, alpha))), alpha = 0.4)

thomasp85 · 2019-09-23T10:36:43Z

@lionel- can I get you to have a look at the meta-programming stuff and make sure I've not done something terribly stupid?

has2k1 · 2019-09-23T10:52:46Z

For the name, as this functionality is similar to hjust and vjust of geom_text how about aes_adjust.

R/aes.r

lionel- · 2019-09-23T11:01:53Z

R/aes-calculated.r

@@ -36,7 +73,12 @@ is_dotted_var <- function(x) {
 is_calculated_aes <- function(aesthetics) {
  vapply(aesthetics, is_calculated, logical(1), USE.NAMES = FALSE)
 }
-
+is_mapped_aes <- function(aesthetics) {


These semantics feel a bit sloppy to me because they allow users to affect the interpretation of an expression by using mapped() or stage() deep in the call, even though that applies to the whole expression, not subparts. It seems it would be cleaner to require the qualifier to be at top-level.

Then you could check for a mapped() call at top level, and bind mapped to a function that fails with an error message in the function-level of the data mask.

On a side note, I find it confusing to have is_ predicate return length != 1 vectors. I think an is_ function should always be safe to use in if () (length 1, no missing value). In rlang I use the are_ prefix for vectorised predicates (but this convention wasn't picked up anywhere else I think).

The whole is_mapped and is_mapped_aes setup is borrowed completely from the way stat() calls are handled. @hadley do you think there is reason to rewrite them both?

Yeah, we should definitely only allow these at the top-level for new code. It's probably too late to change the behaviour of stat(), unless you want to deprecate it first.

ok, so I'll provide simplified parsers for mapped() (or whatever it ends up being called) and stage()

Also expected:

is_call(~ foo()) #> [1] TRUE is_call(~ foo(), "foo") #> [1] FALSE is_call(~ foo(), "~") #> [1] TRUE

A quosure is not a call, and a formula is a call to ~. Some functions in rlang will unwrap formulas and quosures automatically, but is_call() is too low level for that.

Ah... I misunderstood... I thought that FALSE was an error and that it would be fixed with next release...

so... would this be the correct way to test for whether a quosure is of a specific call?

is_call(quo_squash(t), 'test')

or are there any gotchas to that approach?

You should almost never use quo_squash(), its name is meant to be scary ;). quo_get_expr() is the way to extract an expression.

If you know you have a quosure, use quo_is_call() or is_call(quo_get_expr()).

If you'd like to automatically unwrap quosures and formulas (this can be tricky and cause unexpected results), use is_call(get_expr()).

get_expr(quote(foo())) #> foo() get_expr(~ foo()) #> foo() get_expr(quo(foo())) #> foo()

R/aes-calculated.r

clauswilke · 2019-09-23T14:19:44Z

On old-style support: I think pch at least is reasonably common in the wild. See e.g. here for an example I found within 2 minutes of googling. If we want to deprecated old-style names, we should probably do it in two stages, where we first just add a warning that informs people they're using old-style names and that support for this may go away in the future.

On the name of the function stage(): I don't find this name particularly intuitive. What is a "stage" in a geom? I also feel that a verb would be better than a noun. (I assume you mean "stage" as a noun, not a verb, here). I don't yet have the best proposal, but something like map_at() might work. I'll ponder some more.

thomasp85 · 2019-09-23T14:58:15Z

stage is indeed meant as a verb. We are staging multiple mapping of the same aesthetic

clauswilke · 2019-09-23T15:27:15Z

stage is indeed meant as a verb.

Ah, Ok.

thomasp85 · 2019-09-23T15:29:36Z

As for old-style name. I do t suggest we deprecate them. But we need to be careful about this as there is a difference in supporting them as argument names and substituting their use inside expressions. The later will mask any variable that coincide with an old-style name

NAMESPACE

R/aes-calculated.r

hadley · 2019-09-30T13:58:28Z

R/aes-calculated.r

@@ -36,7 +73,12 @@ is_dotted_var <- function(x) {
 is_calculated_aes <- function(aesthetics) {
  vapply(aesthetics, is_calculated, logical(1), USE.NAMES = FALSE)
 }
-
+is_mapped_aes <- function(aesthetics) {


Yeah, we should definitely only allow these at the top-level for new code. It's probably too late to change the behaviour of stat(), unless you want to deprecate it first.

R/geom-.r

R/aes-calculated.r

…g docs for aes evaluation

…layed-aes

hadley · 2019-10-11T13:31:50Z

Can you write a NEWS bullet please? I find them very helpful for giving me the PR context (which I've usually forgotten, and I'd prefer not to have to re-read the entire thread)

thomasp85 · 2019-11-14T10:17:00Z

news bullet added @hadley

hadley

Overall interface looks good to me. I didn't closely review the implementation.

thomasp85 · 2019-12-16T09:29:06Z

can you approve if you trust me on the implementation 🙂

…layed-aes

POC for mod

c2e0ec2

hadley reviewed Sep 19, 2019

View reviewed changes

R/aes-calculated.r Outdated Show resolved Hide resolved

change structure of is_modifier

471e602

thomasp85 added 2 commits September 20, 2019 09:29

Change name to mapped() and document

b87bf1f

propagete mapped values to legend

5244e86

thomasp85 marked this pull request as ready for review September 20, 2019 07:32

thomasp85 changed the title ~~POC: mod() to delay aesthetic calculation until after mapping~~ mapped() to delay aesthetic calculation until after mapping Sep 20, 2019

recursively rename symbols in mapped expressions to standard aestheti…

a31270a

…c names

thomasp85 changed the title ~~mapped() to delay aesthetic calculation until after mapping~~ Finer control over aesthetic evaluation Sep 23, 2019

thomasp85 added 2 commits September 23, 2019 11:56

More correct name substitution - only target symbols

051595f

Add stage() for multistage mapping of aesthetics

afbafcd

lionel- reviewed Sep 23, 2019

View reviewed changes

clean up aes name substitution based on comments from @lionel-

3ee9ee9

thomasp85 added this to the ggplot2 3.3.0 milestone Sep 27, 2019

thomasp85 requested a review from hadley September 30, 2019 11:14

hadley reviewed Sep 30, 2019

View reviewed changes

thomasp85 added 5 commits October 11, 2019 12:06

Rename aes eval controls, soft-deprecating stat(), along with updatin…

c2cc849

…g docs for aes evaluation

Update code to use after_stat() instead of stat()

1e9fc9b

Merge branch 'master' of https://github.com/tidyverse/ggplot2 into de…

9b51f36

…layed-aes

use dev version of rlang

b60af39

Fix stage eval

3713e08

thomasp85 requested a review from hadley October 11, 2019 12:15

Add news bullet

db53358

hadley reviewed Dec 13, 2019

View reviewed changes

hadley approved these changes Dec 16, 2019

View reviewed changes

thomasp85 added 2 commits December 16, 2019 14:31

Merge branch 'master' of https://github.com/tidyverse/ggplot2 into de…

2ca3a40

…layed-aes

Fix bad merging

658a9b0

thomasp85 merged commit fc60051 into tidyverse:master Dec 16, 2019

yutannihilation mentioned this pull request Jan 7, 2020

Warn on stat() and ..var..-notation? #3693

Closed

yutannihilation mentioned this pull request Jun 30, 2022

Let stage() work without after_stat or after_scale #4890

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Finer control over aesthetic evaluation #3534

Finer control over aesthetic evaluation #3534

thomasp85 commented Sep 19, 2019

hadley left a comment

thomasp85 commented Sep 19, 2019

clauswilke commented Sep 19, 2019 •

edited

Loading

thomasp85 commented Sep 20, 2019

yutannihilation commented Sep 21, 2019

thomasp85 commented Sep 21, 2019

clauswilke commented Sep 21, 2019

thomasp85 commented Sep 23, 2019

thomasp85 commented Sep 23, 2019

thomasp85 commented Sep 23, 2019

has2k1 commented Sep 23, 2019

lionel- Sep 23, 2019

lionel- Sep 23, 2019

thomasp85 Sep 23, 2019

hadley Sep 30, 2019

thomasp85 Sep 30, 2019

lionel- Oct 10, 2019

thomasp85 Oct 10, 2019

thomasp85 Oct 10, 2019

lionel- Oct 10, 2019

lionel- Oct 10, 2019

clauswilke commented Sep 23, 2019

thomasp85 commented Sep 23, 2019

clauswilke commented Sep 23, 2019

thomasp85 commented Sep 23, 2019

hadley Sep 30, 2019

hadley commented Oct 11, 2019

thomasp85 commented Nov 14, 2019

hadley left a comment

thomasp85 commented Dec 16, 2019

Finer control over aesthetic evaluation #3534

Finer control over aesthetic evaluation #3534

Conversation

thomasp85 commented Sep 19, 2019

hadley left a comment

Choose a reason for hiding this comment

thomasp85 commented Sep 19, 2019

clauswilke commented Sep 19, 2019 • edited Loading

thomasp85 commented Sep 20, 2019

yutannihilation commented Sep 21, 2019

thomasp85 commented Sep 21, 2019

clauswilke commented Sep 21, 2019

thomasp85 commented Sep 23, 2019

thomasp85 commented Sep 23, 2019

thomasp85 commented Sep 23, 2019

has2k1 commented Sep 23, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clauswilke commented Sep 23, 2019

thomasp85 commented Sep 23, 2019

clauswilke commented Sep 23, 2019

thomasp85 commented Sep 23, 2019

Choose a reason for hiding this comment

hadley commented Oct 11, 2019

thomasp85 commented Nov 14, 2019

hadley left a comment

Choose a reason for hiding this comment

thomasp85 commented Dec 16, 2019

clauswilke commented Sep 19, 2019 •

edited

Loading