#16721: implement gcd(a,b,hold=True)
-------------------------------+------------------------
Reporter: rws | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.3
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps: todo
-------------------------------+------------------------
Comment (by nbruin):
Replying to [comment:18 rws]:
> I do not understand. In what way is this different from
> {{{
> sum(sin(n*pi,hold=True),n,1,5,hold=True)
> ...
> TypeError: symbolic_sum() got an unexpected keyword argument 'hold'
> }}}
> which simply does not work, and from which one usually comes to this:
> {{{
> sage: sum(sin(n*pi,hold=True) for n in range(1,6))
> sin(pi) + sin(5*pi) + sin(4*pi) + sin(3*pi) + sin(2*pi)
> }}}
The problem is that "hold" semantics aren't well-defined, so you'd better
make sure that for "held" expressions, the answers aren't wildly different
depending on when the "hold" is lifted. Never mind that "hold" isn't
implemented for sums. You can usually get an implicit hold by doing
something like
{{{
f(N)=sum(...,n,1,N)
}}}
and with that transform you see that your suggested iterator expression is
NOT the same:
{{{
sage: var("t,T")
(t, T)
sage: sum(sin(t*pi,hold=True),t,1,T)
0
}}}
The hold apparently gets lifted by "sum" already (because our "hold"
doesn't get translated to maxima, perhaps because a corresponding notion
doesn't exist for sine there) and apparently, sum simplifies the
expression under the assumption that t is an integer.
That's why I think "hold" is not an appropriate mechanism for a wildly
non-continuous function such as "gcd". It's meant to be a manipulation on
(polynomial) expressions, not a symbolic function. I don't think SR is
equipped to handle operations like that "symbolically".
I know systems like maple and mathematica tend to not make a distinction
between "operations" and "symbolic expressions", allowing deferred
evaluation on pretty much anything, and in my experience predictability
and debuggability of code suffers from it.
Nothing prevents you from defining `function("completely_inert_gcd")` and
writing expressions with that. The problem arises when you start trying to
use simplification/evaluation rules on this expression. Normally, you'd
from the inside to the outside; for your sum example you'd need it from
the outside to the inside. We can't really have both if we don't have a
way to indicate which method to use where.
--
Ticket URL: <http://trac.sagemath.org/ticket/16721#comment:19>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
