Skip to content

more tests on lagrange multipliers#3

Merged
aadityacs merged 1 commit into
mainfrom
lagrange_multipliers
Nov 13, 2025
Merged

more tests on lagrange multipliers#3
aadityacs merged 1 commit into
mainfrom
lagrange_multipliers

Conversation

@aadityacs

Copy link
Copy Markdown
Owner

No description provided.

@aadityacs aadityacs merged commit 3000f1c into main Nov 13, 2025
0 of 2 checks passed
@gemini-code-assist

Copy link
Copy Markdown

Summary of Changes

Hello @aadityacs, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly improves the robustness and reliability of the MMA optimization implementation by expanding its test suite. The new tests specifically focus on validating the theoretical properties of Lagrange multipliers and KKT conditions under various constraint and scaling scenarios, ensuring the algorithm behaves as expected in critical optimization contexts. Additionally, a standard .gitignore file has been added for better repository hygiene.

Highlights

  • New .gitignore file: A comprehensive .gitignore file has been added to the repository, ensuring that common development artifacts, build files, and environment-specific data are excluded from version control.
  • Enhanced Test Coverage for Lagrange Multipliers: Several new test cases have been introduced to rigorously verify the behavior of Lagrange multipliers and Karush-Kuhn-Tucker (KKT) stationarity conditions within the MMA optimization algorithm. These tests cover active general constraints, variables at lower and upper bounds, mixed bound scenarios, and the scaling properties of multipliers.
  • Removed Debug Print Statements: Redundant debug print statements that displayed objective values during optimization iterations have been removed from the test suite, cleaning up console output.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a .gitignore file, removes several debugging print statements, and significantly expands the test suite for Lagrange multipliers in the MMA solver. The new tests are well-designed, covering stationarity conditions for various bound scenarios and scaling properties of the multipliers. My review focuses on suggesting tighter tolerances in the assertions of these new tests to increase their robustness and ensure they can effectively catch subtle inaccuracies in the solver's results.

Comment thread mmapy/mma_test.py
Comment on lines +884 to +888
self.assertLess(
residual_norm,
0.5,
msg=f"Stationarity at bounds violated: ||∇f - ξ|| = {residual_norm}",
)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The tolerance for the stationarity check (0.5) seems quite high. With a kkt_tol of 1e-6 for the solver, a residual norm of up to 0.5 is surprising. The gradient ∇f at the optimal point (1, 1) is [1, 1], so the lower bound multiplier ξ should be very close to this. A large residual norm could mask inaccuracies.

Consider tightening this tolerance to better reflect the expected accuracy of the KKT conditions, for example to 1e-4. If this high tolerance is necessary due to the solver's behavior, a comment explaining why would be helpful.

Suggested change
self.assertLess(
residual_norm,
0.5,
msg=f"Stationarity at bounds violated: ||∇f - ξ|| = {residual_norm}",
)
self.assertLess(
residual_norm,
1e-4,
msg=f"Stationarity at bounds violated: ||∇f - ξ|| = {residual_norm}",
)

Comment thread mmapy/mma_test.py
Comment on lines +969 to +973
self.assertLess(
residual_norm,
0.5,
msg=f"Stationarity at upper bounds violated: ||∇f + η|| = {residual_norm}",
)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Similar to the lower bound test, the tolerance of 0.5 for the stationarity residual norm seems very loose, especially given the kkt_tol of 1e-6. At the optimum (10, 10), ∇f is [-1, -1], so the upper bound multiplier η should be close to [1, 1]. A large residual norm could hide issues.

I recommend tightening this tolerance to ensure the KKT conditions are being met with sufficient precision (e.g., 1e-4). If there's a specific reason for this loose tolerance, it would be good to document it in a comment.

Suggested change
self.assertLess(
residual_norm,
0.5,
msg=f"Stationarity at upper bounds violated: ||∇f + η|| = {residual_norm}",
)
self.assertLess(
residual_norm,
1e-4,
msg=f"Stationarity at upper bounds violated: ||∇f + η|| = {residual_norm}",
)

Comment thread mmapy/mma_test.py
Comment on lines +1142 to +1147
self.assertLess(
relative_error,
0.2, # 20% tolerance
msg=f"Multiplier should scale with objective. "
f"Expected {expected_lambda:.4f}, got {actual_lambda:.4f}",
)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

A 20% tolerance for the scaling of the Lagrange multiplier seems quite generous and might mask subtle issues. Consider tightening this tolerance to 5% or 10% (e.g., 0.1). If not, adding a comment to explain why such a large tolerance is needed would be beneficial for future maintainers.

Suggested change
self.assertLess(
relative_error,
0.2, # 20% tolerance
msg=f"Multiplier should scale with objective. "
f"Expected {expected_lambda:.4f}, got {actual_lambda:.4f}",
)
self.assertLess(
relative_error,
0.1, # 10% tolerance
msg=f"Multiplier should scale with objective. "
f"Expected {expected_lambda:.4f}, got {actual_lambda:.4f}",
)

Comment thread mmapy/mma_test.py
Comment on lines +1254 to +1258
self.assertLess(
relative_deviation,
0.3, # 30% tolerance
msg="λ * scale should be approximately constant",
)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The 30% tolerance for checking if λ * scale is constant is very high. This could potentially allow incorrect behavior to pass the test. It would be better to have a much stricter tolerance, like 10% (0.1), to ensure the inverse scaling property holds with reasonable accuracy. If the current solver implementation doesn't allow for a tighter tolerance, it would be valuable to add a comment explaining this limitation.

Suggested change
self.assertLess(
relative_deviation,
0.3, # 30% tolerance
msg="λ * scale should be approximately constant",
)
self.assertLess(
relative_deviation,
0.1, # 10% tolerance
msg="λ * scale should be approximately constant",
)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant