@StefanKarpinski: What are you missing that cannot be accomplished, e.g. by Plots + GR backend?
I know that for design work, I have a need for more interactivity. At this point in time, GR does not provide much interactivity.
Some of the things I am currently missing from the Plots+GR backend were pointed out by @hgeorgako:
Would be nice if the new framework supported plotting of time-series data in a seamless manner.
x-axis to the micro/nanosecond resolution
ability to zoom in.
If you are plotting data for 10 days, say between 08:40:00 to 12:45:00, have the ability to ignore the daily/overnight gaps and stitch the time-series together.
I agree with this. New users want not to have to worry about what’s what in the plotting ecosystem.
I know a lot has been said about this already, but the loading times really are an issue for plotting. The default plotting package I think should be a native library with a very thin Julia API on top and should load together with the Julia shell (or that should be at least the default in the mainstream downloadable).
I have not heard many people say this, but in my opinion the Matlab plotting features are by far the golden standard. Nothing in the open source world comes close to its ease of use, persistency capabilities, interactivity, export formats, performance, aesthetics,… As I understand it, one of the initial ambitions of Julia was to compete with Matlab. I would love to see this succeed in the plotting arena.
On a related issue: did anyone consider a Matlab backend to Plots?
@mkborregaard: Yes it does: plot(randn(10)); plot(twinx(), randn(10)).
Excellent!.. but as far as I can tell, Plots.jl does not have a way to inform backend of the user’s desire to lock the x-axes together.
In other words: There is nothing (yet) to signal a backend’s interactive GUI to keep x-axes in sync when the user zooms in (ex: with mouse box-zoom mechanism).
…Worthy of further discussion on the Plots.jl forum, I suppose. Thanks.
@krcools […] On a related issue: did anyone consider a Matlab backend to Plots?
Very good point!
I personally have not found Matlab’s plotting tool to be that great for my particular needs (ie: interactivity, speed, …) - at least not the versions I have been using. However I am certain that others share your opinion, @krcools.
Nonetheless, I would personally appreciate it if someone provided that wrapper module - if ever I were in need of Matlab’s “superior” plotting capabilities (in certain respects). I would like it even more if that person integrated this module as a Plots.jl backend as well. That would make it easy for me to make use of Matlab plotting without having to re-learn a new API.
… I simply am not the right candidate for this at the moment: I don’t really have a use for the Matlab plotting tool right now. However: Please feel free to build this module, both for yourself and others! It will surely attract an untapped group developers/users that were just waiting for a more familiar plotting experience!
Hello, I’m a bit late in joining the conversation. I just wanted to add a quick comment:
In my view that tone is unconstructive.
@mkborregaard Saying that Julia plotting is in a dismal state is not a personal attack toward you or anybody else. It doesn’t mean that you have not done a good job, or that your work is not appreciated. That said, the state of plotting in Julia is indeed dismal, and we should be honest about that. Nobody is being criticized here. Writing a mature plotting package is very difficult. What is really unconstructive is to criticize people who honestly say that the current state is pretty bad. I worry that that kind of attitude would actually impede progress.
I think what I was after was some more specific description of how it is bad, with actionable focus points. I still don’t think merely stating “this is bad” is going to lead to much progress.
How, e.g., is it worse than Python, given that we have PyPlot.jl?
@stevengj I’m responding more than a month late, but I think that this comment is very insightful. It’s hard to stop using PyPlot / Matplotlib when it is so much more mature than anything a few humans can write in a couple of years. The Python layer creates problems: I get a page of errors if I mistype the directory name in “savefig”. But Matplotlib’s documentation is second to none and I’m not certain that other packages will allow me to do relatively simple but important things like changing the aspect ratio and the typeface.
As more of a lurker in this thread, I do think that “dismal” is a pretty negative tone, and really seems overblown. Plots.jl can be slow to start up, but is pretty feature full (I am slowly but surely moving over to it). But given how easy it is to use PyPlot and R calling the experience “dismal” or “bad” seems like hyperbole, and I am sure has a real effect (I know it would bum me out) on the moral of people working in this important, but hardly glamorous area of the ecosystem. I guess my feeling is that we should all try to act with extreme care when talking about open source workers and their products. I personally feel they should be pampered and highly respected, as it is all to easy to act like we are clients and they are corporate software providers which simply isn’t true in most cases. Keeping the tone congratulatory and avoiding needless flowery language that can seem overly critical, in my mind, is a small price to pay to have the mind share we would lose otherwise. Just my 2 cents.
I think PyPlot is great. I don’t use R, but I’m sure it’s great too. The main issues I have with PyPlot is very opaque error messages, and other bugs that arise due to the Python layer. I also struggle when trying to follow the lower-level recipes, like if I need to add a second y-axis.
I guess I was mentally excluding PyPlot and R. I was thinking of native packages. If the only downside of Plots.jl is speed, then I agree with you. Perhaps my problem is that I’m too dumb to understand the documentation, but I have actually tried to move to Plots.jl and GR.jl and Winston.jl and I have always failed because I quickly run into a plot that I do not like but cannot figure out how to tweak. It might be that I need to change the aspect ratio, select a different typefact, or enter LaTeX into a label. If Plots.jl cannot do these things, I would call it dismal. But as I said above, maybe the only thing dismal here is my reading comprehension.
That sounds very reasonable. I have tried to stay away from suggesting that anyone has to do anything for me.
Ok. I use PyPlot all the time. Here’s a concrete example. Consider this error message:
What’s wrong here is that the directory “abc” does not exist. This only gets discovered deep inside the Matplotlib backend, and that leads to that big opaque error stack. Things like this happen from time to time because of the PyPlot → Python → Matplotlib layers. Some time ago @stevengj helped me out with an obscure problem where PyPlot would not plot at all. It turned out to be caused by Matplotlib not being able to find some files. The fix was easy, but I would never have discovered it on my own.
The second line literally says IOError(2, ‘No such file or directory’)… And the rest is just the Python stacktrace and then the standard Julia stacktrace which can be ignored. If you are trying to bring up a case where the error message is bad, that was not the best of examples.
No, this is the example that I want to use. I did not say that I could not read it. Note that I correctly summarized the issue in the next sentence. The question I was answering was “is it worse than Python?”. I think that this example is clearly worse than Python. Having the additional layer makes the stack traces longer and harder to read. Is the information contained somewhere in the stack trace? Usually, yes. Most of the time I can figure it out on my own. But I claim that this is worse than an equivalent problem with a native package.
The other, somewhat related issue, is that it can some times be difficult to go from the Matplotlib documentation to PyPlot commands. Can it be done? Yes, definitely. But some times I’ve struggled. For example, when trying to figure out how to add a second y axis.
To be clear: None of this is intended as criticism for PyPlot. I think that PyPlot is about as good as you can expect. There’s not really a lot you can do on the Julia side to avoid the opaque stack trace issue, for example.
You can just not show the julia stacktrace… If the main complaint about PyPlot is something trivially fixable that seems like the plotting situation is not so bad after all.
If the community wants to get behind PyPlot as the primary plotting package for Julia you will have my full support and I will offer my time to help convert documentation from Matplotlib to PyPlot. I thought that the community did not like the idea of using a Python backend. I personally don’t mind terribly, and I quite like PyPlot.
I think PyPlot is great, it’s the main plotting package I prefer at the moment, but as things develop there will probably be other packages that are going to be much better.
I use Julia language for research. When I try to use Plots.jl for plotting, I do not care what Backends it use. I just want to get the high-quality figure as Matplotlib in Python, which is used by most Python users as the default plot environment.
When I check the features that Plots.jl supports, It confused me. In order to get a journal-quality figure, I checked every backend. At last, I use PyPlot.jl, which is similar to Maplotlib.
Too many alternatives sometimes are not good news for the beginners or the engineers.
That’s not how it works. There is no single centralized decision. People write packages, some people use them, some contribute. Some libraries emerge as de facto standards, because they are good. If you want PyPlot to be one of them, you should not condition your contributions on some vague community decision; just start contributing now.
Ideally, I think that many in the Julia community would prefer a native plotting library. It’s just that they also realize that this is an enormous undertaking, so they are OK with other solutions in the meantime. All other solutions have issues, but they are different ones, and Plots.jl gives you a choice so you can work around them most of the time.
I don’t really understand, first you say the state of plotting is dismal, now you say you like PyPlot. I’m not arguing that everyone needs to use Plots, just use the package you like, like @Tamas_Papp says. Plots has lots of issues, but I personally enjoy it’s very julian approach to plotting. Note that it’s not a pure-julia solution, most of the backends require non-julia libraries.
BTW, in Plots you’d use tickfont and guidefont attributes to change the typeface, aspect_ratio to change the aspect ratio, and LaTeXStrings.jl to pass strings in LaTeX format.
Anyway, I think I’ve said enough on this thread - I only felt compelled to comment when you said I was blocking progress (still not sure how).
