Hi Emmanuel, On 2012-12-22, Emmanuel Charpentier <emanuel.charpent...@gmail.com> wrote: >> You mean: *python's* add was designed in that way.=20 >> > > OK. That does not change much my reasoning, as far as I know|understand.=20
IMHO, it changes a lot. See below. >> * Comparison of symbolic expressions by <, > or cmp really does not=20 >> make much sense before inserting values to the variables.=20 >> > > I beg to disagree : when any of the arguments to a comparison function is a= > symbolic expression, the function should return a symbolic expression., And= > I think of such a result as a "straight answer". Call it "straight" or "not straight". But if you need a truth value (and you *do* need a truth value when you want to program something with "if <condition> then <do something>") then you *have* to decide whether you treat the mathematically correct answer "unkown" or "not provably true" as "False" or "True". >> * Python's max or min functions makes no sense if cmp can't give a=20 >> straight answer.=20 >> > > I think that's where we disagree... Perhaps. But you seem to suggest that computer algebra systems should create their own programming language. I think William Stein made a very wise decision, namely to use a mainstream programming language for Sage: Python. Sage does change some details in Python's syntax (e.g., the ^ operator has a different meaning in Sage than in Python), but it would be a bad idea to replace fast builtin Python functions by slow functions only useful for a part of Sage users. And this is why it changes a lot. Sage developers try to avoid re-inventing the wheel. >> Python's max/min does not delay. > > > That's part of the design flaw I alluded to. I couldn't disagree more. The idea to re-use stuff that many experts have improved over the years -- Python, maxima, R, GAP, Singular, nearly 100 systems in total -- is the *strength* in Sage's design. > Hence the need to use a polymorphism, returning either a boolean (when the= > max/min can be computed) or a symbolic expression. ... and that's exactly what max_symbolic does. Except that it isn't as easy as it sounds: > What would be that cost ? method dispatching ? I other words, what induced= > Python's creator to accept this price for the addition, but not for the=20 > comparison ? I have already told you that method dispatching is not the problem here. *Both* addition and comparison dispatch to methods. Addition dispatches to __add__, comparison dispatches to __cmp__, __eq__ and some other methods. Please consult the Python documentation. It seems to me that the main cost of max_symbolic comes from automatic simplifications of the input. Just look at this example: sage: max_symbolic(0,-1,x) max(x, 0) You see? It realises that -1 can not be maximal, because 0 is guaranteed to be larger. I guess that this additional feature is what makes it slow. If you have an idea to improve the speed of max_symbolic, you are welcome to provide a patch. Best regards, Simon () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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.
