abess: best-subset selection with a certifiably polynomial algorithm
Fast Best-Subset Selection Library
At a glance
- What is it?
- abess is a C++ library with Python and R interfaces that solves best-subset selection across linear, logistic, Poisson, Cox, multi-task and Ising models. Its selling point is a specific algorithmic guarantee for linear regression, not a general speed claim.
- Who is it for?
- Adopt abess if you need a sparse subset of predictors rather than shrunken coefficients, and your problem is one of the supported families: linear, logistic, Poisson or Gamma counting, Cox, multi-task, Ising, or sparse PCA. Do not adopt it if you need a permissive licence, if your data are wide enough that even a polynomial-time routine will not fit in memory, or if L1 shrinkage plus post-hoc thresholding already answers your question.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Activity is slowing. The repository last received commits 6 months ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem abess addresses: picking predictors, not shrinking them
Most sparse regression tooling in Python and R solves a convex relaxation of the subset problem. Lasso and its relatives add an L1 penalty to the loss, which shrinks coefficients toward zero and happens to zero some of them out. The resulting support is a by-product of the penalty path, not the object being optimized. abess optimizes the thing you actually asked for: find a subset of predictors of a given size such that the fitted model has the highest expected accuracy. The README frames the motivation in applied terms, using clinicians who want to know whether a patient is healthy based on the expression levels of a few important genes. That is a setting where the identity of the selected variables matters as much as the prediction, and where a support chosen by a penalty parameter is harder to defend than a support chosen by direct search.
The library is aimed at statisticians and machine learning practitioners who work in high-dimensional data and who are willing to accept a heavier per-fit cost in exchange for a support set that was optimized directly. It is not a drop-in replacement for scikit-learn's linear models in the sense of matching their API surface or their runtime profile. The README states the package has both Python and R interfaces, and the topics list covers feature selection, high-dimensional data, and sure independence screening, which tells you the intended audience is people doing variable selection as a first-class task rather than as a preprocessing step.
What the generic algorithm framework actually covers
abess describes itself as implementing a generic algorithm framework for finding the optimal solution, and then lists the model families that framework has been instantiated for. The list is longer than most feature-selection packages attempt: linear regression, binary and multi-class classification, counting-response modeling (Poisson and Gamma, per the gallery filename), censored-response modeling via Cox regression, multi-response modeling for multi-task learning, and Ising model estimation. The gallery also covers sparse principal component analysis and robust sparse PCA, which are outside the regression families but share the same selection machinery.
Beyond the base problem, the README names two variants. Group best subset selection treats predictors as members of groups and selects at the group level, which is what you want when a categorical variable has been expanded into dummy columns and you need the whole variable in or out. Nuisance penalized regression handles the case where some covariates must be adjusted for but are not themselves subject to selection. Both have dedicated gallery pages, so they are documented features rather than incidental options.
The one claim in the README that deserves to be read precisely is this: the time complexity of (group) best subset selection for linear regression is certifiably polynomial. The parenthetical matters. The guarantee is stated for linear regression and its grouped variant, not for the full list of supported families. If you are running Cox regression or an Ising model, the README does not extend that complexity statement to your case. Treat the polynomial guarantee as scoped to the linear and group-linear settings until you find otherwise in the documentation.
Installing and fitting a first model in Python
The README gives two installation routes for the Python package. From PyPI:
pip install abess
Or from conda-forge:
conda install abess
The R package installs from CRAN with install.packages("abess"). The Python quick start builds a simulated dataset and fits a linear model in four lines:
from abess.linear import LinearRegression from abess.datasets import make_glm_data sim_dat = make_glm_data(n = 300, p = 1000, k = 10, family = "gaussian") model = LinearRegression() model.fit(sim_dat.x, sim_dat.y)
The simulator call is worth reading closely because it encodes the regime abess is designed for: 300 observations, 1000 predictors, 10 of them active. That is p greater than n by more than a factor of three, with a sparse true support. The R quick start is parallel in structure, using generate.data(n = 300, p = 1000) and then a single abess(x = ..., y = ...) call rather than an object with a fit method. The two interfaces are not symmetric in style, which matters if you maintain code in both languages and expect the calls to mirror each other.
The README also states that the runtime comparisons shown in its figures can be reproduced by running python abess/docs/simulation/Python/timings.py from a shell. The timings were collected on an Ubuntu platform with an Intel Core i9-9940X at 3.30GHz and 48GB of RAM, per the README. Those are the project's own numbers on the project's own hardware; they are not a substitute for measuring on your data.
Where the polynomial guarantee stops being useful
Polynomial time is not the same as fast. A polynomial-time routine on a problem with a thousand predictors can still be slower than a convex solver on the same data, and the README's own framing acknowledges this indirectly by leading with runtime comparisons against scikit-learn, glmnet, ncvreg and L0Learn rather than with the complexity result. If your workflow fits hundreds of models inside a cross-validation loop, the per-fit cost of direct subset search is the number that governs your wall clock, not the asymptotic class.
The more concrete limitation is scope. The README's complexity claim is attached to linear regression and group best subset selection. For the other supported families, the documentation describes what the framework supports but the README does not make an equivalent complexity statement. Anyone choosing abess specifically because of the polynomial result should confirm that the family they need is covered by it.
Memory is the third constraint, and the README does not address it. Best-subset methods operate on the full design matrix, and the library is written in C++ with Python and R bindings, so the data will be materialized in a form the solver can traverse. There is no mention of out-of-core operation, sparse matrix handling, or a streaming interface in the supplied material. If your design matrix does not fit comfortably in RAM, that is a question to answer before installing, not after.
Finally, the licence metadata is genuinely ambiguous. The repository metadata reports NOASSERTION, while the README carries a GPL v3 badge linking to gnu.org/licenses/gpl-3.0. Those two signals point in different directions, and the discrepancy is not something this review can resolve. If you are integrating abess into a proprietary pipeline, read the LICENSE file at the repository root yourself rather than trusting either the badge or the metadata field.
How abess differs from glmnet and L0Learn
The README's R runtime comparison names three alternatives directly: glmnet, ncvreg, and L0Learn. The first two are convex-penalty packages. glmnet implements the elastic net family, where the L1 component produces sparsity as a side effect of the penalty path. You choose lambda, and the support falls out. ncvreg works with nonconvex penalties such as MCP and SCAD, which reduce the bias that L1 introduces on large coefficients, but the selection is still driven by a penalty parameter and the solution is still computed along a regularization path.
L0Learn is the closer comparison, because it also targets the L0-penalized problem, meaning it optimizes over the number of nonzero coefficients rather than over a convex surrogate. The difference between abess and L0Learn is in the algorithmic strategy and in model coverage. The abess README positions its contribution as a generic framework with a stated complexity result for the linear case, and it extends that framework to Cox regression, multi-task learning, Ising models, and sparse PCA. L0Learn's documented scope is narrower. If your problem is a Cox model or a multi-task regression, that coverage difference is the deciding factor, not runtime.
Against scikit-learn, the distinction is one of purpose. scikit-learn's linear models give you penalized estimators with a familiar fit and predict interface and a broad ecosystem around them. abess gives you a subset-search estimator with a smaller surface area. If you need pipelines, grid search over arbitrary hyperparameters, and interchange with the rest of the scikit-learn API, the abess classes are a foreign object in that ecosystem, and the README does not claim otherwise.
Release cadence, version pinning and upgrade cost
The release history in the supplied material shows 0.4.7 in September 2023, 0.4.8 in April 2024, and 0.4.11 in March 2026. That is a long gap between 0.4.8 and 0.4.11, and the jump from 0.4.8 to 0.4.11 skips two patch numbers, which suggests intermediate releases that are not listed here. The project is not archived and the last push is dated 2026-03-15, ten days after the 0.4.11 release, so the repository is active as of that date.
For a library at 0.x, the practical upgrade question is whether the estimator classes and their defaults are stable across patch versions. The supplied material does not include a changelog, so the "What's New" section referenced in the README table of contents is the place to look before bumping a pinned version. If you are running abess inside a production pipeline, pin the version explicitly in requirements.txt or in your R environment and read that section before moving.
The licence question interacts with upgrade cost. If the effective licence is GPL v3, then distributing software that links against abess carries obligations that a permissive licence would not impose. This review is not legal advice, and the NOASSERTION metadata versus GPL v3 badge discrepancy means the only reliable source is the LICENSE file in the repository. For internal research use the question is usually moot; for anything shipped to customers, it is the first thing to settle.
Editorial conclusion
Adopt abess if you need a sparse subset of predictors rather than shrunken coefficients, and your problem is one of the supported families: linear, logistic, Poisson or Gamma counting, Cox, multi-task, Ising, or sparse PCA. Do not adopt it if you need a permissive licence, if your data are wide enough that even a polynomial-time routine will not fit in memory, or if L1 shrinkage plus post-hoc thresholding already answers your question. Before committing, verify three things: the exact licence text at the repository root, since the metadata reports NOASSERTION while the README badge points to GPL v3; whether your R version satisfies the CRAN package requirements; and whether the group or nuisance-penalized variants you intend to use appear in the 0.4.11 release notes.
Community notes