This thread is to discuss the possibility and the design of a Grammar of Graphics API for Plots.jl.
the question of whether Plots will have such an API is one that I've seen quite often (it's the only thing Gadfly has which Plots doesn't, and seems to be a major thing for many data scientists). I have already discussed this with @tbreloff and he has mentioned that he is not interested in creating such an API, though he would accept a PR for one (or have one be an addon package, GGPlots was thrown around).
So, how much interest is there in a Grammar of Graphics API? What is the proper way to design it?
I'd love to see this, especially since I haven't been able to find good introductory resources on GoG -- the best I could find when I last tried to research this (as a layman) was this three-part post, but to be honest I didn't find it particularly insightful.
Incidentally, any pointers to good introductory resources on this topic would be very welcome!
If you want this it's pretty easy to make. I think it should be a
standalone package. GGPlots sounds perfect. Happy to host it in JuliaPlots.
To implement, just make a module Geom, add some types Line, etc. each type
stores keywords that were passed into the constructor. The types should all
subtype the same abstraction, and define '+' between a GGPlot and
AbstractGeom to accumulate all the attributes/series. Easy peasy.
Now the real question... Why does anyone care about this? ;)
On Thursday, October 6, 2016, Waldir Pimenta [email protected]
wrote:
I'd love to see this, especially since I haven't been able to find good
introductory resources on GoG -- the best I could find was this three
http://www.science-craft.com/2014/07/08/introducing-the-grammar-of-graphics-plotting-concept/
-part
http://www.science-craft.com/2014/08/30/implementing-the-grammar-of-graphics/
post
http://www.science-craft.com/2014/10/21/data-visualisation-the-power-and-beauty-of-the-grammar-of-graphics/,
but to be honest I didn't find it particularly insightful.Incidentally, any pointers to good introductory resources on this topic
would be very welcome!—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tbreloff/Plots.jl/issues/520#issuecomment-251923351,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA492hJH-tZjWjPGVWjz59pfiqVRW2X4ks5qxMwpgaJpZM4KPp0i
.
What is the current favourite for tabular data anyways?
As a side note. ggvis moved away from the + chaining that ggplot2 does and uses the %>% instead (just like dplyr does). Seems like a sensible change to consider. I think escher does this in a nice julia way using |> (see https://github.com/shashi/Escher.jl#426-syntax-simplification).
Now the real question... Why does anyone care about this? ;)
Data scientists love it. Can't find the quote, but it's something about how it's building the plot the same way the data is built.
And yeah, when I thought about implementation I came up with something pretty close to your idea, so I think it's worth a thought simply because the implementation really wouldn't be that hard. In fact, this would be a good beginner PR for someone who knows GoG (so likely R) and wants to learn Julia. Just a bunch of types with dispatches on + (or %>%, but that's ugly..) that call plot!() with the right arguments. Since it's the one thing people say is better about Gadfly, it might as well get done.
Data scientists love it
<--- Not a real data scientist then???
Haha guess not. Don't you know THE defining factors of a data scientist? Uses R and ggplot2 of course!
But there is something to say there. A lot of data scientists do use these tools which have a GoG API, and a lot of places teach plotting using that style of API. I think the Plots.jl API is more intuitive, but it wouldn't hurt to have both (with the true API being the current one, the GoG just being an addon using types).
I will admit that I quite like ggplot2 and I use it a lot. My personal truth is that I prefer the ggplot2 syntax for data frames and Plots.jl for other data, which surprise surprise is the same criteria that applies for R vs Julia in my case
I put up a prototype here: https://github.com/JuliaPlots/GGPlots.jl
I won't fill this out into a complete package, but I wanted to give someone a head start if they want to take it on. Just shoot me a message if you want to be the "primary maintainer"!
Most helpful comment
If you want this it's pretty easy to make. I think it should be a
standalone package. GGPlots sounds perfect. Happy to host it in JuliaPlots.
To implement, just make a module Geom, add some types Line, etc. each type
stores keywords that were passed into the constructor. The types should all
subtype the same abstraction, and define '+' between a GGPlot and
AbstractGeom to accumulate all the attributes/series. Easy peasy.
Now the real question... Why does anyone care about this? ;)
On Thursday, October 6, 2016, Waldir Pimenta [email protected]
wrote: