[Feauture] Confidence interval bands + errorbars

[icweaver]

Howdy, GLM.jl has this in the works. After some discussion on slack, it sounded like this would be a good thing to fold into AoG if it's ever merged. Will keep this as a draft for now. It's now in!

Depends on JuliaStats/GLM.jl#631

If weights are passed, uses GLM.glm instead of GLM.lm to provide confidence interval support. JuliaStats/GLM.jl#495

Below are some brief usage examples:

julia> using AlgebraOfGraphics, CairoMakie

julia> colors = Makie.wong_colors()

julia> using Random

julia> Random.seed!(111)

julia> df = let
           x = 1:5
           y_err = randn(length(x))
           y = x .+ y_err
           y_unc = abs.(y_err)
           (; x, y, y_unc)
       end

julia> data(df) * mapping(:x, :y) * (
           (visual(Scatter) + mapping(:y_unc) * visual(Errorbars)) * visual(; label = "data") +
           mapping(; weights = :y_unc) * linear() * visual(; color = colors[1], label = "model")
       ) |> draw

Before

After

This uses fweights by default to match current behavior, but different weights can be passed via the new weighttype keyword, along with a new weighttransform keyword to perform any desired transformations before passing to the GLM machinery (assuming on the GLM v2 branch):

julia> specs = data(df) * mapping(:x, :y) * (
           (visual(Scatter) + mapping(:y_unc) * visual(Errorbars)) * visual(; label = "data") +
           mapping(; weights = :y_unc) * (
               linear(; weighttype = :aweights, weighttransform = x -> inv.(x .^ 2)) * visual(; color = colors[1], label = "aweights") +
               linear(; weighttype = :fweights) * visual(; color = colors[2], label = "fweights") +
               linear(; weighttype = :pweights) * visual(; color = colors[3], label = "pweights")
           )
       ) |> draw

If on an older version, this will throw an error if anything besides fweights is passed to respect the deprecation notice in GLM v1.9.1

Still playing around with the design. Happy to make any changes if this is useful

Related

• Confidence Interval Band #366

Todo

• GLM v1/v2 compat layer?
  • wts --> weights once Rename wts to weights and allow passing variable name to it JuliaStats/GLM.jl#631 is in
  • open weighttype to aweights and pweights
• tests
• docs

[icweaver]

Whoo, JuliaStats/GLM.jl#487 is in now! I've updated the PR here to match current functionality. Once the design looks ok to y'all, could I have some help with adding any additional docs + desired tests?

[icweaver]

Ok, I think things should be ready now for a first review

[nalimilan]

Is weighttype really needed? The whole idea behind these AbstractWeights types in StatsBase is that you only specify once the kind of weights you have when building the vector, and then all functions automatically interpret it correctly. We don't have any API currently that takes the kind of weight separately.

[icweaver]

Thanks for taking a look, Milan! I hear ya, and I as on the fence on if it would be better to have the user explicitly construct the weight vector themselves before passing it to AoG, or to just have AoG handle it internally. I decided to go with the latter for ease of use.

Currently, this just wraps the specified field from the table-like data passed to AoG in fweights (or to potentially more supported weight kinds after GLM v2 is released). In either case, the weights are still only specified once, no?

Maybe calling it weighttype is misleading since it's really just wrapping our array in a convenience function call. I think I called it weightkind in an earlier iteration, and could switch back to that if this design makes sense? Sorry if I am misunderstanding what you are asking.

[nalimilan]

My point is that imagine I'm loading a dataset in df. I immediately do something like df.y_unc = aweights(df.y_unc). Then I can create one or more graphs, estimate models, etc., without ever saying again that these are aweights, and everything works automatically. And this is necessary to use weights with StatsBase or GLM as they require an AbstractWeights type. Introducing a new keyword argument which differs from the method used in other packages actually makes things more complex IMO.

As @jkrumbiegel said (https://github.com/MakieOrg/AlgebraOfGraphics.jl/pull/710/changes#r2685551356) it seems better to adopt the API of underlying packages as much as possible.
without introducing new API in AoG.

[icweaver]

Right, so your strategy is totally what I would do if I was using vanilla Makie.

In contrast, it's my understanding that the current usage with AoG makes all calls to StatsBase and GLM internally so that the user only needs to pass the raw data without any pre-processing or explicit loading of additional packages needed. It seems this would need to change with your proposed usage, so I guess my question is if this is the direction that we would like to go in this PR.

At any rate, happy to go with either route, was just asking for clarity

[nalimilan]

If you allow passing distr, it would make sense to allow passing link too. Most distributions other than Normal require a link other than identity.

[icweaver]

Oh cool, didn't know about link, thanks! I'm wondering now if it might make more sense to start storing these GLM.glm-specific kwargs in their own struct that's then passed to AoG.linear instead of duplicating individual args in AoG.LinearAnalysis internally as I am currently doing. I guess it depends on how much additional API surface we want to introduce. Happy to go with either route depending on what Julius prefers

[jkrumbiegel]

I didn't closely examine this but in general, I like it better if options for a different package are pass-through (like kwargs...), so AoG doesn't really add API on its own. But if it's just really cumbersome to use that way, that's an argument for making special AoG API. After all, linear() is still supposed to be rather simple to use.

[nalimilan]

That makes sense. One point to note though is that distribution and link are positional arguments in GLM, so either they would have to be passed as positional arguments to linear, or they would need special-casing.