Gurobi C++ expr sum

回答済み

ALESSANDRA VIEIRA

2023年12月11日 23:40 編集済み

• 
• 
• 

Hi Folks,

I need some help with my code. I am using Gurobi C++.

I did a QuadExpr sum += sum of GRBVar variables.

 How is possible that this sum gives any value different than zero if my variables are computed as zero? 

How should I choose between QuadExpr and LinExpr? Because there is some limitation to their uses that makes my code lose readability, e.g. LinExpr= sum of variable ( is not possible if the variable has its limits defined through multiplication with another variable).

Thank you in advance.

Best regards.

関連

• C++

0

• 

  Gurobot (AI-generated response)

  • Gurobi Staff

  2024年02月27日 15:51

  First, regarding your issue with QuadExpr summing to a non-zero value when you expect zero:

  1. Variable Initialization: Ensure that all your GRBVar variables are indeed initialized to zero. If they're not explicitly set to zero, they might hold arbitrary values.

  2. Floating-Point Precision: Gurobi, like other solvers, uses floating-point arithmetic, which can sometimes lead to small numerical inaccuracies. If the sum is very close to zero but not exactly zero, this could be the reason.

  3. Model Updating: After making changes to your model (like changing variable values), ensure you call model.update() before performing operations on the variables.

  4. Code Inspection: Review your code to ensure there are no unintended assignments or modifications to the GRBVar variables involved in your QuadExpr.

  Now, regarding the choice between QuadExpr and LinExpr:

  • LinExpr: This is used for linear expressions. It's simpler and more efficient for linear constraints and objectives. Use LinExpr when your expression involves only addition or subtraction of variables and constants.

  • QuadExpr: This is used for quadratic expressions. You should use QuadExpr when your expression involves multiplication of variables (i.e., when you have quadratic terms). Note that QuadExpr can also handle linear components, so you can mix linear and quadratic terms.

  • Performance and Readability: QuadExpr generally has more overhead than LinExpr due to its capability to handle quadratic terms. If your model is purely linear, sticking with LinExpr can be more efficient. However, if you need to express any quadratic relationships, you must use QuadExpr.

  • Limitations in Expressions: If you're facing limitations in expression construction (like in your example where variable limits are defined through multiplication with another variable), you'll need to use QuadExpr since that's a quadratic operation.

  In summary, choose LinExpr for linear operations for efficiency and readability, but switch to QuadExpr when dealing with quadratic terms. If you face any specific code-related issues or limitations, feel free to share the relevant code snippets for more targeted assistance.

  0
• 

  ALESSANDRA VIEIRA

  2024年02月27日 16:39

  • 
  • 
  • 

  Hallo gurobot! 

  The question is : 

  GRBVar x;
  GRBLinExrpr b;
  GRBQuadExpr c;
  GRBLinExpr d;
  c=6*x;
  d=x+x;
  b= c+d;

  The solver does not accept, the sum of expr can be easily a LinExpr, but  I think is because the expr c is quad the solver does not accept, is true? 

  0
• 

  Gurobot (AI-generated response)

  • Gurobi Staff

  2024年02月27日 17:20

  In the code snippet you provided, the issue arises from trying to add a QuadExpr (c) to a LinExpr (d). Gurobi distinguishes between linear and quadratic expressions because they are fundamentally different in terms of the optimization problem structure.

  Here's a breakdown of your code:

  • GRBVar x; - This is a decision variable.
  • GRBQuadExpr c; - This is a quadratic expression. When you define c=6*x;, it's still considered quadratic because Gurobi treats any expression involving variables as potentially quadratic.
  • GRBLinExpr d; - This is a linear expression. d=x+x; is a simple linear expression.
  • GRBLinExpr b; - The issue occurs here. You cannot directly add a QuadExpr (c) to a LinExpr (d) and store it in a LinExpr (b), because the resulting expression could be quadratic.

  To resolve this, you can either:

  1. Treat everything as a quadratic expression if there's a possibility of having quadratic terms.
  2. Explicitly handle the expressions to ensure they are linear before assigning them to a LinExpr.

  For example, if you are sure that c will always be linear, you should rewrite your expressions or handle them in such a way that their linearity is explicit.

  Remember, the distinction is important because linear problems are generally easier and faster to solve compared to quadratic problems. So, correctly categorizing your expressions can significantly impact the performance of your solver.

  0

サインインしてコメントを残してください。