[Axiom-developer] [DistributedMultivariatePolynomial] These examples are wrong and due to user and Interpreter errors.

[wyscc]

Changes http://wiki.axiom-developer.org/DistributedMultivariatePolynomial/diff
--
The fact that one can "explain" what the Axiom's Interpreter does to an input 
does not make its operation legitimate.  Even though 'EXPR INT' (and similarly 
'POLY INT') is designed to include 'Symbol' (that means *all* symbols 
corresponding to all legal identifiers, including those decorated with 
subscripts or superscripts), it is never the intention that no other symbols 
can be used *outside* of 'EXPR INT' or 'POLY INT'.  That is why it is legal to 
construct 'DMP([x,y], EXPR INT)' in the above examples. However, in 
mathematics, a polynomial ring $P$ over a coefficient domain $R$ in the 
variables $[x,y]$, say, means that $x,y$ are indeterminates and therefore are 
algebraically independent over $R$. In particular, $x,y$ **cannot** be elements 
of $R$.

The above examples, such as $x+x$, where the two $x$'s have to be 
differentiated as belonging to two different domains is nonsense. Any 
scientific literate user who writes $x+x$ intend the expression to simplify to 
$2x$ because the $x$ **MUST** represent the *same* mathematical quantity. 
Axiom's Interpreter, in producing $x+x$ in the examples, violates this 
universally accepted convention and the definition of indeterminates. These 
violations are **not acceptable**.

In short, the error occurs because the Interpreter, unaware of the definition 
of indeterminates, "coerces" $x$ from $P$ to $R$, but there is *no* 'coerce' 
function with signature 'P -> R' even when 'R' is 'EXPR INT' or 'POLY INT'. The 
situation for 'EXPR INT' is harder to investigate since 'EXPR INT' is 
implemented as the quotient field of a polynomial ring. So rational functions 
are easily coerced into 'EXPR INT' and the Interpreter will not spit out 
information on how it does this even with ')set mess bot on'. For the 'POLY 
INT' case, a careful examination (see 
http://wiki.axiom-developer.org/270IntegratingUTS) shows that it actually 
invokes a *substitution* of $x$ in $P$ (I'll label this $x_P$) by replacing it 
with another $x$ in $R$ (I'll label this $x_R$). Substitutions are perfectly 
legal operations, but the Interpreter should not substitute for one $x_P$ and 
not another. This happened in the computation of 'b' above. The division 'a/x' 
is taken with signature '/:(P,R)!
->P' because 'R' is a field, but in doing so, the Interpreter selectively 
*substitute* (under the mask of *coerce*) the denominator $x_P$ (actually, 
here, it is probably an 'x' in 'POLY INT' coerced into $x_R$ because 'x' has 
not been defined except as a 'Symbol', but I will assume that 'x' has been 
defined as in 'x:P:=x' so that the denominator in 'b=a/x' is undoubtedly $x_P$) 
but not the numerator 'a'. So the two $x$'s in 'a/x' are treated as different 
(first violation) and then one $x_P$' is allowed to be pushed down into the 
coefficient domain 'R' even though it is transcendental over 'R' (second 
violation).

Unfortunately, these bugs are difficult to correct. The Interpreter was 
designed to faciliate conversions among any two polynomial rings and their 
quotient fields. Had the above 'coerce' been from 'DMP([x,y], R)' to 'FRAC 
DMP([x,y], R)' (the correct coercion) or even 'EXPR R', things would have been 
ok. But the designers wrongly disallowed construction of 'EXPR EXPR INT' and 
similar towers. The correct fix should therefore be coercion to 'FRAC 
DMP([x,y], R' no matter what 'R' is. This is consistent with mathematics, since 
if $a \in P$ when $P$ is an integral domain, then $1/a$ should be in the 
quotient field of $P$. The examples below illustrate these incorrect and 
correct approaches.

\begin{axiom}
S:=FRAC POLY INT
Q:=DMP([x], S)
a:Q:=x
)set mess bot on
b:Q:=a/a
\end{axiom}


The last output from the ')set mess bot on' output::

 [1]  signature:   ((DMP([x],POLY INT) -> POLY INT),FRAC DMP([x],POLY INT)) -> 
FRAC POLY INT
      implemented: slot (Fraction (Polynomial (Integer)))(Mapping (Polynomial 
(Integer))      
      (DistributedMultivariatePolynomial (x) (Polynomial (Integer))))
      (Fraction (DistributedMultivariatePolynomial (x) (Polynomial (Integer)))) 
      from FRAC2(DMP([x],POLY INT),POLY INT)

shows clearly (this is a much simplified version of what actually is done, 
which involves 4 "coercions") that the coercion from 'DMP([x], FRAC POLY INT)' 
to "FRAC POLY INT' for the denominator 'a' is really a substitution, 
implemented using the 'map' function from 'FRAC2' package, taking $1/x_Q$ to 
$1/x_S$ via the substitution $x_Q$ to $x_S$.  If we replace 'S' by 'POLY INT', 
the coercion would be simpler, but then 'S' is not a field.

\begin{axiom}
)clear all
S:=POLY INT
Q:=DMP([x], S)
a:Q:=x
)set mess bot on
b:Q:=a/a
\end{axiom}

Surprise! The difference in the value of 'b' just because the coefficient ring 
was changed is not acceptable, but at least in this case, the answer and indeed 
the coercions are correct. Had the other cases used the same coercion into the 
quotient field of 'P' (or 'Q'), they would be correct too. Now have fun with 
the quizzes in SandBoxPolynomials.

William
--
forwarded from http://wiki.axiom-developer.org/address@hidden