New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multivariate polynomial substitution has a design flaw #6482
Comments
comment:1
the main use-case for which I wrote it is (which must be fast):
The performance for elements in R is:
However, to my surprise
Is it because it caches or is really just better code? |
comment:2
Hom is implemented by Singular when the base ring is a singular ring.
|
comment:3
So it is It seems the most straight-forward implementation possible including the comment
|
comment:5
Attachment: fix_mpoly_subs.patch.gz Performance sage: P.<a,b,c,d,e> = PolynomialRing(QQ)
sage: f = P.random_element(degree=3,terms=50)
sage: g = {a:b,b:c,c:d,d:e,e:a}
sage: %timeit f.subs(g)
1000 loops, best of 3: 271 µs per loop sage: phi = P.hom([b,c,d,e,a])
sage: %timeit phi(f)
1000 loops, best of 3: 939 µs per loop sage: phi(f)
-a^2*b - 11/2*b^3 - 8*a^2*c + 1/51*b*c^2 + 1/2*c^3 - a^2*d + 1/3*a*b*d - 2/11*a*c*d + 195*b*c*d + 1/3*a*d^2 + 2*b*d^2 - c*d^2 - 2/3*a^2*e + 1/2*a*b*e - 203*b^2*e + 1/4*a*c*e + b*c*e - 5*c^2*e + 6*a*e^2 + b*e^2 - 1/3*c*e^2 - 5*d*e^2 + 3*e^3 + 1/3*a^2 - a*b - 7/48*a*c - 2*b*c - 53/2*c^2 - 1/3*a*d - 1/2*b*d + c*d - d^2 - a*e - 4*b*e - d*e + 13*e^2 - 2*a - 1/2*b - c + 9/2*d - 1/2
sage: f.sub
f.sub_m_mul_q f.subs f.substitute
sage: f.subs(g)
-a^2*b - 11/2*b^3 - 8*a^2*c + 1/51*b*c^2 + 1/2*c^3 - a^2*d + 1/3*a*b*d - 2/11*a*c*d + 195*b*c*d + 1/3*a*d^2 + 2*b*d^2 - c*d^2 - 2/3*a^2*e + 1/2*a*b*e - 203*b^2*e + 1/4*a*c*e + b*c*e - 5*c^2*e + 6*a*e^2 + b*e^2 - 1/3*c*e^2 - 5*d*e^2 + 3*e^3 + 1/3*a^2 - a*b - 7/48*a*c - 2*b*c - 53/2*c^2 - 1/3*a*d - 1/2*b*d + c*d - d^2 - a*e - 4*b*e - d*e + 13*e^2 - 2*a - 1/2*b - c + 9/2*d - 1/2 |
comment:6
Note that since dictionaries do not preserve order, in python, there is no way to distinguish between Note that this also means that there is no distinction between these calls: |
comment:7
To emphasize the point, here is the result after applying the patch:
Note that things are not in order in the second example. I think this is probably hopeless as stated. If the substitutions were given as a list of tuples, then you could depend on the order. In other words, if you had something like |
comment:8
It never even occurred to me that one could want to substitute in the order of the dictionary, so this is not what I tried to provide. 'ordered' to me only means 'by variables'. To me, the second example is in order but it might be a good idea to add a note to the docstring to clarify the behaviour. |
comment:9
I think that this patch should get a positive review. The behavior after the patch is the correct behavior and is consistent with the rest of Sage. I think Jason just misinterpreted what the ticket was for. |
Reviewer: Mike Hansen |
Author: Martin Albrecht |
Merged: sage-4.2.alpha0 |
Component: commutative algebra
Author: Martin Albrecht
Reviewer: Mike Hansen
Merged: sage-4.2.alpha0
Issue created by migration from https://trac.sagemath.org/ticket/6482
The text was updated successfully, but these errors were encountered: