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

-- 
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.


Reply via email to