Dear Simon,
Thank you for that prompt answer.
I have a couple of comments below :
Le samedi 22 décembre 2012 13:18:32 UTC+1, Simon King a écrit :
>
> Hi Emmanuel,
>
> On 2012-12-22, Emmanuel Charpentier <emanuel.c...@gmail.com <javascript:>>
> wrote:
> > So, if I follow you, Sage's add was designed from the start to be=20
> > overloaded by class methods,
>
> You mean: *python's* add was designed in that way.
>
OK. That does not change much my reasoning, as far as I know|understand.
>
> > As for the performance : class matching and method dispatching would
> occur=
> > every time a hypothetical max method would be used, and this is
> considered=
> > bad performance-wise. May I note that fundamentally identical class=20
> > matching and method dispatching occurs every time one uses '+'
>
> No, you misunderstood. Python's max and min functions certainly dispatch
> to comparison methods of the classes, in order to find out what instance
> is biggest/smallest. That's not the problem.
>
> The problem is that you won't (and can't) get a straight answer out of a
> pair of symbolic expressions if you ask "which of you two is bigger":
>
> sage: x>1 # Note: The result is a symbolic expression!
> x > 1
> sage: type(x>1)
> <type 'sage.symbolic.expression.Expression'>
>
> sage: bool(x>1) # try to evaluate - but hang on, we don't know x!
> False
> sage: bool(1>x)
> False
>
> Warning : tangential diversion ahead :
Here, I may have another peeve about bool() being the only function to
compare truth values. It reflects an algoithmic point of view, not a
mathematic oint of view. To make things clearer : Maxima's is() function
can return either, true, false or unknown, the first one meaning 'the
argument is demonstrably true in the current state of the program", the
second meaning 'the argument is demonstrably false in the current state of
the program", the last meaning "the logical value of the argument is not
unequivocally assessable in the current state of the program". Sage's
bool() does not distinguish the latter two cases, qhich is a pity :Sage's
((!bool("something")) and (!bool("not something")) is not necessarily
equivalent to Maxima's "unknown" value for is().
In other words, Sage works under a heavy "closed world" assumption (a bit
"à la Prolog").
But this problem is known as difficult, and I need to think more about it.
Furthermore, it is not relevant to the current "max" problem. So, without
further ado :
> In other words:
> * Comparison of symbolic expressions by <, > or cmp really does not
> make much sense before inserting values to the variables.
>
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".
> * Python's max or min functions makes no sense if cmp can't give a
> straight answer.
>
I think that's where we disagree...
> * In your integral example, what you really want is that the comparison
> in the max function is delayed until values are inserted for all
> variables.
Nope. I want to insert the *symbolic expression* (i. e. a
callable|evaluable object) inserted in place.
> Python's max/min does not delay.
That's part of the design flaw I alluded to.
> Hence, one would need to
> replace it by a function that does delayed evaluation *for symbolic
> expressions only*.
>
Hence the need to use a polymorphism, returning either a boolean (when the
max/min can be computed) or a symbolic expression.
* The price to pay for replacing Python's min/max is a serious regression
> for everything that is not a symbolic expression. I, for one, would
> not be willing to pay that price.
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
comparison ?
> Hence, better have a special
> function (namely max_symbolic) for that special purpose.
>
> But if you use "max" only in integrals, then max's speed on integers
> won't matter for you (even though it would matter for others!). Hence,
> if you like, you can easily customise it by defining
> max = max_symbolic
>
> Note that max_symbolic appears to work on non-symbolic input:
> sage: max(range(5))
> 4
>
> Nevertheless, such customisation is inappropriate for general
> applications,
Hearttily agreed (for many reasons) !
> because one gets the following regression:
> sage: L = range(100)
> sage: %timeit a=max_symbolic(L)
> 625 loops, best of 3: 352 µs per loop
> sage: %timeit a=max(L)
> 625 loops, best of 3: 4.03 µs per loop
>
Just tells us that max_symbolic's handling of non-symbolic expressions case
has poor performance.
The real question (for which I have no answer now) is : How much worse
would an (hypothetical) max (set of) method(s) perform compared to the
current max Python function ? Can this be paralleled to the question : How
much better would an hyothetical Python add function perform compared to
the current Python add (set of) methods) ?
In other words : what differs between the methods/function tradeoffs
between the "add" case and the "max" case : what does tip the scale
differently in those two cases ? In yet other words : what didPyton
creators had in mind ?
>
> Best regards,
> Simon
>
>
Sincerely,
Emmanuel Charpentier
--
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.
