axiom-developer
[Top][All Lists]

## [Axiom-developer] [#270 integrating UTS] 1/x x = 1 is a bug!

 From: wyscc Subject: [Axiom-developer] [#270 integrating UTS] 1/x x = 1 is a bug! Date: Thu, 23 Feb 2006 01:08:00 -0600

Changes http://wiki.axiom-developer.org/270IntegratingUTS/diff
--
I think recently this issue of using the same 'identifier' 'x' to stand for two
different 'variables' in two different domains (either accidentally or on
purpose) has been thoroughly discussed, but not quite. Note that I distinguish
'identifier' from 'variable'. We have two variables, usually one internally
denoted by the 'Symbol' 'x' and another unspecified as ? (as in 'UP(x,INT)')
where ? does NOT exist but can either be printed as ? or any identifier the
user prefers, such as 'x'. As any one who does programming should know, the
same 'identifier' should never be used to denote two different objects (at
least not within the same scope). By the way, this design is in some sense
ingenious, and necessary, to allow extending a polynomial ring that already has
all the symbols as variables; such extension is useful in testing radical ideal
membership of polynomial rings, and intersections of polynomial ideals, for
example.

In creating 'integrate((1/x)::ULS(FRAC POLY INT, x, 0),x)', the user erred by
combining two operations into one and thus allowing, actually forcing, Axiom's
Interpreter to firstly misidentify the first 'x' encountered during scan as
belonging to 'FRAC POLY INT' when the user meant it to be in 'ULS(FRAC POLY
INT, x, 0)' and then secondly it is forced to coerce the result '1/x' to be a
coefficient in 'ULS(FRAC POLY INT,x,0)' by the user. Once satisfied that the
result is in 'ULS(FRAC POLY INT, x, 0)', there is no need to do anything
further but to start processing the 'integrate' command.

Instead, the user should have separated the two operations:

\begin{axiom}
f:ULS(FRAC POLY INT, x,0):=1/x
integrate(f,x)
\end{axiom}

Three things should be noted here: (a) 'x' is first encountered in 'ULS(FRAC
POLY INT, x,0)' which creates an 'identifier' 'x' for the main variable ? in
the 'ULS' domain. (b) In the first line, having bound 'x' to the main variable,
'1/x' is now treated as a Laurent series (not as a coefficient living in 'FRAC
POLY INT'), but it is not apparent to the inexperienced user in the output (but
it is different, as seen below).
(c) In the second line, Axiom fails (correctly) because the integral, which is
'log(x)', which is not given by a Laurent series about 'x=0'. A better example
is:

\begin{axiom}
g:ULS(FRAC POLY INT, x,0):=1/(x-1)
integrate(g,x)
\end{axiom}

Here Axiom actually expands '1/(x-1)' in a series in powers of 'x'. Compared
this with:

\begin{axiom}
h:=(1/(x-1))::ULS(FRAC POLY INT, x,0)
integrate(h,x)
\end{axiom}

Now Axiom having been forced to output the same identifier for two different
variables, the first 'x' bound to a variable in 'FRAC POLY INT', and the second
'x' bound to the main variable of 'ULS', should NOT then simplify the
expression '1/x x' of (3) to '1'. This is unfortunately a consequence of the
design goal to permit elements of 'UP(x,R)' to be coercible to 'POLY R' where
the main variable is coerced into the variable using the identifier 'x'. In our
case, 'ULS(R,x,0)' was first truncated to 'UP(x,R)' (using
'univariatePolynoimial') by identifying the main variable of 'ULS' with the
main variable of 'UP(x,R)'. Here 'R' IS 'FRAC POLY INT', and 'UP(x, FRAC POLY
INT)' is first coerced into 'FRAC UP(x, POLY INT)' and then further to 'FRAC
POLY INT' via 'UP(x, POLY INT)' to 'POLY INT' (from 'map' from 'FRAC2(UP(x,
POLY INT),POLY INT)' and the Interpreter probably simplified 'POLY POLY INT' to
'POLY INT'). In other words, we have '((1/x ?)::(?/x)::(x/x)=1'.  The 'bug'
there!
fore probably lies in the identification of 'POLY POLY INT' with 'POLY INT'
where the outer ? (or 'x') is identified with 'x' of the inner 'POLY'.

Conclusion: (i) Any simplification of towers which makes sense in mathematics
probably would not make sense in computer algebra (due to scope problems for
one). Other examples could be 'FRAC FRAC INT' to 'FRAC INT' and 'EXPR EXPR INT'
to 'EXPR INT'. (ii) Users should be alert to the order in which an input is
scanned and the consequences, and break a long input into simpler steps. (iii)
Users should not use the same identifier for two different objects.

William
--