Skip to content
All library documents

L1 Logistic Regression Solver and Tolerance Tradeoffs

Code Machine Learning for Trading

Summary

This configuration note explains the choice of the saga solver and a tighter convergence tolerance for L1 logistic regression on three-class labels. It contrasts saga with liblinear, citing runtime measurements on a Nasdaq microstructure panel and reported out-of-sample log loss and accuracy. The measured runs favored saga on both speed and those predictive metrics, while the authors report that full-panel runtime remains uncertain.

The tolerance choice also affects whether small coefficients become exactly zero. Since exact sparsity is the purpose of the L1 sweep, the note compares exact-zero counts with counts of coefficients merely near zero. At the looser tolerance, some coefficients were tiny but nonzero; the tighter setting aligned those counts and produced more sparse solutions in the measured settings. The configuration uses the smaller tolerance for this strongly penalized case.

These observations come from a particular dataset and solver comparison, not a general guarantee. The full-size compute cost is explicitly unestablished, and the large-panel estimate extrapolates from limited timing evidence. Runtime and sparsity behavior should therefore be checked in the target environment.

Key ideas

  • The saga solver is chosen for multiclass L1 logistic regression and measured substantially faster than liblinear on the cited panel.
  • The reported saga runs also had better out-of-sample log loss and accuracy in that comparison.
  • A tighter tolerance can distinguish exact zeros from coefficients that are merely very small.
  • The full-panel runtime is uncertain because its estimate relies on limited scaling evidence.
  • Solver performance and sparsity should be verified on the actual dataset and environment.

Tags

Full text
# logistic_l1_C0.001.yaml


```yaml
# L1 logistic regression. The solver is `saga` rather than `liblinear`, and the tolerance
# is set explicitly rather than left at scikit-learn's 1e-4 default.
#
# Two reasons, and the first one is not optional. These labels are three-class (-1, 0, 1),
# and scikit-learn 1.8 makes multiclass `liblinear` a hard error; #740 already moved our
# floor to 1.7. `OneVsRestClassifier(liblinear)` would reproduce the current objective
# exactly - liblinear multiclass IS one-vs-rest - and would keep the problem below.
#
# The second is that `liblinear` does not finish. It is single-threaded coordinate descent
# and scales about N^1.4 here. Measured on nasdaq100_microstructure's `fwd_dir_15m` panel:
#
#     rows      liblinear 1000/1e-4     saga 200/1e-2
#     400,000     144.4s  converged      11.0s  converged
#   1,200,000     716.9s  converged      44.8s  converged
#
# which extrapolates to roughly eight hours per configuration at the full 16.9M rows against
# about twenty minutes. That is not a projection: `06_linear` ran 7h23m at 100% of one core
# on 2026-09-05 and was killed with two of thirteen configurations still unfinished, both of
# them these L1 ones.
#
# saga is also better out of sample at every C measured here: log loss 1.0273-1.0276 against
# liblinear's 1.0293-1.0294, and accuracy 0.415-0.420 against 0.404-0.410.
#
# `tol: 0.001` here rather than the 0.01 the weakly-penalised configurations use, because
# this is where the penalty binds and exact sparsity is the point of the sweep. At 1e-2 saga
# leaves coefficients stranded NEAR zero instead of AT zero, which `coef_ != 0` then counts
# as live. Measured on the same panel, exact zeros against coefficients below 1e-8, out of
# 198:
#
#     C        liblinear 1e-4     saga 1e-2        saga 1e-3
#     0.001      128 / 128         148 / 149        157 / 157
#     0.01        40 /  40          24 /  52         87 /  87
#     0.1          8 /   8           3 /   4         24 /  26
#
# The 24-against-52 at C=0.01 is the defect: twenty-eight coefficients below 1e-8 that are
# not zero. At 1e-3 the two counts agree and saga is *more* sparse than liblinear at every C
# here, so the tighter tolerance is not a concession - it is what makes the L1 solution an
# L1 solution.
#
# Cost at 1.2M rows: 226s, 352s and 287s for C=0.001, 0.01 and 0.1 against liblinear's 30s,
# 202s and 499s. **The full-panel cost of this arm is not established** - the 16.9M-row
# extrapolation is uncertain because it rests on a single scaling estimate taken from the
# tol=1e-2 timings. Watch it on the first run rather than assuming it is small.
model_class: LogisticRegression
params:
  C: 0.001
  max_iter: 200
  penalty: l1
  solver: saga
  tol: 0.001

```

Shown in full with attribution under the source's licence. Licence: MIT

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.