Julia alternatives to Matplotlib?

New to Julia
, ,
43

No, that is a user facing thing. Besides the poor suckers wrapping the backend binary libraries and working to ensure installation is seamless, no user is effected.

I would love a pure Julia Blas library if it was as fast and convenient as the alternatives… And maybe it will be! Until them openblas/mkl are perfectly fine for me.

Your goals here are somewhat contradictory. If you want the simple, safe, approach to plotting there is one set of choices. If your objective is to focus on examining what is the minimal amount of non Julia code possible in a plotting solution, that is clear but will take you down a different path.

2 Likes
44

On top of the two language problem, there is also the “one language mentality”, or “one language psyche”, i.e. there is a desire to use one language, and to be “true” to that language. And now we are in the realms of Psycology.

2 Likes
45

This is a very deep rabbit-hole. You might get away from those, for plotting library or otherwise, but at some point you’re going to call the operating system, in a sense a C “library” (and a/the C library, libc, Julia only supports one or two, depending on platform, all written in C; e.g. Zig language can avoid libc, or or use with, but not a lot of languages can avoid a libc library or the OS). I’m just, like others, pointing out: avoiding other languages shouldn’t be a goal, easy installation of libraries written in those should be. There are currently two Julia gnuplot library wrappers, and both can be very fast for first-plot, but the downside is (currently) the user needs to install gnuplot itself. Such could be avoided with Julia’s artifact system, if not already done for either wrapper. Pure Julia code currently has more startup cost, by default, can also be avoided, I’m just pointing out a reason o NOT use Julia libraries, the other they often already exist, feature complete, so why reinvent the wheel?

“plus assembly” if you you want to be strict.

2 Likes
46

I am not sure about this. Putting the question of how much plotting is appropriate in a book about math aside, I would be (and am) very impressed with the options for plotting in Julia. A lot of work has gone into Vega, Matplotlib, Gnuplot, Plotly, etc and by learning Julia you get the full power of those “for free” + Julia specific packages such as Gadfly, Plots, Makie, SimplePlots for Jupyter notebooks (+friends such as StatsMakie). Personally I also think calling other languages for plotting is not a particular problem as the resulting plot is usually an “endpoint” as in I do not further process the plot (at least within the program) after it is created and the output is universally some kind of graphics format (e.g. svg, png).

1 Like
47

This is highly individual, though. For me, plotting is only ‘stage 1’. After that, I need to pan, zoom, tweak clims and colormaps, then browse and manipulate the data with the mouse cursor. Moving the cursor over the data triggers source data loading. Drawing shapes on top of the plot that can be dragged around, to trigger live updates of multiple other plots that are linked together in various ways.

Etc. etc. In this regard (one of few) I have been very pleased with Matlab’s capabilities (especially after I became familiar with listeners), but have yet to figure out Julia’s. I suspect that Makie has much of this.

3 Likes
48

I’ll concede that I’m being too harsh towards binary-only libraries written in other languages. I should instead be happy that Julia makes using them much easier than do other programming languages. In an ideal software world, any language could seamlessly use libraries from any other language. We don’t yet live in such a fantasy world, but at least Julia is trying to reduce those barriers.

Nevertheless, I’m still not keen on the idea of having to install Python to use a Julia library, especially if the core of that library is written in C or C++ which Julia might just use directly. I could ignore this mild annoyance, however, if the library performs well and I need not write any Python to use it.

I suppose installing gnuplot shouldn’t bother me much, either, given that it’s open source and available for many operating systems. Unless it’s a better wheel, I agree that there’s not much point in reinventing the wheel.

5 Likes
49

I think the book is more about math than Python, though the publisher may have thought that using Python and related tools like Matplotlib would be a good selling point. Doing Math with FORTRAN or Doing Math with COBOL might not sell very well today.

I’ll try to ignore that PyPlot.jl uses Python and Matplotlib and just use it.

50

PlotlyJS is a decent plotting library. It does use JavaScript. But, perhaps that would be better than Python?

52

Then don’t. There is only a single plotting package that does this, and it isn’t even the most widely used. Except for some quirky but useful alternaties (e.g. the PGFPlotsX which is very nice for publication quality ones with latex) you never need to install anything manually or worry about when code eventually hits soemthing compiled in C… because it eventually has to.

2 Likes
53

Completely. I guess the plots I do are mostly quite simple but maybe I don’t know enough about plotting. I really have not done anything interactive

54

For the purist, Plots (or SimplePlots) + UnicodePlots will likely not require any underlying plotting library.

2 Likes
55

In my humble opinion, I use PlotlyJS when I want the really useful feature of interactivity and coordinates seeker. Also, it shows the graphic in SVG (Vector). The main disadvantage is oudated and really hard to save figures in SVG or PDF.

For that reason I only use Plots.jl, it’s very nice but it has three things that I dislike a lot:

  1. No SVG output, I really hate the graphic with blurry PNG in Juno (Atom)
  2. No interactivity and coordinates seeker, like PlotlyJS
  3. First Run is really slow
1 Like
56

I’m so surprised 23 posts in we finally mentioned it…

57

it does have SVG output right?..and the second point can be overcomed by calling plotly() before plotting right? Backends · Plots

58

A plotting library is one of those things that is really difficult for a research community to support because

a) it doesn’t really change research
b) limited types are necessary at the very bottom (your eye can’t see the difference between Float64 and Float32 in terms of relative scale, so just convert)
c) The limited types means that even ancient C++ libraries do about the same thing and are already optimized.

For this reason, the Julia community has worked on new interfaces specifically for solving (b): how do you automatically convert types to plottable types? This is the innovation of the recursive recipe system of Plots.jl (Recipes · Plots). However, in terms of plotting itself, even Plots.jl just calls into established backends.

One spot where there is innovation to be had is in GPU acceleration. Not too many people are plotting things with the billions of data points with interactivity that is required to make this useful, but it is something that is starting to come up more and Makie.jl is a library for handling that, which is pure Julia (GitHub - JuliaPlots/Makie.jl: High level plotting on the GPU.). It is quite far along.

For more of a traditional plotting library in pure Julia form, there’s https://github.com/GiovineItalia/Gadfly.jl , but it’s limited to 2D so it works well for data science workflows but not general technical computing. This is somewhat because the development efforts grow fast with 3D of course.

A plurality of the community uses Plots.jl, then there’s sizable communities around PyPlot.jl, Gadfly.jl, Makie.jl, and VegaLite.jl. Then there’s a long tail of Winston.jl, Plotly.jl, InspectDR.jl, PlotlyJS.jl, UnicodePlots.jl, etc. Plots.jl lets you swap backends to use many of these, so you can just learn plots and get the different displays and call it a day, which is what a lot of people do. In the end, there’s a pretty bustling plotting community with anything a researcher needs, but without a focus on purity, and quite frankly I think that’s okay.

22 Likes
59

No bro, at least with the default backend (GR) of Plots.jl, there’s no SVG output :frowning:

And well, there’s the problem. We have to change between many backend to make certain things. As @ ChrisRackauckas mentioned above, the plotting libraries don’t really change research. It’s only how (beautiful or ugly) to show a graphic

60

This is not what the documentation says, and I’m pretty sure that GR lets you savefig in svg format.

2 Likes
61

Depends how narrowly you define ‘research’. For me, plot interactivity is an integral and essential part of how we do our work. The beauty of the final plot is secondary (but appreciated).

1 Like
62

I like to suggest to turn the cat off its head on its feet* and ask: which packages make good use of the features Julia provides and do not just transplant or mimic a plotting package written in some different context.

And I suggest Makie then. It uses https://github.com/JuliaGizmos/Observables.jl to trace change in the data used to build a plot in a very Julian way down to the GPU to redraw the specific parts of the plot affected. This gives you interactivity and animations at GPU speeds.

*Rotation of cats is somewhat a theme of the Makie example gallery GitHub - JuliaPlots/Makie.jl: High level plotting on the GPU.

4 Likes
63

What’s interesting to me is that the established plotting libraries sometimes have quite large “holes” in functionality. I spent a lot of time to create the layouting backend MakieLayout for Makie.jl and of course there is always the question, isn’t my time better spent using the established packages? But in my opinion matlab, matplotlib, ggplot, gadfly, etc. all work quite well for the single subplot / subplot grid use case but make it hard to do something like arbitrarily spaced colorbars across differently sized subplots, with subtitles or legends in between, any kind of the more creative layouting you quickly need if you do anything out of the ordinary. For my own research purposes these needs come up quite often and stackoverflow is full of others asking for hacks and workarounds to do this in the above mentioned packages. I’m already quite happy to see how many others share my sentiments and enjoy using the library I made. My worry is just that Julia will never get rid of the large compilation lag for our complex plotting pipeline and people will be annoyed out of using what we can offer them.

14 Likes