Bug in p.add_constraint ?

[Peter Mueller]

In Sage 5.3, I get the following:

sage: p = MixedIntegerLinearProgram()

sage: x = p.new_variable(integer=True)

sage: c = x[0]-x[1]

sage: p.add_constraint(10 <= c)

sage: p.show()

Maximization:

 

Constraints:

Variables:

  x_0 is an integer variable (min=0.0, max=+oo)

  x_1 is an integer variable (min=0.0, max=+oo)

Thus, the constraint was not added to p. If I however do

sage: p.add_constraint(c >= 10)

sage: p.show()

Maximization:

 

Constraints:

  R0: - x_0 + x_1 <= -10.0

Variables:

  x_0 is an integer variable (min=0.0, max=+oo)

  x_1 is an integer variable (min=0.0, max=+oo)

then things are fine.

According to the doc, this seems to be a bug. Unfortunately, this behavior produces wrong results. It took me some time to isolate the problem! Bugs which just produce error messages are much friendlier ...

-- Peter Mueller

[Nathann Cohen]

Hellooooooooooooo !!!

According to the doc, this seems to be a bug. Unfortunately, this behavior produces wrong results. It took me some time to isolate the problem! Bugs which just produce error messages are much friendlier ...

I totally agree. It has been reported before, and I definitely remember spending some time on this during the Sage days in Cernay. The thing is : I have no idea on earth how to solve this. If you want to meddle with this you have to deal with the coercion system (I have no idea how that works), and at that time I was helped by the combinat guys, who if I remember correctly thought this could be solved by categories.

I spent days on this trying to understand how the categories and coercion system worked. I have no idea on earth. This thing is a nightmare.

Of course it should be possible. But I got angry so many times because of this bug and what had to be done to solve it (I forgot all of it. That's how my memory works when something drives me crazy) that I know trying to solve it again through the same method would lead to the same result.

Here's the problem with that bug :

when you write "c <= 0", it behaves as if the operator " <= " was applied to "c", which is a MIPVariable.

No problem, I can handle that with methods in the MIPVariable class.

When "5 <=" is read, the <= operator is applied on 5. If I make no mistake, for some reason the code seems to assume that this <= operator HAS to return a True/False value, while I want it to return a symbolic expression (I want to remember what has to be inferior to what), and that seemed to be asking for too much.

- "It is reasonable to assume that <= returns True/False values, isn't it ?"

- "Well, just look at this example. In this case it is NOT reasonable, and it just prevents me from writing my code"

I definitely had this conversation with somebody at that time.

And of course, because this "5 <=" code is managed by something over which I have no power (the integers and their coercion system), I don't have any way to raise an exception either.

I definitely remember this thing as a nightmare. If I give it another try, the Combinat guys from my lab will have to hear me complain for at least one week, and it's not even sure that I will end up solving it.

And this mailing list will receive one thousand of angry emails saying "Why did somebody write a code that prevents me from writing code I need", like assuming that a <= operator applied on an integer always returns a Boolean.

Well.

Just the memories, and I am angry already. Today is not about to be a quiet day :-P

Nathann

[Volker Braun]

I'd say there are two bugs:

1) p.new_variable() should raise an error if it doesn't understand the argument, and not just silently do nothing.

2) the inequality operators should work both ways to create LinearConstraints

[Volker Braun]

And, by the way, the MIP stuff has absolutely no support for any of the Sage infrastructure. Everything just derives from object. Not even SageObject.

[Nathann Cohen]

Here's a trac ticket that -- at least -- prints a bug report.

http://trac.sagemath.org/sage_trac/ticket/13646

Nathann

[Nathann Cohen]

Hellooooooo !!

> I'd say there are two bugs:

There are always too many.

> 1) p.new_variable() should raise an error if it doesn't understand the argument, and not just silently do nothing.

Perfectly true. #13646 is meant to fix that :-)

> 2) the inequality operators should work both ways to create LinearConstraints

Yep.. Definitely :-/

Nathann

[P Purkayastha]

The earlier discussion happened here:
http://trac.sagemath.org/sage_trac/ticket/12091

Must feel good to jiggle your memory with those "fun" times ;-)

[Volker Braun]

I've added the missing parents and coercion bits in a patch at the trac ticket.

[P Purkayastha]

This is really nice. A long standing functionality. When we move to python3, the other bug can also be taken care of.

[Volker Braun]

Both bugs are fixed in the ticket's patch. In particular, this now works as it should:

    sage: x[0] <= 1

    x_0 <= 1

    sage: x[0] >= 1

    1 <= x_0

    sage: 1 <= x[0]

    1 <= x_0

    sage: 1 >= x[0]

    x_0 <= 1

[P Purkayastha]

That's only one bug as mentioned in #12091 (having numerics on the left
of a comparison operator). The other bug is the chained inequalities.

sage: x[0] <= x[1] <= 2
x_1 <= 2

This can't be fixed (I think) without moving to python3.

> --
> You received this message because you are subscribed to the Google
> Groups "sage-support" group.
> To post to this group, send email to sage-s...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-support...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-support?hl=en.
>
>

[Volker Braun]

Yes, there is another can of worms in chained comparisons. So far I've implemented parents for LinearFunction, but there should be a parent for LinearConstraint as well. I'm pretty sure your example can be fixed by overriding __nonzero__.