axiom-developer
[Top][All Lists]

[Axiom-developer] [DistributedMultivariatePolynomial] These examples are

 From: wyscc Subject: [Axiom-developer] [DistributedMultivariatePolynomial] These examples are wrong and due to user and Interpreter errors. Date: Sun, 26 Feb 2006 04:09:27 -0600

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
--