Removing direction constraint from geoms - #3506
Conversation
|
One thing to consider is how to deal with ambiguity in directional geoms. |
|
This should also deprecate |
|
Could you describe your overarching strategy/expected API? In an ideal world, the stat (e.g. density) shouldn't have to know about x and y at all and just produce two output columns, one for the dependent and one for the independent variable. These could then be mapped to x and y however one wants. However, I haven't been able to make this possible in the existing ggplot2 stat and geom framework. So I assume you're doing something else. Also, are there any parts of the logic that could be encapsulated into reusable functions or maybe into a ggproto superclass, so that not that much code duplication is required? |
|
This is very much WIP at the moment as I’m exploring what is possible. Don’t expect the current state of the code to prevail. The overarching strategy is to let the stats (and geoms) sniff out the wanted orientation from the mapping of the aesthetics. Many are quite easy such as histograms where you just look at whether x or y is mapped. Others need inspection of the data types mapped to x and y to figure out which one is discrete. Others still are fully ambiguous and we’ll need to figure out what to do there. The plan and hope is that it should “just work” by mapping the variables to the right aesthetics, but whether this is possible is open |
|
Auto-detection + optional manual override should work fine. |
|
yeah, that was my plan as well... don't know if we want manual override for all or just the ones where ambiguity exist though |
|
@clauswilke can you remember why you created the AFAIK, |
|
One annoying side effect of this is that many of these stats/geoms have to have their |
|
One way to address the problem of removing required aesthetics will be to add another field to geoms and stats ( |
|
I didn't create |
|
Oh yeah. It was @hrbrmstr. Got it mixed up |
|
Maybe you could make all these I don't see an obvious way to update the documentation generation, ideally we'd special case something where it would generate "x or y". Or maybe a better option would be to introduce some special sentinel value |
|
Can I offer some unsolicited thoughts after seeing this on Twitter? :) I recently implemented something similar in tidybayes (the multiple-orientations-one geom part, not the part that chooses orientation automatically --- I love the idea of having that sniffed out automatically and am planning to add it now too, with an API consistent with whatever is decided here). I came to a similar solution as @thomasp85 : have a parameter like draw_panel = function(self, data, panel_params, coord) {
...
data$y = data$ymin + justification * data$height
...
}Became: draw_panel = function(self, data, panel_params, coord, orientation) {
define_orientation_variables(orientation)
...
data[[y]] = data[[ymin]] + justification * data[[height]]
...
}Which saved me a bunch of A few other things:
|
|
Thanks for chiming in @mjskay... Some quick thoughts:
@hadley the |
|
Ok, last piece of the puzzle: The easiest is to expect the function to output data with |
|
It was really a no-brainer as all of the supplied function returns data in x-orientation format so this is what we continue to support |
|
@thomasp85 can you give me a few pointers as to where to focus my effort? |
|
The main logic lies in |
There was a problem hiding this comment.
Two small documentation comments, otherwise it looks good to go.
|
Haven’t I provided examples for all options in the section ? |
|
This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/ |
Some geoms have directionality constraint, e.g.
geom_histogram()that requires binning along the x-axis. The gospel has been to usecoord_flip()if one wanted binning along the y-axis, but that comes with a set of limitations. Further the constraint seems arbitrary from a user perspective.This PR explores the possibility of making relevant geoms work in either direction. Hopefully this can completely remove the need for ggstance.
Geoms, stats, and positions under consideration
geom_bargeom_histogramgeom_violingeom_colgeom_linerange()geom_pointrange()geom_errorbar()geom_crossbar()geom_boxplot()geom_density()geom_area()geom_ribbon()geom_line()geom_smooth()stat_bin()stat_boxplot()stat_count()stat_density()stat_ydensity()(consider renaming this for clarity)stat_summary()position_dodge()position_dodge2()position_fill()position_stack()position_jitterdodge()Please add to this list if anything comes up. @clauswilke when we have settled on this it would be great if ggridges could be updated to reflect this as well