Conversation
Five docstrings carried `>>>` examples that no longer ran:
- `einsum_utilities`: the vendored NumPy helpers were renamed to drop
their leading underscore, but the examples still called
`_find_contraction`, `_optimal_path`, `_greedy_path` and
`_parse_einsum_input`. The examples were also nondeterministic --
set repr ordering and generated einsum index symbols both vary
between processes -- so they now assert sorted/structural output.
- `Constraint.set_label`: no `import cvxpy as cp`, so every example
raised NameError; the variable is now named so its repr is stable.
- `geo_mean`: zero-weight terms are dropped from `w`, so the expected
output no longer lists the `0`.
- `Dgp2Dcp`: variables were defined as `x1..x3` but used as
`x_1..x_3`, `cvxpy.reductions` was referenced with only `cp`
imported, and three calls had no expected output.
`Power` needed more than a doc update. Its note states that domain,
sign, monotonicity and curvature follow the rational approximation
`p_used` rather than the input exponent. `is_incr`/`is_decr` already
did, but `is_atom_convex`, `is_atom_concave` and `sign_from_args`
still read `self.p.value`, so `power(x, 1.0001)` and `power(x, 1)`
were classified differently despite both reducing to `p_used == 1`:
power(x, 1) AFFINE, UNKNOWN
power(x, 1.0001) CONVEX, NONNEGATIVE <- before
power(x, 1.0001) AFFINE, UNKNOWN <- after
Those three now consult `p_used`, matching the documented behaviour
and the existing monotonicity logic. Parametrized exponents are
unaffected (`p_used is None` keeps the previous fallback).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Asserts that an exponent approximating to exactly 1 (1.0001) is affine
like power(x, 1), that one which does not (1.001) stays convex and
nonnegative, and that a parametrized exponent is still unknown.
Verified to fail against the previous behaviour ('CONVEX' != 'AFFINE').
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
Benchmarks that have stayed the same:
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Five docstrings shipped
>>>examples that no longer ran. Fixing the last of themsurfaced a real behaviour bug in
Power, which is also fixed here.Docstring fixes
cvxpy/utilities/einsum_utilities.py— the vendored NumPy helpers were renamed todrop their leading underscore, but the examples still called
_find_contraction,_optimal_path,_greedy_pathand_parse_einsum_input, so every one raisedNameError. They were also nondeterministic by construction: set repr ordering and thegenerated einsum index symbols both vary between processes, and the
# may varymarkeris a NumPy refguide-check convention that plain
doctestdoes not honour. They nowassert sorted and structural output instead.
cvxpy/constraints/constraint.py—Constraint.set_labelhad noimport cvxpy as cp, so all four examples raisedNameError. The variable is now namedso its repr does not depend on the global variable counter.
cvxpy/atoms/geo_mean.py— zero-weight terms are dropped fromw, so the expectedoutput no longer lists the
0.cvxpy/reductions/dgp2dcp/dgp2dcp.py— variables were defined asx1..x3but usedas
x_1..x_3;cvxpy.reductionswas referenced with onlycpimported; and threecalls had no expected output.
Behaviour fix in
PowerThe
Powerdocstring states that domain, sign, monotonicity and curvature are determinedby the rational approximation
p_used, not the input exponent.is_incr/is_decralready did this, but
is_atom_convex,is_atom_concaveandsign_from_argsstill readself.p.value. So two exponents that reduce to the samep_usedwere classifieddifferently:
power(x, 1.0001)hasp_used == 1— mathematically identical topower(x, 1)afterapproximation — yet was treated as convex with an implicit
x >= 0. Those three methodsnow consult
p_used, following the pattern already established byis_incr/is_decr.Parametrized exponents are unaffected:
p_used is Nonekeeps the previous fallback.Note this is a semantic change to DCP curvature analysis and deserves a careful look,
even though the suite is green.
Issue link (if applicable): n/a
Type of change
Contribution checklist
Checklist notes, for transparency:
test_power_curvature_follows_rational_approximationincvxpy/tests/test_atoms.pycovers the curvature change. It was verified to fail againstthe previous behaviour (
AssertionError: 'CONVEX' != 'AFFINE') and pass after. Thedocstring fixes are covered by the restored doctests themselves.
solver-gated: only CLARABEL, SCS, SCIPY, HIGHS and OSQP were installed, so the
commercial-solver paths through
powerwere not exercised here and rely on CI.Also verified:
pyrightreports 0 errors, and all pre-commit hooks pass.🤖 Generated with Claude Code