What do you know about the current state of GR? The information on the web is pretty sparse about the plans for future development. I can see some bug-fixing on github, but if you say that the problem with the vanishing windows is ancient, that doesn’t bode well.
He’s working on a totally different GUI. Watch the JuliaCon video where he shows it. Just ask in the Gitter for an update: I’m curious why it hasn’t been released.
The reason I advocate GR as the first-choice backend (not default - that’s up to the user) for Plots is the responsiveness of the backend author. Josef very often fixes reported GR/Plots issues on the day they’re opened. The only serious issue I’m aware of is the window not reopening after closing manually; if you have a habit of constantly closing down your plotting window I can understand why that would be annoying.
In my view that tone is unconstructive.
8 Likes
@mkborregaard: on the contrary, stating that plotting in Julia is dismal has the potential of being constructive.
Just realizing that there is a problem gets you halfway to the solution.
Would you argue with the statement that there is a problem with plotting? If so, what is it that you use that works? And I mean, really works (fast, no major bugs).
Complaining about problems doesn’t actually amount to half of the work of improving a project like julia. /snarkiness ends
Seriously:
Gadfly.
A beatiful and very well-functioning graphics package using the grammar-of-graphics interface, the interface that dominates R.
PyPlot.
A feature-complete representation of matplotlib, one of the best and most iconic plotting libraries in any programming language.
Plotly(JS).
A featurecomplete julia version of one of the prettiest and most modern cross-language plotting libraries out there.
GR.
Stable, mature, very fast cross-platform library.
ggplot2 through RCall.
Why the h*ll not? Just add R" to your code and fire away.
Plots
A distinctly julian plotting solution, based on ecosystem integration, a macro-based DSL, an ultra-light dependency, multible dispatch and type awareness. A much newer project, but very focused on intuitiveness in the interface and generating coherence in the package ecosystem.
Of course improvements can happen. Fortunately the community is very open for ideas and contributions.
4 Likes
The people working the hardest on plotting in Julia already know its limitations. Open source development is thankless work, so any comment that can be interpreted as disparaging someone’s efforts at best isn’t constructive, and at worst will burn people out so they stop working on stuff for free.
I promote Plots + GR to everyone I know who’s tries out Julia. Of the several issues I’ve reported, I had a response within a day and fixes within a week. Here are two things I’ve made in the last week. The ease of making these through Plot’s recipes and animation support is downright amazing.
14 Likes
To elaborate a little bit more on @mkborregaard’s answer. GR, PyPlot, and Plotly(JS) backends (with and without Plots frontend) all support 3D. One important thing though, setting the triangles explicitly in a trisurf plot, is still PyPlot only and not through Plots.jl either. Everyone doing finite element method PDE solving need this when solving on non-convex domains. But PyPlot and Plotly slow down if you put too many points into it, which doesn’t happen as easily with GR. But Plotly you can use on a website, so this website is able to use just the standard DiffEq recipes since it outputs the Plotly JSON via the Plots backend. You don’t get the recipes, the 3D, the trisurf, etc. with pretty much anything with Gadfly, but for the few things it can do you do get a complete Grammar of Graphics API. None of these though give editable TeX code, whereas the PGFPlots backend does. And in a pinch when you don’t have browsers or GUIs available (on some remote server), UnicodePlots will still plot using the same recipes when it’s a backend to Plots.jl.
Even then, not even PyPlot (not even matplotlib, it’s not a wrapper thing) does tetramesh for 4D FEM plots. That’s still MATLAB-only.
Every backend has a purpose if you go deep enough. And since matplotlib is still missing things it’s crazy to think that we can just build up a single library that does it all in a year (especially when one doesn’t donate code 
). We’re still not at a great point but plotting is at least good and there’s lots of things which are easier to do in Julia than other places.
Josef responds really fast, but it seems that the Windows issues never stay fixed. A large part of that are GUI issues though. I don’t plan on bugging him again until the new GUI is out because of that.
If you want a backend that just always works for Plots, it’s Plotly. That thing works everywhere and all the time. Even when Plots doesn’t support a Julia version update you can find ways to make the Plotly backend work 90% of the time. It’s crazy. But since it always opens to a browser I agree it shouldn’t be the default, but since it builds automatically and works so well it’s something for people to consider if they are having issues.
I realize the difficulty. I have written hundreds of thousands of lines of open source code myself. But, when something is not working it is probably better if the community knows about it. Not everybody follows issues on github all the time…
Well, you may be lucky. I couldn’t get this combination to work for either 0.6 or 0.7. There are multiple GR bugs at play. I understand that at least one of them is several years old.
I said that newbies should not be exposed to a bewildering array of choices. What is needed is a simple, totally unobtrusive graphics solution that covers the basic tasks. More sophisticated users will use whatever they prefer.
To illustrate my point:
I rest my case, your honor.
3 Likes
If you want a backend that just always works for Plots, it’s Plotly. That thing works everywhere and all the time.
Nope, not here (Win10). Installed Plots.jl recently in my 0.6 and a simply plot just opened an empty page in the browser.
1 Like
Interesting. Never seen that on Windows 10. Filed an issue? What browser?
Firefox. Opened issue [https://github.com/JuliaPlots/Plots.jl/issues/1138](https://github.com/JuliaPlots
So, note that I actually agree that Julia should have some inbuilt functionality to make plotting more coherent, and that the current fragmented situation isn’t ideal. But what is it you suggest exactly?
Gadfly has already been special-cased for years. It features prominently on the julialang website, all plots on the homepage are made with that, Julia Computing explicitly uses it for almost every example, and it comes bundled with JuliaPro. It also does what you request - it produces basic plots reliably. But some people spending more time with julia find they prefer different plotting packages. Making that even more default than it is risks blocking these people’s options.
I fundamentally don’t think desicions on the language design should be based around beginner adaptation alone. I think they should be based around making it the best language, in turn making it worthwhile to adapt. Beginner adaptation should be facilitated by good documentation, a welcoming and responsive community, and e.g. lots of answered StackOverflow questions.
What I do think Base Julia should contain is some method for plotting specification that can permeate the ecosystem. Look at @sdanisch 's idea: he wants to provide a new interface, a new output and way of interacting with it - but still to use Recipes (and PlotUtils and parts of Plots). Adopting recipes means that he will have access to all functionality plotted in association with the Plots ecosystem - right out of the box! Almost everything associated with Plots is programmed as recipes. Imagine what that means for a new plotting package to have all the specialised plotting methods available from the out. And importantly it will come with no price in terms of the interface he can offer.
It’s a big problem, both for plotting packages but in fact generally in open source, that some projects arise because a person or a group put all their energy into it - it becomes very successful, but after a few years the person behind loses steam or some other package becomes the fashion, and that’s that. Huge amounts of dedicated work is lost in that way. The key to resolving this is modularity, where sound functionality can persist and be reused for other functionality, as opposed to monolithic frameworks. And some specification that allows plotting methods to be specified in a package-independent way will ensure continuity of the ecosystem, and make it much much easier to create new plotting packages that offer novel and creative ways of specifying and interacting with visualizations.
3 Likes
Actually I was going to suggest to promote GR as the default graphics package. It is fast (minimal dependencies), it can do 2D and 3D, claims to be platform and device independent, and offers some interactivity (and perhaps more interactivity is coming).
It looked good until I tried running a few plotting exercises myself. The first bug was apparently also the one that’s been around a long time: a closed plotting window means no more plotting until the kernel is restarted. But I’ve seen a few other problems as well: for instance the following piece of code produces neither a legend, nor axis labels. (It is a slightly tweaked example from one of the presentations of GR.)
using GR
GR.clearws()
figure(figsize=(6,4))
d = 2*rand(15).-1.0
plot(collect(1:length(d)), d, "r")
xlim([0.0, length(d)])
ylim([-1,+1])
legend("H1 strain")
xlabel("Index")
ylabel("whitented strain")
title("Advanced LIGO WHITENED strain data near GW150914")
GR.updatews()
All I get is
I think the bugs can be exterminated, and I still believe GR would be a good choice of something supported with Julia out of the box, no hassle basic plotting, and for framework builders it may be a boon too: it would be great to have something stable that one can build upon.
The idea behind Plots.jl is very appealing. It may be also very hard to implement due to the multitude back ends that need supporting. Doing what Plots.jl does but only with GR would make the job much more feasible. And hence more likely to be shipped with 1.0. As everybody else on this forum I am vested in this language, and I would very much love to see it succeed. The 1.0 release will be very important to generate momentum that could keep the language alive.
2 Likes
Interesting discussion. Plotting is something I, as a semi competent user in Julia, I have never been entirely comfortable with. I always find myself getting confused and going back to PyPlot but it makes me feel bad … And it is brutal to teach new users to do things like plt[:hist] and talk about calling out to Python … but man getting plotting libraries going has to be one of the most challenging things in scientific computing. That people do this at all as volunteers is really impressive to me.
One thing I wonder is the idea that plotting libraries really follow the kind of fashion changes of OpenSource at large. For python matplotlib is extremely dominant, I know there are other packages that solve pet issues, but really matplotlib seems to be the 1000 lb gorilla in that space and has been almost from the very start of the SciPy project. Not a lot of open source churn. Similarly in R, base/ggplot2 have been the only game in town (and they can use the same low level API of grid as far as I know so technically you can mix and match if you are an advanced user). That ggplot2 has taken hold I think is more a testament to Hadley than to OpenSource fashion changes, and that Grid was such a robust model for low level graphics primitives that basically one person could make such a feature complete system as an initial output.
So guess I wonder how much churn really happens in the plotting space in open source science stacks? For my experience working a lot in both python and R previously, Julia is unique in how many plotting api’s people use regularly as opposed to just having one or two main libraries and then a lot of pet projects that never take off. It sounds like recipes etc. are an attempt to maybe have it both ways, but as an end user I have often gotten frightened of the Plot.jl way of doing things for all this software engineering style indirection right at the user level. People talk about recipes … I look at them, I don’t really get them. Beyond that I have to know details about each of the many backends, choose one, figure out if the top level API gives me the control I need to get something ready for publication, etc. Call the one I use specifically… and so on. It just seems like far more work to make all these choices and see what features are covered than to just use one of the lower levels. I get that for a developer this is pain itself, given that none of these backends is a standard, but as a user having a second layer of APIs that don’t cover every detail I need to finish a plot for publication, just means I need to learn at least two different APIs and understand how the system works at a low level to tweak them. I absolute understand how this solves a real problem, but I think this way of doing things is tough even beyond new users. It feels complex without giving me a real sense of benefit as an end user. I find it hard to teach and hard to keep in my own head, so I just jump ship and add to the original problems of many, soft competing, plotting APIs that are common in the Julia community.
I have no solutions as smarter people than me are involved in this discussion. I just wanted to add some thoughts on how this situation feels from someone that is not a beginner, but not quite a superstar Julia user. As well as questioning if other spaces that I am familiar with have had the same history of plotting API proliferation.
10 Likes
I think we all agree that plotting shouldn’t be a hassle. What I don’t understand is how is
using Plots
plot(...)
any hassle (as some here suggest)?
Yes, currently there is a problem with the time-to-first-plot with Plots and some bugs in the default backend but these issues are being worked on. And the bugs in GR (or any other default plotting package candidate) are the same regardless of whether it is used as a back-end to Plots or not.
And if the main backend works fine, then the above plot() is all that’s needed to get going with Plots and the end-user really does not need to know about any of the complexities of the package.
As for the recipies, they might indeed have a little unusual syntax but not more so than let’s say ggplot2 compared to R base plotting. The point being that every solution has its peculiarities and I don’t think this one is especially confusing.
5 Likes
Also, they are for package authors. That doesn’t excuse all of the problems, but it’s a different target audience. Recipes should be feature-filled with dense documentation. The standard plotting API should be a simple entrance.
2 Likes
I use Gadfly and love it, for most of the work I do.
However, I often have need for animating changes over time, or presenting 3-dimensional data. There are some ways of doing 3-D with Gadfly, but they are limited. I usually end up using ThreeJS.jl for that, which is a lot of work.
We live in a world with easily accessible 3D VR glasses, both 3-D and animation should be easy, and easy to output in a format that works with those types of glasses. I’m not talking about a 3-D pie chart, either.
I suggested focusing on GR as the default plotting package because of the, well, focusing. Right now it seems to me that many people are working on plotting, but the effort is fragmented. Many examples of projects are listed in this thread. Some of these work for one application, but not for another. Some may work for some people some of the time.
As you say, if Plots.jl did not have that prohibitive start up time and if the back ends actually worked, this would be a good solution. But the complexity of the task may prevent this from happening anytime soon.
I wonder what people actually working on Plots.jl actually think about having this package ready for 1.0?
There are several issues that make this difficult, and one issue in particular that is causing more churn for Julia than you see for e.g. Python:
-
Plotting is enormously complicated. Anyone can throw together a package that does a simple scatterplot, but for production-quality graphics there are a staggering number of variations that need to be supported.
-
Cross-platform GUIs are extremely complicated; to this day, there is no “standard” solution that satisfies most people. (Look at the huge number of Matplotlib backends.)
-
Because some very full-featured open-source solutions exist, it is hard for new competitors to get off the ground — it is insanely hard to get to feature-parity with e.g. Matplotlib, and until you get close to that point your library is not viewed as a serious option.
The third point is critical here: when Matplotlib and ggplot2 were created, the competition for open-source plotting was not nearly as stiff — the main free/open-source choices for 2d plotting were gnuplot and Grace, but both of those had huge drawbacks for use by a dynamic language like Python or R, and both were written in low-level languages where adding features was much harder. So I think it was easier for Matplotlib and ggplot2 to get started, because people were willing to put up with many fewer features to get a “native” library. (Their developers did amazing work, regardless.)
In contrast, GNU Octave went through years and years of trying to develop a replacement for gnuplot. I used to participate more in the Octave community, and there were several times when a “native” replacement plotting package was created, got to the point of a few plot types and some cool demos, and then collapsed. The trouble was, until they got close to feature parity with gnuplot, they attracted interest but not real users and developers, so they died once the initial developer moved on to other projects (all volunteer effort, remember).
Julia is able to benefit from some extremely mature and full-featured plotting packages developed for other languages, especially Matplotlib and PlotlyJS. This is great, because it would be hard to use Julia for serious work without production-quality plotting. But it also makes it harder to develop a “native” alternative like GR.jl — it requires a labor of love (years of it) to get to the level of maturity where it attracts a lot of other developers. (In contrast, the “native” plotting package Winston.jl had a lot more contributors than GR.jl … but then it pretty much died out when full-featured cross-language plotting libraries became available.) And we also get a lot of churn, because no one is completely happy with “non-native” solutions involving inter-language calls and nontrivial dependencies.
16 Likes