Development Plans for CVXR

Catching Up with CVXPY — A Progress Report

Balasubramanian Narasimhan

Stanford University

Anqi Fu

2026-02-19

“So… I had this idea. What if I just asked AI to do the whole thing?”

[Pause for effect. Read the terminal output.]

“Package done. 7,199 tests. 13 solvers. Half a second. My talk is done! Thank you!”

[Pretend to leave the podium. Wait for laughter.]

Actually…

As you probably guessed, that was a joke.

Really, this is hard work.

Let me give you a proper progress report.

[Walk back to podium] “OK fine, I’m not getting off that easy. Let me tell you what actually happened.”

The Mission

• CVXR: The R port of CVXPY
• Developer community: 2 (yes, two)
• Released version: 1.0-15 (S4 classes)
• Has fallen behind CVXPY in features

But:

• New AI development tools
• New facilities in R (S7 classes)
• Offer hope of catching up

CVXR mirrors CVXPY’s disciplined convex programming approach. But with only two developers, we couldn’t keep pace with CVXPY’s larger community. The released version was missing DGP, DPP, DQCP, complex number support, and many solvers.

What is R?

For the Python developers in the room:

• Created 1993 (descendant of S, 1976)
• #1 language in statistics and biostatistics
• 20,000+ packages on CRAN
• Bioconductor, tidyverse, Shiny
• Vectorized, functional, multiple dispatch

“Everything that exists is an object. Everything that happens is a function call.”

— John Chambers

R is where statisticians live. If you do convex optimization for statistics, your users are likely R users. The Chambers quote is key: R is deeply object-oriented, but in a different way than Python.

R’s Object Systems

R has four major OOP systems. Yes, four.

S3 — Duck typing

# Just slap on a class attribute
person <- list(name = "Alice", age = 30)
class(person) <- "person"

# Methods: generic.class
print.person <- function(x, ...)
  cat("Person:", x$name, "\n")

S4 — Formal & strict

setClass("Person",
  slots = list(name = "character",
               age  = "numeric"))
setGeneric("greet",
  function(x) standardGeneric("greet"))
setMethod("greet", "Person",
  function(x) cat("Hi,", x@name, "\n"))

R6 — Reference semantics

Person <- R6::R6Class("Person",
  public = list(
    name = NULL,
    initialize = function(name)
      self$name <- name,
    greet = function()
      cat("Hi,", self$name, "\n")
  ))

S7 — The new hope (2024)

Person <- new_class("Person",
  properties = list(
    name = class_character,
    age  = class_numeric
  ))
method(greet, Person) <- function(x)
  cat("Hi,", x@name, "\n")

S3 is simple but loose. S4 is strict but verbose. R6 feels Pythonic but has reference semantics (unusual in R). S7 combines the best: strict like S4, clean like Python, value semantics like R.

S4: The Verbose Way

The Abs atom in old CVXR — one of 100+ atoms to implement:

.Abs <- setClass("Abs", representation(x = "Expression"),
                 contains = "Elementwise")

Abs <- function(x) { .Abs(x = x) }

setMethod("initialize", "Abs", function(.Object, ..., x) {
  .Object@x <- x
  callNextMethod(.Object, ..., atom_args = list(.Object@x))
})
setMethod("to_numeric",      "Abs", function(object, values) abs(values[[1]]))
setMethod("sign_from_args",  "Abs", function(object) c(TRUE, FALSE))
setMethod("is_atom_convex",  "Abs", function(object) TRUE)
setMethod("is_atom_concave", "Abs", function(object) FALSE)
setMethod("is_incr", "Abs", function(object, idx) is_nonneg(object@args[[idx]]))
setMethod("is_decr", "Abs", function(object, idx) is_nonpos(object@args[[idx]]))
setMethod("is_pwl",  "Abs", function(object) is_pwl(object@args[[1]]))
# ... and more for .grad, .domain, graph_implementation ...

Now imagine doing this 100+ times, keeping in sync with CVXPY.

Every atom requires a class definition PLUS 10+ separate setMethod calls, each with verbose boilerplate. The methods are scattered across files. And this is just ONE of over 100 atoms. Translating from CVXPY’s Python classes to this is painful and error-prone.

R Package Structure

CVXR/
├── DESCRIPTION      # Metadata, dependencies, version
├── R/               # All R source files ← FLAT directory!
│   ├── expression.R
│   ├── variable.R
│   ├── abs.R
│   └── ...246 files...
├── src/             # C/C++ code (canonicalization)
├── man/             # Documentation (one .Rd per export)
├── tests/           # Test files
└── vignettes/       # Long-form documentation

The problem: CVXPY has a deep directory tree with naturally occurring filename clashes (e.g. atoms/affine/sum.py vs atoms/axis_atom/sum.py).

R packages require a flat R/ directory.

How do you flatten without collisions — and still find things?

CVXPY organizes code in atoms/affine/, atoms/elementwise/, reductions/dcp2cone/, etc. But R packages must have all .R files in a single flat R/ directory. This makes it very hard to keep the two codebases in sync.

Mirroring CVXPY: The rsrc_tree Solution

Develop in an isomorphic tree:

rsrc_tree/
├── atoms/
│   ├── elementwise/
│   │   ├── abs.R
│   │   └── exp.R
│   └── affine/
│       ├── reshape.R
│       └── index.R
├── reductions/
│   └── dcp2cone/
│       └── canonicalizers/
└── ...

Every file starts with:

## CVXPY SOURCE: atoms/elementwise/abs.py

Build script flattens to R/:

R/
├── 045_atoms_elementwise_abs.R
├── 046_atoms_elementwise_exp.R
├── 047_atoms_affine_reshape.R
├── 048_atoms_affine_index.R
├── 112_reductions_dcp2cone_...R
└── ...

Numeric prefixes control load order.

One script. Automatic. Reversible.

This was a critical design decision. We maintain an rsrc_tree directory that mirrors CVXPY’s directory structure exactly. A build script (copy_r_source.R) flattens it to R/ with numbered prefixes. Every R file is annotated with its CVXPY counterpart. This means an AI or a human can always find the corresponding CVXPY code.

Enter S7

The next generation R OOP system (R Consortium, 2024):

Abs <- new_class("Abs", parent = Elementwise,
  constructor = function(x) {
    x <- as_expr(x)
    new_object(S7_object(), args = list(x), shape = x@shape)
  }
)

method(sign_from_args,  Abs) <- function(x) list(is_nonneg = TRUE, is_nonpos = FALSE)
method(is_atom_convex,  Abs) <- function(x) TRUE
method(is_atom_concave, Abs) <- function(x) FALSE
method(is_incr,         Abs) <- function(x, idx, ...) is_nonneg(x@args[[idx + 1L]])
method(is_decr,         Abs) <- function(x, idx, ...) is_nonpos(x@args[[idx + 1L]])
method(numeric_value,   Abs) <- function(x, values, ...) abs(values[[1L]])

Clean. Compact. One file per atom.

S7 is a joint effort by the R Consortium to unify R’s OOP systems. It combines S4’s formal types with S3’s simplicity. The constructor is embedded in the class definition. Methods are clean one-liners. And it’s FAST — 300x faster than S4 for object construction.

S7 ≈ Python

CVXPY (Python)

class Abs(Elementwise):

    def __init__(self, x):
        super().__init__(x)

    def sign_from_args(self):
        return (True, False)

    def is_atom_convex(self):
        return True

    def is_atom_concave(self):
        return False

    def numeric(self, values):
        return np.abs(values[0])

CVXR (S7/R)

Abs <- new_class("Abs",
  parent = Elementwise, ...)

method(sign_from_args, Abs) <-
  function(x)
    list(is_nonneg = TRUE,
         is_nonpos = FALSE)

method(is_atom_convex, Abs) <-
  function(x) TRUE

method(is_atom_concave, Abs) <-
  function(x) FALSE

method(numeric_value, Abs) <-
  function(x, values, ...)
    abs(values[[1L]])

The structure maps almost 1:1. Perhaps an AI can translate it…

Look at how close these are. The class definition, the method signatures, even the return values are nearly identical. This structural similarity is what makes AI-assisted translation feasible. S7 was the missing piece.

So We Tried It

A systematic, AI-assisted rewrite of CVXR.

With guardrails:

• Isomorphic file structure (mandatory)
• 15 architectural constraints
• 150+ documented design decisions
• Rigorous test mapping to CVXPY

We didn’t just say “AI, port this.” We created a systematic framework: mandatory constraints, documented decisions, test mapping. The AI was a powerful tool, but the architecture was human-designed.

The Journey

Each bar represents a major milestone. We started with 95 tests in the foundation phase and grew to 7,199. The growth was steady and methodical — each phase built on the previous one, with full test coverage at every step. No regressions.

Design Choices That Mattered

Structural

• Isomorphic file tree — every CVXPY .py maps to an R .R at the same path
• S3 Ops handler for arithmetic (not S7 method()) — handles unary -x correctly
• C++ bridge unchanged — reuse CVXcanon from old CVXR

Practical

• Cache pattern mirroring CVXPY’s @lazyprop with R environments
• Dual sign convention documented per solver (13 solvers, 5 problem types)
• Every decision recorded (150+ in decisions.md)

These aren’t arbitrary choices. The isomorphic file structure means any future CVXPY update can be systematically translated. The S3 Ops handler was necessary because S7’s method() evaluates both operands, breaking unary operators. The C++ bridge was our biggest reuse win: thousands of lines of canonicalization code, unchanged.

Testing Kept Us Honest

• 3,247 test blocks, each annotated:

  ## @cvxpy test_problem.py::TestLP::test_basic
  test_that("basic LP solves", {
    x <- Variable(2)
    prob <- Problem(Minimize(sum(x)),
                    list(x >= 1))
    result <- psolve(prob)
    expect_equal(result, 2, tolerance = 1e-4)
  })

• Cross-referenced with 1,641 CVXPY tests

• Validation scripts to find gaps

Coverage:

Category	Count
CVXPY parity	514
R-specific	2,197
Documented N/A	699
Total	3,247

Every test block is annotated with its CVXPY counterpart. We have scripts that extract all CVXPY test IDs, scan our annotations, and report gaps. This is how we maintained parity across 7,199 tests. If a CVXPY test exists, we either have the R equivalent or a documented reason why it’s N/A.

Solver Progression

We started with just SCS and Clarabel to prove the pipeline worked. Then we added solvers methodically, testing each one against CVXPY’s results. The dual-interface architecture (QP path vs conic path) matches CVXPY exactly, so adding a new solver is now systematic.

Beyond DCP

Features that old CVXR never had:

• DGP — Disciplined Geometric Programming
  • Log-space transformations, 6 DGP atoms
• DPP — Disciplined Parameterized Programming
  • Tensor-aware C++ bridge, fast re-solve
• DQCP — Disciplined Quasiconvex Programming
  • Bisection solver, ceil/floor atoms

• Complex numbers — Full Complex2Real reduction
  • 50+ canonicalizers, Hermitian variables
• Warm-start — 7 of 13 solvers
• Logic atoms — Not, And, Or, Xor, implies, iff
• Perspective, FiniteSet constraints

This is where the “catching up” becomes “caught up.” These are features the CVXPY community uses that old CVXR simply didn’t have. DGP for geometric programming, DPP for parameterized problems, DQCP for quasiconvex problems, complex number support, warm-start… all working, all tested.

Does it actually work?

Well, let’s see…

[Build the suspense. Pause here.] “I mean, 7,199 tests is great. But does it ACTUALLY work on real problems?”

The Documentation Website

67 working examples

From basic LP to advanced DGP/DPP/DQCP

All tested. All running. All documented.

[THIS IS THE BIG REVEAL. Switch to browser and show the cvxr_docs website, OR use the next few slides to show highlights.]

“We didn’t just build the package. We rebuilt the entire documentation website. 67 examples, covering everything from a gentle introduction to advanced geometric programming. Let me show you…”

What’s in the Docs

Getting Started

• Quick Introduction
• Gentle Introduction
• Basic: LP, QP, SOCP, SDP, MIQP

Regression (9)

• Huber, Logistic, Quantile
• Censored, Isotonic
• Elastic Net, Pliable Lasso

ML & Finance

• Lasso, Ridge, SVM
• Portfolio Optimization
• Kelly Strategy

Applications (14)

• Robust Kalman Filter
• TV Inpainting
• Antenna Array Design
• Channel Capacity
• …and 10 more

Advanced

• DGP: 6 examples
• DPP: 2 examples
• DQCP: 4 examples

Solvers

• Parameters & tuning
• Warm starts
• Speed optimization
• 13 solver configs

Point out the breadth: regression, machine learning, finance, signal processing, statistics, applications. Plus the advanced features: DGP with 6 examples, DPP, DQCP. And practical solver documentation. This is a complete, production-ready documentation site.

By the Numbers

Metric	Value
Expectations passing	7,199
Failures	0
test_that() blocks	3,247
CVXPY parity tests	514 / 1,641
Source files	246
Solvers	13

Metric	Value
Atoms	100+
Canonicalizers	47
Documented examples	67
Design decisions	150+

3,247 test blocks × ~2 expectations each = 7,199. 514 blocks map 1:1 to CVXPY tests; the rest are R-specific or documented N/A.

Explain the testing hierarchy: testthat has test_that() blocks, each containing multiple expect_*() calls. 7,199 is the total expectation count. 3,247 is the number of test_that blocks, each annotated with its CVXPY counterpart (or marked R-specific/N/A). Of CVXPY’s 1,641 test methods, 514 have direct R equivalents, 699 are documented as not applicable to R, and 424 gaps remain to close.

Performance: Expression Building

The S4 overhead that plagued old CVXR is gone:

S4 (old)

1.16 min

1,000 variables
2.54 GB memory

S7 (new)

228 ms

1,000 variables
828 KB memory

305x faster. 3,100x less memory.

This is the raw object construction benchmark. S4’s method dispatch and slot allocation were the bottleneck. S7 eliminates almost all of that overhead. For users building large problems, this is transformative.

Performance: End-to-End

Lasso regression, CLARABEL solver, median of 5 runs:

Build time (problem construction):

Size	Old (S4)	New (S7)
200x50	10 ms	2 ms
500x100	8 ms	2 ms
1000x200	8 ms	2 ms
2000x500	9 ms	2 ms

5x faster builds, consistent across sizes. Solver time dominates for large problems.

Up to 3.3x faster for small/medium problems. For large problems, solver dominates — which is exactly where you want the bottleneck.

The benchmark shows: for small problems (200x50), the new CVXR is 3.3x faster because modeling overhead was a large fraction. For large problems (2000x500), solver time dominates and both versions converge. The key insight: S7 eliminated the modeling tax. The build time went from ~10ms to ~2ms (5x faster). The solver is now the bottleneck, which is where optimization should happen.

To regenerate: cd /Users/naras/research/cvxr/talk && bash benchmark/run.sh

Room to Grow

“Premature optimization is the root of all evil.”

— Donald Knuth

• DPP fast path: parameterized re-solve skips re-canonicalization
• Direct solver calls bypass compilation for repeated solves
• Profiling reveals hotspots (profvis package)
• We got correct first. Speed comes next.

We deliberately chose correctness over optimization. The Knuth quote is our guiding principle. Now that we have 7,199 passing tests, we can profile and optimize with confidence. The DPP fast path alone could give another 10x for parameterized problems.

Click inside the terminal area to start the typing demo. Arrow keys still work to advance slides. The punchline: “All in 10 days.”

So… where are we?

v1.8.0-9044

Aligned with CVXPY 1.8.1

[Say this casually, like it’s no big deal.] “Oh, version 1.8.0-9044. We’re tracking CVXPY 1.8.1.”

Keeping Up with CVXPY

The isomorphic structure isn’t just for the rewrite — it’s the maintenance strategy:

1. CVXPY tags a new release (e.g. 1.9.0)
2. We pin to that commit in our repo
3. rsrc_tree/ + ## CVXPY SOURCE: annotations make diffs obvious
4. AI-assisted translation of changed files
5. Test mapping validates parity
6. Repeat

No-regression guarantee:

Every test_that() block is annotated:

## @cvxpy test_qp.py::TestQP::test_warm

If something breaks:

• The annotation tells you which CVXPY test it mirrors
• You run that CVXPY test to see the expected behavior
• The fix is scoped to one file (isomorphic path)

The breadcrumbs lead you straight back to CVXPY’s ground truth.

The same process that built 1.8.1 in 10 days keeps us in sync going forward.

This is the key insight for sustainability. We’re not just catching up once. Every test block has a breadcrumb annotation linking it to the exact CVXPY test it mirrors. When a regression occurs, you don’t have to guess — the annotation tells you which CVXPY test to look at, you compare behaviors, and the isomorphic file structure means the fix is in one predictable location. It’s a self-documenting debugging system.

What’s Next

Coming soon:

• CRAN submission (R CMD check clean)
• Performance optimization pass
• Remaining CVXPY test parity (424 gaps)
• Community feedback integration

Deferred:

• Derivative/sensitivity API (needs R equivalent of diffcp)
• Quantum computing atoms
• Exotic cone fallbacks

We welcome feedback from the CVXPY and CVXR community.

Is this a good plan? Have we overlooked something? Tell us.

The CRAN submission is close. We need a final polish pass and some dependency cleanup. The derivative API is our biggest gap — it requires a port of diffcp to R, which is a separate project. Everything else is working and tested.

What Made This Work

• Standing on giants’ shoulders
  • CVXPY’s clean architecture and DCP theory
  • 10 years of CVXPY community effort
• Anqi Fu’s astonishing S4 work
  • CVXR from scratch to v1.0-15 using S4
  • That she got it working at all in S4 was a tour de force
  • The design thinking carried forward
• S7 at the right moment
  • Finally, an R OOP that maps to Python

• Disciplined architecture
  • Isomorphic file structure
  • 15 mandatory constraints
  • 150+ documented decisions
• Rigorous testing from day one
  • CVXPY parity as the north star
  • Never move forward with failing tests
• AI-assisted development
  • Claude Code for translation + testing
  • Human judgment for architecture
  • 179 commits in 10 days

This slide is important. Acknowledge Anqi’s work explicitly — getting S4 CVXR to work on CRAN was a heroic effort. S4 is genuinely painful for this kind of deep class hierarchy. Her design decisions and domain knowledge made the S7 rewrite possible. Also acknowledge the CVXPY community — without that clean architecture, none of this works.

[Return to the terminal graphic. Let them read it.]

“So here’s what actually happened. Same output: 246 files, 7,199 tests, 13 solvers. But it took 10 days, not 0.42 seconds. 179 commits. Two humans and Claude Code. Each file reviewed. Each solver debugged. 150+ design decisions.”

[Pause]

“Close enough?”

Thank You

Links:

• CVXR: github.com/cvxgrp/CVXR
• Docs: cvxr.rbind.io
• CVXPY: cvxpy.org

Contact:

• Balasubramanian Narasimhan
• Anqi Fu
• Stanford University

We welcome your feedback!

Yes, this presentation was also made by Claude — in about an hour, from a one-page brief. It read the git history of 3 repos, ran benchmarks comparing old and new CVXR, synthesized 150+ design decisions, and wrote the typing demo. Even the SVG terminal jokes.

Thank the audience. Remind them we’re a team of two and we genuinely want feedback from the CVXPY community. They know what features matter most.