Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

54 multiplier models #66

Open
wants to merge 61 commits into
base: 54-multiplier-models
Choose a base branch
from

Conversation

IsitaRex
Copy link

@IsitaRex IsitaRex commented Dec 7, 2022

Closes #54

Changes

On the multipliers module we created a new class called cooper.multipliers.MultiplierModel, which predicts the value of the Lagrange multipliers associated with the equality or inequality constraints of a cooper.problem.ConstrainedMinimizationProblem.
Additionally, we created a new Lagrangian formulation --> cooper.formulation.LagrangianFormulation that works with the created MultiplierModel class.

Testing

We tested the class multipliers.MultiplierModel with the simplest model. A linear model with a single output.
The new Lagrangian Formulation was also tested.

References

This idea comes from the paper by Narasimhan et al. and we took their repository as reference.

IsitaRex and others added 30 commits November 5, 2022 18:33
- Create MultiplierModel as instance of multipliers instead of multiplier_model class

- Implement MultiplierModel tests
Added MultiplierModel
Added LagrangianModelFormulation
Change meta to metaclass
@gallego-posada gallego-posada marked this pull request as ready for review December 7, 2022 22:59
@juan43ramirez juan43ramirez added the enhancement New feature or request label Dec 7, 2022
@juan43ramirez juan43ramirez linked an issue Dec 7, 2022 that may be closed by this pull request
Lagrange multipliers.
is_positive: Whether to enforce non-negativity on the values of the
multiplier.
"""
Copy link

Choose a reason for hiding this comment

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

Are these arguments valid? I think that they should be removed and we should make explicit that class is meant to be inherited by the model class, just as it is done with torch.nn.Module

@@ -119,6 +124,11 @@ def load_state_dict(self, state_dict: dict):
"""
pass

def flip_dual_gradients(self):
Copy link

Choose a reason for hiding this comment

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

Remove repeated class

class LagrangianModelFormulation(BaseLagrangianFormulation):
"""
# TODO: document this
Computes the Lagrangian based on the predictions of a `MultiplierModel`.
Copy link

Choose a reason for hiding this comment

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

Give a more complete description of the formulation and add the arguments of the init to it.


# Update multipliers based on current constraint violations (gradients)
self.dual_optimizer.step()

if self.formulation.ineq_multipliers is not None:
# TODO: Check if the isintance flag has to be added to other optimizers
Copy link

Choose a reason for hiding this comment

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

Missing TODO

@@ -65,6 +65,8 @@ def base_sanity_checks(self):
Perform sanity checks on the initialization of ``ConstrainedOptimizer``.
"""

# TODO: ensure that the dual optimizer and the dual scheduler is initialized when LagrangeModelFormulation
Copy link

Choose a reason for hiding this comment

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

Missing TODO

@@ -94,17 +94,20 @@ def step(

def dual_step(self):

# TODO: Fill the flip dual gradients and model formulation flag with other optimizers
Copy link

Choose a reason for hiding this comment

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

Missing TODO

# It's unclear why this difference exists. Must be checked before
# merging into main
# new_loss = lagrangian - self.accumulated_violation_dot_prod
# new_loss.backward(inputs=dual_vars)
Copy link

Choose a reason for hiding this comment

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

This alternative implementation should be disregarded, that implementation corresponds to confusion made while looking at the authors' code, it was a test. The current implementation is the one that works and should be kept.

self.eq_multiplier_model = eq_multiplier_model

if self.ineq_multiplier_model is None and self.eq_multiplier_model is None:
# TODO: document this
Copy link

Choose a reason for hiding this comment

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

Is it really necessary to document this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multiplier Models
3 participants