@nicolaromano There is already a ggrastr::geom_point_rast(). My use case was 'suddenly collaborators want all plots ever made for a project in PDF' for a few notebooks consisting mostly of EDA scatterplots. I did not have the patience to wrap every geom_point() individually :)
I'm excited for the new #rstats ggplot2 version coming up that I helped out with. So I thought a fun game might be to post a plot every day and people can guess what the new thing is. No cheating by looking at the NEWS.md file!
Alright, yesterday's plot was difficult to see, as nobody has guessed the new thing. The new thing was that polygons are closed before being deformed by coords.
To make up for the difficulty yesterday, please enjoy today's new thing:
@jadeynryan@njtierney@adamhsparks@milesmcbain
Regarding the ggtern thing; ggtern essentially reimplements some interior parts of ggplot2 and for that reason overwrites ggplot2's methods. I get why this is done, e.g. x and y are hardcoded position aesthetics, but I wouldn't encourage other developers to take the same approach.
As I've been working on legends and axes and stuff, it just makes a lot of things so clear. The justification of legend text used to be an outright horror. Now, that logic could hardly be any clearer:
text <- switch(
text_position,
top = element_text(hjust = 0.5, vjust = 0.0),
bottom = element_text(hjust = 0.5, vjust = 1.0),
left = element_text(hjust = 1.0, vjust = 0.5),
right = element_text(hjust = 0.0, vjust = 0.5)
)
#rstats folks who switched from notebook/rmd/qmd oriented workflows to {targets}, how did you transition? Do you just precompute files with {targets} and then use these in your notebooks? Is rendering a notebook in itself a target? How do you do EDA now versus then?
I find it hard to adapt my analysis mindset to the targets framework
@brodriguesco Ah yes this is helpful for grasping the outline of it. So: yes, you precompute files and yes rendering a notebook is in itself a target. So let's say you try 3 approaches to a problem and find a satisfactory one, you just end up with 2-leaf nodes in targets instead of letting them die in the notebook?
@njtierney Right so I/O and other standardisable tasks should stay in targets? How do you deal with 'due diligence' tasks that you investigate but end up not using for your final goal? Just prune your targets in the end or you keep them around somewhere?
@johnmackintosh@ERDonnachie@eddelbuettel Wasn't too familliar with coalesce() but that seems more like fill behaviour for vectors, whereas %||% is more of a non-vectorised, object-wise operation, if that makes sense.
...find (the positions of) rectangles with the same value. For example the first 'run' is m[1:2, 1:2] in this case, the second m[1:2, 3], third m[3, 1:2] and last m[3, 3].
@Mehrad For my use case probably rows should get priority over columns, so the first example should be m[1, 1:2], m[2, 1] and m[2, 2]. The second example might be m[1, 1:2], m[1, 3], m[2, 1], m[2, 2:3], m[3, 1:2] and m[3, 3].
I don't want to sound ungrateful, but what happened yesterday that made people suddenly interested in a definitely-not-ready-for-proper-use #rstats repo of mine? Anyway, thanks for the interest!