"Bill Page" <[EMAIL PROTECTED]> writes:
> If we allow (2*x+1/x)::DMP([x], EXPR INT), i.e., allowing 1/x as a
> coefficient, then it must be clear that the "x" in 1/x is something
> different than the "x" in 2*x. Otherwise we don't get a polynomial,
> obviously.
>
> Martin,
> On February 22, 2006 3:54 AM you wrote:
> > I think this is wrong. In fact, it is clear from the implementation of Axiom
> > that whether the 'x' in these two cases is the same or not depends on which
> > domain to which they belong.
Any scientific literate person, when (s)he wrote down:
2*x + 1/x
would mean that there is only ONE x, the x means the same thing throughout the
expression. So
(1) -> (2*x+1/x)::DMP([x], EXPR INT)
2
2x + 1
(1) -------
x
Type: DistributedMultivariatePolynomial([x],Expression Integer)
(2) -> degree(%)
(6) [0]
is perfectly correctly interpreted by Axiom. The entire expression is a
coefficient, in EXPR INT. If you )set mess bot on, you'll see that Axiom
actually computes all this in FRAC POLY INT!
However, I think Axiom is wrong in allowing that, since x, being an
indeterminate over EXPR INT, should not be in EXPR INT. The coercion should
simply fail, or end up in FRAC DMP([x], EXPR INT).
Note that even if the following is used, Axiom continues to "retract" the x from
1/x to EXPR INT. This is simply wrong.
x:DMP([x], EXPR INT):=x
2*x + 1/x
degree(%)
[1]
On the other hand, the following is correct, and should be the case no matter
what the coefficient domain is.
y:DMP([y], INT):=y
2*y+1/y
2
2y + 1
-------
y
Type: Fraction DistributedMultivariatePolynomial([y],Integer)
The two cases should not be handled differently.
If a user wants to push the result down to the coefficient domain, it should be
done with a substitution map, explicitly, and the user should not use x in EXPR
INT.
William
_______________________________________________
Axiom-developer mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/axiom-developer
