Update of bug #10530 (project axiom):
Status: None => transferred
fricas
gcd((x-2^a)::UP(x, EXPR INT), simplify((x-2^a)*(x+2^a))::UP(x, EXPR INT))
Type: UnivariatePolynomial
?(x,
Expression(Integer))
Gives 1, while the correct answer should be , as given by
fricas
gcd((x-2^a)::UP(x, EXPR INT),((x-2^a)*(x+2^a))::UP(x, EXPR INT))
Type: UnivariatePolynomial
?(x,
Expression(Integer))
Internal Cause
In EXPR INT, and are treated as two variables
without relations in EXPR INT. But
fricas
simplify((x-2^a)*(x+2^a))::UP(x, EXPR INT)
Type: UnivariatePolynomial
?(x,
Expression(Integer))
Therefore exquo in:
exquo(simplify((x-2^a)*(x+2^a))::UP(x,EXPR INT),(x-2^a)::UP(x,EXPR INT))
fails. In details, it calls exquo$UP(x,EXPR INT)
. This implements exact division of
polynomials p1 by p2 as usual. After each subtraction - done via
fmecg$UP
- the result is again stored in p1. exquo terminates
when p1 is the empty list - note that UPs? are stored as lists
of pairs (degree, coefficient) - or the degree of p2 is larger
than p1. In the latter case, exquo fails.
Thus, in our case, at one point p1 is , which is zero
mathematically, but FriCAS? does not know it. In particular,
p1 is not the empty list, but rather a constant polynomial...
To get correct result we need to express coefficients of p1 and p2
in terms of independent kernels.
Wed 09/29/2004 at 16:02, comment #1:
I should have added:
fricas
exquo(normalize(simplify(((A-2^a)*(A+2^a)))::EXPR INT),normalize((A-2^a)::EXPR INT))
Type: Union(Expression(Integer),...)
fricas
exquo(simplify((A-2^a)*(A+2^a))::UP(A,EXPR INT),(A-2^a)::UP(A,EXPR INT))
Type: Union("failed",...)
I'm afraid that this cannot be fixed easily, since there is no
general mechanism to determine whether an expression is zero or not,
which is needed in exquo. The instance of exquo involved is the
one in SUP.
The problem seems to be that Axiom does not always treat
the same as
.
fricas
dom:=UP('x,EXPR INT)
Type: Type
fricas
p:dom:=x-2^a
Type: UnivariatePolynomial
?(x,
Expression(Integer))
fricas
q:=(x-2^a)*(x+2^a)
Type: Expression(Integer)
fricas
qq:= simplify(q)
Type: Expression(Integer)
fricas
r:= q::dom
Type: UnivariatePolynomial
?(x,
Expression(Integer))
fricas
rr:= qq::dom
Type: UnivariatePolynomial
?(x,
Expression(Integer))
fricas
gcd(p,q)
Type: UnivariatePolynomial
?(x,
Expression(Integer))
fricas
exquo(q,p)
Type: Union(Expression(Integer),...)
fricas
gcd(p,r)
Type: UnivariatePolynomial
?(x,
Expression(Integer))
fricas
gcd(p,qq)
Type: UnivariatePolynomial
?(x,
Expression(Integer))
fricas
gcd(p,rr)
Type: UnivariatePolynomial
?(x,
Expression(Integer))
fricas
q - qq
Type: Expression(Integer)
fricas
simplify q - qq
Type: Expression(Integer)
fricas
simplify ((r - rr)::EXPR INT)
Type: Expression(Integer)
fricas
t:Boolean:=(r = rr)
Type: Boolean
Comments from wyscc:
Martin wrote:
I'm afraid that this cannot be fixed easily, since there is no
general mechanism to determine whether an expression is zero or not,
which is needed in exquo.
Your analysis seems to be the correct diagnosis. The problem has nothing to do with gcd
or exquo
, but with the fact that simplification is an art as there is no canonical form for expressions and hence no way to test equality (which is in general different from testing zero, a special case needed for exquo
). More frequent use of simplification will help but will not eliminate the problem. Here, it is because the expressions and are not handled by an automatic simplification in UP(x, R)
(that is, not pushed down to the level of R
).
Category: => Axiom Compiler
Severity: => serious
Status: => open
Category: Axiom Compiler => Axiom Library