equatiomatic turns fitted R models into LaTeX equations

The output is the model in symbolic form, not the estimates

The stated goal of equatiomatic is to reduce the pain associated with writing LaTeX code from a fitted model, and the package aims to support any model supported by broom. That dependency defines the reach: whatever broom can tidy, equatiomatic can try to render.

What you get back is the structure of the model expressed with Greek letters. Fitting a simple regression and passing the result to extract_eq() produces an equation of this shape:

library(equatiomatic)

# Fit a simple model
mod1 <- lm(mpg ~ cyl + disp, data = mtcars)

# Give the results to extract_eq
extract_eq(mod1)

The rendered result is the response on the left and a sum of beta terms with an epsilon, one term per predictor, with each predictor wrapped in an operatorname so that a multi-word variable name stays upright. The coefficients themselves are not substituted, and there is no error term in the output. That is the important thing to understand about the package: it describes the model you fitted, it does not report the numbers, and it is meant to sit alongside a results table or a coefficient plot rather than replace one.

The workflow this supports is the familiar one where a manuscript needs the model written out in words and symbols, and the author wants that equation to match the model object rather than a hand-typed approximation that can drift.

Categorical predictors become subscripts, in the order you wrote them

Two behaviours make the output usable in a real analysis rather than a toy example.

The first is categorical variables. The README says that when using categorical variables, the equation includes the levels of the variables as subscripts. A model with a species predictor renders each level as a subscript on the species term, so the equation distinguishes the reference level from the others instead of collapsing them.

The second is ordering. The README points out that the package preserves the order the variables are supplied in the formula, and it demonstrates this with a model whose predictors are deliberately not in a tidy sequence:

set.seed(8675309)
d <- data.frame(cat1  = rep(letters[1:3], 100),
                cat2  = rep(LETTERS[1:3], each = 100),
                cont1 = rnorm(300, 100, 1),
                cont2 = rnorm(300, 50, 5),
                out   = rnorm(300, 10, 0.5))
mod4 <- lm(out ~ cont1 + cat2 + cont2 + cat1, data = d)
extract_eq(mod4)

The rendered equation keeps the beta numbering in the formula's order, with cat2 before cont2 and cat1 last, even though the columns in the data frame are in a different order. For a manuscript where the equation and the surrounding prose have to agree on which term is which, that consistency is the feature that matters.

The model itself can be built any standard way. The README shows the shortcut form, a model with a dot on the right hand side, and the result enumerates every remaining column in the data set as its own term.

Wrapping puts the operator at the start or the end of the line

A long equation does not fit on one line in a two column paper, so the package offers a wrapping mode.

The parameter is terms_per_line, which defaults to 4, and it decides how many terms appear on the right hand side before the line breaks. The switch that turns it on is wrap:

extract_eq(mod2, wrap = TRUE)

With wrapping on, the output becomes an aligned environment where continuation lines are indented and each broken line ends with the trailing operator, which is the default placement. The number of terms per line is then adjustable:

extract_eq(mod2, wrap = TRUE, terms_per_line = 6)

The trailing operator is a style choice rather than a fixed rule, and the package exposes it as such. The README explains that when wrapping you can change whether lines end with trailing math operators like +, which is the default, or whether they should begin with them, using operator_location = "end" or operator_location = "start".

Two things are worth noting for anyone integrating this into a document pipeline. The aligned environment with an ampersand at the start of the continuation lines requires an amsmath package in the target LaTeX document, and the trailing backslash on a broken line is part of the generated output rather than something you add by hand. If your LaTeX template does not load amsmath, the wrapped output will not compile even though the code ran.

Installation is CRAN, with a GitHub path for the development version

There are two ways in, and the README keeps them short.

From CRAN:

install.packages("equatiomatic")

Or the development version from GitHub:

remotes::install_github("datalorax/equatiomatic")

The remotes route pulls the development branch rather than a released version, so it is the one to use when you need a fix that has not reached CRAN yet, and the one to avoid when you need a reproducible environment.

The package is documented on its own site, hosted at the equatiomatic GitHub Pages URL, where the introduction article includes the section listing other models and currently supported ones. That page is the reference to check for a specific model class before you try it, because the README points to it rather than enumerating the supported families.

The repository is a conventional R package layout. There is a DESCRIPTION file, NAMESPACE, R/ for the source, man/ for the documentation, tests/, vignettes/, a data-raw/ directory alongside a data/ directory, inst/, tools/, a pkgdown/ directory and _pkgdown.yml for the site, a revdep/ directory for reverse dependency checks, TODO.md, NEWS.md and CODE_OF_CONDUCT.md. The README itself is generated from README.Rmd, which means the examples are executed rather than typed by hand, so the outputs shown in the documentation are the ones the current code produces.

Maintenance is on the R package release cycle, not the commit cycle

The two timelines here move at different speeds and it is worth separating them.

The published CRAN releases are v0.3.3 on 2024-05-28, a version 0.3 CRAN release on 2021-09-27, and a version 0.2 CRAN release on 2021-01-30. That is a slow release cadence, which is normal for a package whose output format has to stay stable for the papers already written with it.

The commit history is more active. The last push was on 2026-08-19, and the repository carries the standard R package badges: an R CMD check build status, a codecov test coverage badge, and a lifecycle badge marking the package as stable. The CRAN logs badge tracks download counts over time, and the README carries a note that the coverage summary was last built in 2020, which tells you the coverage badge lags the code.

For a paper being written now, the practical choice is CRAN, because that is the version whose output you can point a reviewer at. The GitHub version is for people who need a fix that has not been submitted, and for anyone who wants to see what changed since 0.3.3, which includes work that may never reach CRAN.

One gap to keep in mind: the repository does not publish GitHub releases, so the commit log and the CRAN version list are the only version records you have, and the gap between them is where unreleased changes live.

Where equatiomatic stops being the right tool

The limits are clear enough that it is worth stating them plainly rather than discovering them at manuscript time.

The first is that the package gives you a symbolic model, not results. If you need the numeric coefficients, the standard errors, the confidence intervals or a table for a results section, this is the wrong tool, and no setting changes that. The output is intentionally abstract, which is what makes it readable in prose and useless as a statistics table.

The second is model coverage. The package aims to support any model supported by broom, and the introduction article is where the current list lives. If your model class is not there, the result is not a worse equation but no equation, and the README does not document a fallback or an extension point for writing your own renderer.

The third is that it is an R package, so it only helps if your analysis is in R. A fitted model from Python, Stata or R itself computed with a different toolchain has no path into this workflow, and a manuscript written across two languages will still need the equation typed or generated elsewhere.

The fourth is scope. A LaTeX equation in a paper is one artifact. equatiomatic does not produce the figure, the table, the appendix of model output, or the reproducible script that ties them together. It removes one repetitive task from a larger writing workflow, which is a good trade if that task was in fact repetitive for you, and a distraction if your equations were already fine.

Editorial conclusion

equatiomatic fits an R user who writes papers and needs a symbolic equation for a model they have already fitted, and it does not fit someone who needs the numeric estimates, the standard error table or a figure, since it renders the structure of the model rather than the numbers behind it. Before you rely on it, check the introduction to equatiomatic for the list of models currently supported, since coverage depends on broom, and note that the last CRAN release was v0.3.3 on 2024-05-28 while the last push was on 2026-08-19, so install from CRAN for a stable build and from GitHub only if you need what is in the development version.

Frequently asked questions

Official sources

1. datalorax/equatiomatic on GitHub
2. License: CC-BY-4.0
3. Project website
4. README
5. Releases