Skip to main content

File "src\gurobipy\quadexpr.pxi", line 45, in gurobipy.QuadExpr.__init__ File "src\gurobipy\linexpr.pxi", line 46, in gurobipy.LinExpr.__init__ IndexError: string index out of range

Answered

Comments

7 comments

  • Jonasz Staszek
    Community Moderator Community Moderator
    Gurobi-versary
    Thought Leader
    First Question

    Hi Heena,

    based on the code snippet you shared it is difficult to figure out what could be going wrong. Could you please share a minimal reproducible example?

    The error itself to me would suggest to me that you are trying to access a character in a string using an index that does not exist (usually assumes a bigger value than the length of this string). But - as mentioned above - without more context, I am unable to guide you further.

    From afar, it also seems to me that your inputs to QuadExpr() are somewhat strange. You would normally pass in a constant, a variable, or another LinExpr or QuadExpr - see the documentation for a thorough discussion.

    Best regards
    Jonasz

     

    0
  • Jaromił Najman
    Gurobi Staff Gurobi Staff

    Hi Heena,

    In addition to what Jonasz already correctly pointed out, it looks like you are trying to construct a QuadExpr object from a string. This is not possible. You have to use Var objects. As an example

    expr = QuadExpr("2*x")

    does not work and results in the error you mention in the title of this post.

    To model \(2\cdot x\), you have to first define \(x\) as an optimization variable and then pass \(2\cdot x\) to the QuadExpr constructor

    m    = Model("test")
    x = m.addVar()
    expr = QuadExpr(2*x)

    To get a better grasp of Gurobi's Python API, I recommend to have a look at our Python Webinars and Python examples.

    Best regards, 
    Jaromił

    0
  • Heena Jain
    Gurobi-versary
    First Comment
    First Question

    Hi Jonasz and Jaromil,

    Thank you for your responses. Firstly, here is a reproducible example:

    from gurobipy import *
    from gurobipy import GRB
    lm = Model("lm")
    expr = '1253.8051344 - 654.268051728*lambd'
    lm.addVar(vtype = GRB.CONTINUOUS, name = "lambd")
    lm.update()
    expr = QuadExpr(expr)
    lm.setObjective(expr, GRB.MINIMIZE)
    lm.addConstr(lambd <= lambdamax)
    lm.addConstr(lambd >= 0)
    lm.update()

    I understand that the usage of QuadExpr is incorrect. It was basically a desperate attempt to fix this other issue while trying to set the objective function. This is the error I get "line 259, in <module>
        lm.setObjective(expr, GRB.MINIMIZE)
      File "src\gurobipy\model.pxi", line 1411, in gurobipy.Model.setObjective
      File "src\gurobipy\exprutil.pxi", line 28, in gurobipy.__simpleexpr
    gurobipy.GurobiError: Unable to convert argument to an expression" when trying to run this:

    from gurobipy import *
    from gurobipy import GRB
    lm = Model("lm")
    expr = '1253.8051344 - 654.268051728*lambd'
    lm.addVar(vtype = GRB.CONTINUOUS, name = "lambd")
    lm.update()
    lm.setObjective(expr, GRB.MINIMIZE)
    lm.addConstr(lambd <= lambdamax)
    lm.addConstr(lambd >= 0)
    lm.update()

    The error generates while setting the objective function in both cases. This line 'expr = QuadExpr(expr)' itself worked fine because there was no error about wrong input type. Please let me know if that is how it is supposed to be. Also, the reason I have to use an expression while setting an objective function is that my objective expression changes in each iteration. So, I thought the best way would be to keep passing this updated expression.

    0
  • Jaromił Najman
    Gurobi Staff Gurobi Staff

    Hi Heena,

    You are using a string as input for an expression object in the setObjective method. This is not possible in Gurobi. You have to construct your expressions using Var objects. For your particular example, you could do it via

    from gurobipy import *
    from gurobipy import GRB
    lm = Model("lm")
    # add an optimization variable called lambd to model lm
    # you can now use object lambd as an optimization variable
    # in your constraint/objective expressions
    lambd = lm.addVar(vtype = GRB.CONTINUOUS, name = "lambd")
    lm.setObjective(1253.8051344 - 654.268051728*lambd, GRB.MINIMIZE)
    lm.addConstr(lambd <= lambdamax)
    lm.addConstr(lambd >= 0)

    For more information on how to properly construct a model in Gurobi's Python API I strongly recommend to have a look at our Python Webinars and Python examples.

    Best regards, 
    Jaromił

    0
  • Heena Jain
    Gurobi-versary
    First Comment
    First Question

    Hi Jaromil,

    I appreciate your input. I have been through the examples and some webinars also. My query though is that the objective function doesn't remain same for me. It keeps changing with every iteration. So, I need to understand how to incorporate this. For example, if

    1253.8051344 - 654.268051728*lambd

    was the objective expression in first iteration, then the second may have an objective expression like this:

    9.00946076159322e-6*lmd**2 - 0.00242412398198366*lmd + 997.395132906327
    0
  • Jonasz Staszek
    Community Moderator Community Moderator
    Gurobi-versary
    Thought Leader
    First Question

    Hi Heena,

    assuming that both lmd and lambd are properly defined as Gurobi variables you can set your first objective exactly the way Jaromił did in the previous post:

    lm.setObjective(1253.8051344 - 654.268051728*lambd, GRB.MINIMIZE)


    and the second one in the following way:

    lm.setObjective((9.00946076159322e-6)*lmd*lmd - 0.00242412398198366*lmd + 997.395132906327, GRB.MINIMIZE)

    On a side note, 9.00946076159322e-6 is a very small number, a few orders of magnitude smaller than the other coefficients in the objective. Is this something you would expect? Perhaps Gurobi staff can comment on whether this could lead to numeric issues?

    Best regards
    Jonasz

    0
  • Jaromił Najman
    Gurobi Staff Gurobi Staff

    On a side note, 9.00946076159322e-6 is a very small number, a few orders of magnitude smaller than the other coefficients in the objective. Is this something you would expect? Perhaps Gurobi staff can comment on whether this could lead to numeric issues?

    In most cases, this should not be a problem. However, Jonasz' concern is correct and if you have a possibility to re-scale the coefficients by, e.g., changing the unit for variable \(\texttt{lmd}\), I would definitely recommend to do so. For more details you can have a look at our Guidelines for Numerical Issues.

    Best regards, 
    Jaromił

    0

Please sign in to leave a comment.