On 10/23/2012 05:26 PM, Nathann Cohen wrote:
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
The earlier discussion happened here: http://trac.sagemath.org/sage_trac/ticket/12091 Must feel good to jiggle your memory with those "fun" times ;-) -- You received this message because you are subscribed to the Google Groups "sage-support" group. To post to this group, send email to sage-support@googlegroups.com. To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support?hl=en.
