Plot recipes

[irregular-rhomboid]

This PR builds on the discussion in #581 and provides summary plots of LinearModels for both Plots and Makie. The plots are based on those from R's plot.lm function. While one new lightweight dependency is needed for RecipesBase, the plots are implemented as extensions for StatsPlots and Makie.

Implemented features

• Plots are implemented for the equivalent of R's Residual plot, Scale-Location plot, Q-Q plot, Residuals-Leverage plot and Cook's distance vs leverage plot. The interface for these functions is the same for both plotting packages.
• A summary plot function lmplot displaying the residual plot, Q-Q plot, scale-location plot and residuals-leverage plot. The configurability of this function is limited, however.
• The computation of the leverages has been factored out into a function in lm.jl.
• For the StatsPlots extension, default values for the axis labels and title are provided. This is not available for the Makie extension, except in lmplot.
• Basic docstrings are provided for all the new functions

Not implemented

• Documentation in docs/. This seems like a good thing to add.
• Tests (it is not clear how to test for both plotting packages at the same time)
• Loess smoothing. This is a feature in the R plots which would require another dependency to implement, for unclear benefits.
• Outlier labelling (see last image)

Examples

StatsPlots:

using GLM
using StatsPlots
using RDatasets

data = dataset("datasets", "trees")

l = lm(@formula(Height ~ Girth + Volume), data)

lmplot(l; size = (700,500))

Makie:

using GLM
using CairoMakie
using RDatasets

data = dataset("datasets", "trees")

l = lm(@formula(Height ~ Girth + Volume), data)

lmplot(l; size = (700,500))

R equivalent:

[codecov]

Codecov Report

Attention: Patch coverage is 95.33679% with 9 lines in your changes missing coverage. Please review.

Project coverage is 91.05%. Comparing base (89493a4) to head (ae37c1c).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
ext/StatsPlotsExt.jl	95.76%	5 Missing ⚠️
src/GLM.jl	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #582      +/-   ##
==========================================
+ Coverage   90.33%   91.05%   +0.72%     
==========================================
  Files           8       11       +3     
  Lines        1107     1297     +190     
==========================================
+ Hits         1000     1181     +181     
- Misses        107      116       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[csimal]

@ajinkya-k @andreasnoack It would be good to get some feedback about this PR. I finally got time to write some tests, but ultimately plot recipes are hard to test beyond "does not catastrophically crash", and I'm not sure that I can test both the StatsPlots and Makie Recipes since they override the same function.

One option would be to put the recipes into separate mini packages rather than extensions.

[andreasnoack]

Thanks for preparing this. It's really a great feature. Would it be possible to handle testing of both plotting frameworks by splitting the testing of them into separate CI jobs? Regarding the testing of the images then @jkrumbiegel might be able to share some ideas.

[irregular-rhomboid]

Would it be possible to handle testing of both plotting frameworks by splitting the testing of them into separate CI jobs?

Good idea. Ii'll look into it.

[ararslan]

IMO we should just raise the minimum Julia version rather than taking a dependency on Requires, especially since get_extension is 1.9 and 1.10 is the oldest supported release series.

[ararslan]

It seems vanishingly unlikely that someone would load both Makie and Plots in a single session. Rather than duplicating the function stubs for different plotting backends (of which there are more in the ecosystem than just the two implemented here), I think it would probably be fine to define the stubs just once in GLM, even though the methods in different extensions will conflict with one another. Or maybe that would cause other issues I can't think of offhand.

Plotting is a weird case where it feels like a great use case for package extension but in practice it seems hard to do well given how the package extension mechanism itself is designed. This is likely why there are packages like MixedModelsMakie that live separately from MixedModels and Makie. I kind of feel like would be a sensible approach for GLM as well.

[irregular-rhomboid]

I ended up making two small separate packages:

• https://github.com/irregular-rhomboid/GLMPlots.jl
• https://github.com/irregular-rhomboid/GLMMakie.jl

The Makie one is unfortunately close to GLMakie, which may not be desirable. I'm open to suggestions.

Currently, there is some code duplication for the standardizedresiduals and leverage functions. It's unclear whether they should be integrated into the main GLM codebase, since they would only be used by these two packages. If not, then this PR can simply be closed without merging.

For the same reason, I'm not sure defining function stubs in GLM is necessary at this point. Might as well just keep the plot packages as standalone, and maybe mention them in the GLM docs

To summarize the latest changes:

• Moved the Plots and Makie recipes to dedicated packages, instead of extensions.
• Bumped the Julia compat to 1.11

[andreasnoack]

Plotting is a weird case where it feels like a great use case for package extension but in practice it seems hard to do well given how the package extension mechanism itself is designed.

@ararslan I'd like to understand the argument here. What is the specific issue with using package extensions for this?

[ararslan]

What is the specific issue with using package extensions for this?

I wouldn't say it's an issue per se, perhaps more of an inconvenience? Package extensions are designed around the idea defining a method of a function in package A for a type in package B without A or B depending on one another directly. As a consequence of this design, package extensions can't have their own exports. The inconvenience for plotting is that plotting packages generally have separate functions for different kinds of plots rather than methods of some parent function, which means you have to maintain stub definitions for the plotting functions in one of the packages (e.g. as implemented in this PR), but there are multiple plotting packages with different, incompatible interfaces but often identically named functions, which then requires duplication of stub definitions (e.g. as implemented in this PR) if you want to avoid overwriting methods if multiple plotting packages get loaded.

It's also worth noting that other modeling packages could conceivably want to define methods of these functions for the model types they define, but if GLM owns the stubs, the extension for the other package has to be defined such that it's loaded for when the modeling package, GLM, and a plotting package are all loaded. It would also need to duplicate it by plotting backend.

It almost feels like it makes more sense for the plotting packages to own the function stubs, but I'm not sure the maintainers of those packages would necessarily agree, haha.