I completely agree with this, but I have a feeling that a lot of people won’t.
3 Likes
This seems to be an important point in favor of GR as the baseline.
On recipes: the first question should not about the philosophy of recipes, etc. but rather whether they are useful as a stopgap plotting solution. @ChrisRackauckas brings up an important point that these are a very nice addition for new users in the short-term. So even if recipes do not end up in the long-term solutions and if no new recipes are written, it could help out new users playing around with differential equations, etc.
More generally: I see a whole bunch of discussion of the philosophy of the design of plots, what Makie can do, etc. At the risk of being my grumpy self, this is exactly what I was hoping we would avoid by posting up this discourse comment. There are a million (all very useful) comments on the long-term solutions, where everyone brings up important points and many of the ideas simply need to be tested.
But this obsession with the long-term is clouding the thinking on the short-term: plotting is a complete and utter disaster for new users, and there may be low-hanging fruit to fix and buy a year until the longer term solutions are ready.
For example, if GR can get multiple plots to show up from the REPL, and if plotly backends can be made stable in jupyter, that takes us a long way to fulfilling the requirements I posted.
1 Like
In this case, PNG or SVG seems like the most obvious, then creating PDF or LaTeX elsewhere.
For your desired use cases and desired features. Plenty of people get along just fine, because they have a single environment and work as they need to with the functionality available.
The problem is plenty of people \neq new users. Everyone has their own setup, but you can’t replicate that with a class and reusable tutorial notes shared between people.
Sure, I understand the student piece. I’m just saying that if you start with your requirements, it may look like a disaster. To someone like myself in industry, not being able to run in any editor and juliabox and supporting LaTeX and directly printing to PDF and being able to download PNGs aren’t jointly a concern (and thus, short-term isn’t much of a consideration)
Absolutely. I think my comments apply to students and new people evaluating Julia in industry and/or academia.
But if you look at my requirements, I think that it is much closer than people realize.
1 Like
I think it might be a little much even to say that students need all of these things. When I was an undergraduate I didn’t have a lot of this stuff and it didn’t bother me at all. I think the real issue right now is that the existing plotting solutions for Julia are unbelievably slow due to code generation. That’s something that’s guaranteed to frustrate students and experienced users alike, though students are far more likely to dismiss Julia altogether as a result of this difficulty alone.
This comment notwithstanding, I do think your list is a pretty reasonable set of goals, even despite my deep dislike of Jupyter notebooks.
But recipes are a long term solution. @Tamas_Papp misses the composability of recipes. The idea of the recipe chain is what’s important. Basically, the recipe system is that the current set of types will have recipes called on them recursively until the final product is made. I created a recipe for high dimensional arrays and complex numbers in DimensionalPlotRecipes.jl. If DiffEq’s recipe is called with complex numbers, it will generate these arrays that then get caught by those DimensionalPlotRecipes reductions which then give out arrays to plot. You don’t get this just by writing new plotting commands: this is quite unique to Plots.jl. That kind of composability is what makes developing difficult plots easy, and Plots.jl already has it. This is what makes Plots.jl have so many “free” features that even the backends don’t have, which is why it’s a great short-term solution. It won’t have a fast first-time-to-plot, but just about any plot is easy to make with Plots.jl. Makie has big shoes to fill in terms of extendability, but until it gets there the short term solution is:
- Use whatever backend works on your system or has the features you need.
- Deal with the first plot times.
1 Like
All true. I was only saying that I don’t care about long-term solutions right now… just want to patch together a solution for the next 6-9 months and hope that as many other people as possible coordinate on the solution for tutorials and examples (so we can all share them).
@ExpandingMan From my experience with teaching and getting new users up and running the last month, I can say that complaints about speed haven’t come up, because of the issues of stability, bugs, features, and incompatibility of code they find in tutorials running on their computers. This was a surprise to me since I though speed would be the big issue, but they aren’t even getting to that point.
Using Gaston.jl/Gnplot I get the following times for first plot:
julia> using Gaston
julia> @time histogram(randn(100000))
2.728446 seconds (1.26 M allocations: 66.601 MiB, 6.16% gc time)
1
I don’t recall installation being overly confusing. Plots seem to be persistent. Not sure about Juliabox (don’t use it). Outputs to PDF,SVG,PNG,EMF. Does multiple plots in separate window or in Jupyter. Good tutorials. Good for quick plotting but arguably isn’t publication quality.
1 Like
Tried Pkg.add("Gaston") and it did not install binaries for gnuplot, etc. So I think we would have to reject it as the intro plotting library according to the “new users” criteria I put up there. But nice to have fast options for people who are more advanced.
Installation of gnuplot is trivial. Gaston would be a great choice for you if it could plot into a notebook. (It can’t AFAIK.)
At the moment I am able to plot in a jupyter notebook.
See also
Excellent! Gaston then probably meets all the requirements …
Hello all, I’m Gaston’s maintainer. I’m happy to see it being used and mentioned here.
Regarding the original minimal requirements: I assume gnuplot is installed already (which is really easy to do); I have never tried it on juliabox; print preview works on Jupyter, but I don’t know how to print after that; I have never tried it on Juno. All others seem to be there.
Nice to have requirements: I don’t know how hard it’d be to migrate existing tutorials, but I’d imagine it wouldn’t be difficult; I don’t use VS code; I don’t use Juno.
One of the driving principles behind Gaston is code simplicity, and emphasis on quick, exploratory plotting rather than on aesthetics, publication-quality plots, luxuries such as subplots, or handling of huge data sets. The reasons are that I don’t need these features, and that I have very limited time to work on it. I like it that Gaston has no dependencies beyond Base, and I want to keep it that way.
Having said that, I welcome contributions (PRs, bug reports, feature requests), and I want Gaston to be useful to many people, even if sometimes it takes me a while to get things implemented or fixed.
3 Likes
Sounds great and a perfect thing to point users towards after they get started.
What I would say, though, is that for intro users the binary gnuplot would have to be installed for the package for it to be viable as the tutorial plotting baseline. Imagine a windows user (or an osx user who has never used the terminal), and who may not have programmed before.
I could say that if they managed to install julia, they should manage to install gnuplot too 
If somebody submits a pull request implementing this, I’ll accept it. See the issue pointed out by @sdmcallister above.
3 Likes