I am writing up some notes for some students (several who have never done computer programming before) to do basic plotting. The issue is that the documentation for PyPlot is targeted at people who are able to read the matplotlib documentation and is focused on helping people to translate matpoltlib.pyplot calls into Julila. New users are not going to be able to do that (though it is perfect for them later).
My thinking was that these things are best taught by example, if the main concern is to help people get started on basic plots (i.e. for problem sets, not for publication). The best source I have found is: https://gist.github.com/gizmaa/7214002
Is this mostly up to date and accurate? Are there any other sources worth giving to users to help them learn plotting basics?
Because it takes 30 to 40 seconds after opening ANY jupyter notebook to get the first plot (after precompiling everything possible) . That time is perfectly fine when trying to generate a production quality graph while doing a big computational project, but it is unbearable and unnecessary when learning Julia and flipping through various notebooks, or doing quick and dirty data exploration. I am trying to get grad students who know matlab, and undergraduates who may know nothing, to use Julia and I am pretty sure that this will be the one thing that turns them off.
For now, if I can tell them to use PlotlyJS and PyPlot directly when doing exploratory work, it cuts things down to 8ish seconds. They can use Plots.jl or whatever WAY down the road when they need to generate papers and slides (ie never for many of the students)
More generally, when you guys are thinking through the marketing and training collateral for the v1 release, I think that you should seriously consider suggesting a separate library for now between interactive/exploratory plotting (which you use in tutorials) and print quality.
Spencer’s PlotlyJS.jl is already good with enough examples to get started , and with a little extra effort from you guys it could probably get the load time to 4 or 5 seconds in jupyter/atom. With a few extra docs, it could easily become the “quick and dirty” but “pretty on the web/electron” solution to get over the plotting chaos hump.
In fact, I don’t see why an interactive jupyter/electron based solution needs to be the same as the print quality one, even in the long term. They have very different needs.
Regardless, this may not be the perfect longterm solution, but buys you a year to figure out the Plots.jl precompiling and eval issues…or let a competitor provide a different approach.
True, but I am questioning that approach, and taking it further: are we sure that the frontend choice has sufficient commonality between the interactive/exploratory/jupyter use cases and the print-ready use cases? It is great to be able to swap out backends, but if the frontend features of either Plot.jl or Makie.jl need to to be design the the lowest common denominator of print vs. exploration, then nobody wins. But I haven’t spent enough time thinking about this, so consider this a diffuse prior.
@ChrisRackauckas What are your thoughts on encouraging people to use PlotlyJS.jl? It might not take much for it to become the temporary best practice for exploratory work, and as an interactive/web first starting point. It also fits exactly into what Plotly.js is for?
Honestly, I don’t know. I like the “do it right the first time” philosophy, but since Plots.jl is changing to Makie.jl anyways, it’s hard to teach for what the eventual target looks to be.
I am not sure, because I haven’t seen the sort of libraries people could design for jupyter/juno display if they were unshackled from having to provide a common interface for print-focused plots. I imagine pretty cool stuff with Reactive.jl, Interactive.jl, etc. I have the seen some pretty cool interactive web graphics over the last few years…
Moreover, are we sure that even if the dependent library issue requiring the use of eval for backends that it will be fast to use? There is a LOT of code to compile for a general front-end to backend interface, and I am not convinced it could all be precompiled.
But my main concern is less suggesting the longterm solution, and more trying to figure out a short-term (ie until October or so) to prevent my grad students and coauthors from revolting.
Since the target isn’t even clear, and we want to get people using Julia before then, we need a solution. What I was planning to tell people was:
use PlotlyJS.jl as your first place to explore the results, and it may be good enough for a while
directly use PyPlot.jl for building higher quality output for slides, papers, etc as required. I typically find that you write those sorts well after the initial exploration of the results.
finally, consider Plots.jl as a simple interface for producing plots or reading existing examples (with the understanding it is very slow to use right now, and will change in the medium term).
Makie.jl is built on top of GLVisualize.jl which has all sorts of interactivity (look at the tweets and gifs). I believe the idea is to have all of this, and then disable it for libraries which can’t handle it, not the other way around.
Doesn’t matter if you’re not convinced, it’s already been done .
It compiles into binaries and the system image for instant startup. Some work on ease of use / ease of installation is in order, but there’s no questioning that it works.
Sure. I would suggest always trying to keep the number of libraries to a minimum, and PyPlot.jl is interactive if you use its GUI so that’s a nice thing to use. I use Plotly all the time though, but those are my two main Plots.jl backends.
The answer is that there’s no good answer right now. The hope is that any answer is temporary, so go with what you know.
Is that sort of thing possible in juliabox and jupyterhub hosted kernels in the medium. Most of my students are going to use Julia online and I am less concerned with the speed of simple plotting for those able to compile their own image.
Thanks for your thoughts. My fear is that “temporary” means at least a year before any Makie or Plots rewrite or whatever is fast enough for quick and dirty plots from a vanilla installation…which goes through the v1 release when matlab users start playing with tutorials.
Maybe some general efforts for better documentation and tweaks for the “tutorial” version of plotting is worth it during that process. PyPlot is almost entirely devoid of documentation for that use case, while PlotlyJS.jl is off to a good start.
I wonder whether, once Makie becomes stable, one could add the option to download a system image with Makie with JuliaPRO. I guess the occasional user who doesn’t want to wait for loading time wouldn’t want to rebuild the system image either.
Slightly OT, but for FWIW, I am using PGFPlotsX.jl for all my plots these days. Time to first plot: ~1s, each plot ~1s (it has to compile the LaTeX), outputs to TikZ which is what I want most of the time (plus svg, pdf, png, also for display), plots just looks very professional, pgfplots itself is very well documented and the net is full of examples for every possible plotting scenario on Earth. It made plots fun again.
. But yes, I’m banking on Makie.jl for this, but it’s not ready yet.
.