[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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

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 

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:

f:ULS(FRAC POLY INT, x,0):=1/x

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 

g:ULS(FRAC POLY INT, x,0):=1/(x-1)

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

h:=(1/(x-1))::ULS(FRAC POLY INT, x,0)

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

forwarded from

reply via email to

[Prev in Thread] Current Thread [Next in Thread]