Plots.jl recipes

[cailmdaley]

Would be nice to add plot recipes for FlatField, FieldTuple, InterpolatedCℓs, etc. Currently I have these two recipes kicking around:

@recipe function f(m::FlatMap)
        seriestype   :=  :heatmap
        seriescolor  --> :vik
        aspect_ratio --> :equal
        axis --> false
        grid --> false
        size --> (500, 450)
        clims --> (-maximum(abs.(m)), maximum(abs.(m)))
        m[:Ix]
end

@recipe function f(Cℓ::InterpolatedCℓs, ℓrange::AbstractVector = 1:5000)
        xguide --> L"\ell"
        ℓrange, Cℓ.(ℓrange)
end

Happy to add this in myself, but wanted to discuss a little bit first. Do we want the plot recipes to exactly replicate the PyPlot functionality in plotting.jl? Because of Plots.jl's frontend/backend approach, this might be pretty hard / impossible. I get the sense that PyPlot.jl is more customizable and verbose, so maybe it makes sense for the Plots.jl recipes to provide "quick and dirty" plotting functionality, while the current PyPlot.jl functions you've written could be more "production quality"?

[marius311]

Do we want the plot recipes to exactly replicate the PyPlot functionality in plotting.jl?

Which functionality specifically do you mean? Is theres something that just wont be possible with Plots? (I think this is fine btw and shouldnt stop us from putting something in there)

I will say I don't think it needs to replicate the existing functionality, or that one needs to be productions vs. quick&dirty. Rather, I see it as some people might like PyPlot.jl, others might like Plots.jl, and it'd be nice to have a hook into both, each which is consistent with the paradigm / code style of how the particular package.

[marius311]

Feel free to open a PR to start. I think we rename plotting.jl -> pyplot.jl and add a plots.jl, which would similarly be wrapped in a @requires.

[cailmdaley]

Ah sorry for leaving you hanging here, totally forgot about this.

Is theres something that just wont be possible with Plots?

I'm not exactly sure if anything will be outright impossible, but I definitely think some things will be harder. My anecdotal experience is that Plots.jl doesn't let you muck around with axis objects to the same extent as PyPlot, and there have been a few times where I've run into things (can't remember what exactly) that just aren't implemented in the Plots.jl frontend. In any case, I agree that that the PyPlot and Plots hooks should take advantages of the strengths of their respective packages.

As for @requires, we don't actually need to add Plots.jl as a dependency, so I'm not sure if this is necessary. Usually the way you add Plots.jl functionality to a package is via RecipesBase, which is a package with no dependencies that defines "recipes" for Plots.jl to use. Then it's up to the user to do using Plots; plot(...), totally separate from CMBLensing itself. But this is a minor point, and that naming scheme sounds reasonable.

I can take a stab at this sometime in the next few weeks!

[b-thorne]

I quite like Plots.jl, so I am revamping this thread. It seems to be a WIP, with some documented features being backend-specific, and some not being implemented at all. However, I quite like the @recipes functionality, and prefer some of the backends to PyPlot.jl, personally.

I have started a PR (#42) for this, with a first attempt at a flat field recipe.