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.