Where is actual development in Plotting?

https://juliacomputing.com/products/juliapro.html

2 Likes

Thanks.

This depends on what you mean by “guaranteed”, but if you are looking for reliability/maturity like R or Matlab, you may have to wait a while. Notice that the latest released version is 0.6, which means that

Anything may change at any time. The public API should not be considered stable.

This is about the core language, the library ecosystem may of course take additional time to catch up once the language stabilizes.

Julia, especially the released branches, are perfect for productive daily work, but users occasionally need to get their hands dirty. It is very important to keep this in mind when teaching a course, and adjust expectations accordingly. Choose Julia when the benefits (speed, future value of investment, convenience) outweigh the costs (occasional bugs, library ecosystem moving forward rapidly, WIP or nonexistent libraries for certain tasks).

4 Likes

Very true. But note that my concern is more about the state of affairs at the time when 1.0 is released.

Hello everyone,

thanks for the lively discussion and to everyone who contributed. Initially i tried to get an overview of things/technology/SW that’s in flow (and might be interesting to contribute to) without visibility but i learned also a lot about community building and expectations on the plotting topic. I wasn’t aware e.g. about Simon’s https://github.com/SimonDanisch/MakiE.jl .

I’ll pick up some topics in dedicated other questions.

@tobias.knopp: I think one of the most promising efforts was/is Winston.jl. It is pure Julia and thus is fully hackable. Integration with Gtk.jl works nicely.
Unfortunately the development behind this stalled a little bit.

I am not certain if this satisfies your needs, but the InspectDR plotting backend is also “pure Julia”: The rendering is done through Cairo.jl, and the interactive GUI makes use of Gtk.jl.

Link: ANN: New interactive Plots.jl backend for large datasets

@stephancb: To me it seems that plotting can easily become highly complex. It would perhaps be worth (and a big work) to design a hierarchically structured plot container that can be filled/modified via the usual plot(…) functions calls or from persistent storage and that can be displayed with the different backends […]

I might not have understood your concerns correctly, but: If you choose the HDF5 backend, you can:

  1. Build your plot in a backend-agnostic way using the usual plot(...) functions.

  2. Save said plot to an .hdf5 file.

    a) Stop working/close session/or whatever…
    b) Come back at a later time (or possibly never stop working).

  3. Choose whichever backend you wish to use when “replaying” said .hdf5 file.

  4. Replay .hdf5 file to currently selected Plots.jl backend.

  5. Add more detail to the plot using the usual plot(...) functions (if desired).

  6. Possibly do the same to a second/thrid/… backend.

The only real problem at this point (That I am aware of) is that the HDF5 backend is not of archival quality: Given that the HDF5 backend uses an object dump of the internal Plots.jl structures, it is very succeptible to backward compatibility issues whenever the internal Plots.jl structures change.

To make an archival-quality version of the HDF5 backend, we would probably need to develop a more rigid specification for the file structure… and probably have some form of versionning to lower the pain threshold wrt to adding features in the future.

@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.

  1. x-axis to the micro/nanosecond resolution
  2. ability to zoom in.
  3. 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.
  4. Multiple y-axis for the same x-axis.

FYI @hgeorgako:

The InspectDR backend for Plots.jl has the ability to do 1, 2, and 4.
Link: ANN: New interactive Plots.jl backend for large datasets

Having a common x-axis is really useful to do interactive exploration of Bode plots (for example).

Sadly, Plots.jl does not support having multiple y-axes for the same x-axis… To use this feature, you would have to use InspectDR.jl directly.

Yes it does: plot(randn(10)); plot(twinx(), randn(10)).

2 Likes

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?

1 Like

@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.

5 Likes

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.

1 Like

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.