#6482: multivariate polynomial substitution has a design flaw
---------------------------------+------------------------------------------
Reporter: was | Owner: malb
Type: defect | Status: new
Priority: critical | Milestone: sage-4.1.1
Component: commutative algebra | Keywords:
Reviewer: | Author:
Merged: |
---------------------------------+------------------------------------------
{{{
On Wed, Jul 8, 2009 at 1:28 AM, Kwankyu<...> wrote:
>
> Hi,
>
> I was surprised to see
>
> sage: R.<x,y>=QQ[]
> sage: g=x+y
> sage: g.subs({x:x+1,y:x*y})
> x*y + x + y + 1
>
> So the order of substitution matters...unfortunately.
>
> sage: g.subs({x:x+1}).subs({y:x*y})
> x*y + x + 1
> sage: g.subs({y:x*y}).subs({x:x+1})
> x*y + x + y + 1
>
> So the order seems to be from right to left. This seems to me
> unnatural. Anyway this is undocumented.
Actually, i guess it is documented. However, I consider it a serious
design flaw.
Many thanks for pointing this out!!
I consider this a serious design flaw for the following reasons:
(1) it is too hard to understand the above behavior, since it depends on
the hash values symbolic variables, which might possibly be system-
dependent.
(2) it is totally inconsistent with the behavior for symbolic
expressions, where things are done right.
(3) it is totally inconsistent with the behavior of *homomorphisms*,
where things are also done right.
Here is a session to illustrate the above points:
# BAD
sage: R.<x,y>=QQ[]
sage: g=x+y
sage: g.subs({x:x+1,y:x*y})
x*y + x + y + 1
# BAD
sage: R.<x,y>=QQ[]
sage: g=x+y
sage: g.subs(x=x+1,y=x*y)
x*y + x + y + 1
# GOOD
sage: R.<x,y>=QQ[]
sage: phi = R.hom([x+1,x*y])
sage: g=x+y
sage: phi(g)
x*y + x + 1
# GOOD
sage: var('x,y')
sage: g = x+y
sage: g.subs({x:x+1,y:x*y})
x*y + x + 1
# GOOD
sage: var('x,y')
sage: g = x+y
sage: g.subs(x=x+1,y=x*y)
x*y + x + 1
> What should be done to this?
1. I suggest that for now you use Hom, as illustrated above, as a
workaround.
2. I think subs should be reimplemented using Hom ASAP. Note that this
could break existing code, so will have to be done carefully. We can
leave the old behavior in for speed, but as a non-default option.
3. Come up with a fast way to implement the new behavior.
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6482>
Sage <http://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 post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
