Originally Savannah bug 10350. Example of code trigerring the bug: axiom integrate((1/x)::UTS(FRAC POLY INT,
axiom integrate((1/y)::UTS(FRAC POLY INT, The first bug is an indication that
I disagree with the previous comment; x should be captured and not allowed in the FRAC POLY INT. (I agree that the second example in the original report is not a bug.) But surely we can all agree that
Dylan (dpt@math.harvard.edu)
Neither of these is a bug. In the first one, Axiom coerced
Note that the domain of this command is For the same reason, in the second command, So your examples do not illustrate the problem about mixed up
variables. In fact, it supports use of towers like
William (wyscc@cunyvm.cuny.edu) axiom integrate((1/x)::ULS(FRAC POLY INT,
It is finite so we can represent it as a polynomial: axiom univariatePolynomial(%,
This domain distinquishes between axiom %::FRAC POLY INT
Type: Fraction(Polynomial(Integer))`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 Instead, the user should have separated the two operations: axiom f:ULS(FRAC POLY INT,
axiom integrate(f, Three things should be noted here: (a) axiom g:ULS(FRAC POLY INT,
axiom integrate(g,
Here Axiom actually expands axiom h:=(1/(x-1))::ULS(FRAC POLY INT,
axiom integrate(h,
Now Axiom having been forced to output the same identifier for two different variables, the first 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 William Users should not use the same identifier for two different objects. consider that this is COMPUTATIONAL mathematics. the user has to know
what the scope of a variable is. the removing simplification of type towers would significantly reduce the usefulness of axiom. t 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. I have examined this simplification more closely. As discussed in another email, this is actually done by invoking a substitution map: briefly, the x in ULS is being substituted by the x in FRAC POLY INT. I think this is unwarranted "smartness" by the Interpreter (this is a "lesser crime" than a "bug"). Of course, as Tim said above, this is secondary error due to an error by the user. It would be a legitimate substitution if a user initiated it. I believe the automatic substitution would not be done in the compiler (that is, the coercion would be flagged). The Axiom compiler, as far as I can tell, scoped the two x's correctly. It is the automatic substitution by the Interpreter due to a request to coerce that yields the answer 1. Whether you call this a feature or a bug is up to you. Users beware. William From email referred to above: (edited for Wiki) :: Date: Fri, 24 Feb 2006 07:14:24 -0500
From: William Sit Bill: > This thread seems to go on forever ... but I feel compelled > to continue it because: 1) I think understanding how this > works is critical to understanding and using Axiom, 2) I don't > think we have a simple explanation yet of something that really > should be simple in principle, if not in it's application in > certain cases. There never is anything simple in Axiom. By its nature every function is parametrized and categorical. Clearly, this issue will recur as new users stumbles onto these constructions. As you know, a polynomial ring over a ring in the indeterminates When you write However, no matter how buggy a computer algebra system is, we are using it to do
As to your quibble to my separating "identifier", let me emphasize:
identifiers are external strings what a user in the interpreter use to refer
to objects that are internal to Axiom. axiom )set mess bot on
Type: Symbolthen: y is the identifier I use (y is NOT the symbol), x[1,2,3,4] the linear function with signature elt: (VARIABLE x, LIST PI)->SYMBOL, and the symbol is x with [1,2,3,4] as subscript x itself is a Symbol and is different (as far as Axiom goes) from the x in the domain Variable(x) Just to emphasize the fine distinctions, the output you see, is an element of
Bill Page wrote: > William Sit continued: > > > 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. ... > > I don't think that this is the case since we can obtain the > same result above using: > > (1/x)$MPOLY([x],FRAC POLY INT)*x > %::FRAC MPOLY([x],POLY INT) I am trying to explain the coercion using coerce: UP(x,R) -> POLY R when > > 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) > > Apparently on the first coercion is sufficient. Moving the > fraction from the coefficient domain to become a fraction > of polynomials: > > UP(x, FRAC POLY INT) +-> FRAC UP(x, POLY INT) > > provides a domain in which the two uses of x can cancel.You are missing the point. I don't care how the Interpreter performs the illegal coercion (except that I was trying to explain the design goal that leads to the illegal coercion). The coercion is simply WRONG. Period. It is an error built on a user error. (Don't we know that compilers are famous for that when reporting error messages?) In such cases, a user is supposed to remove the original error, not argue about the validity or invalidity of subsequent errors. > In fact we can see this same coercion in operation in the > case of going from: > > POLY FRAC INT +-> FRAC POLY INT > > (1) -> (1/2*x)$UP(x, FRAC INT) > > 1 > (1) - x > 2 > Type: UnivariatePolynomial(x,Fraction Integer) > > (2) -> )set message bottom on > (2) -> %::FRAC UP(x,INT) [additonal output snipped]These are legal coercions since mathematically, `POLY FRAC INT` is a subring of
`FRAC POLY INT` and similarly, `UP(x, FRAC INT)` is a subring of `FRAC UP(x, INT)` .
The design goal I mentioned above is not involved. If you had taken `x/2` in ```
FRAC
POLY INT
``` or in `POLY FRAC INT` and coerce this to `UP(x, FRAC INT)` , then the design
goal is applied and the Interpreter (not the compiler) will oblige by
identifying the
the variable `x` of `POLY FRAC INT` with the main variable ? of `UP(x, FRAC INT)`
because the user used the identifier `x` for ?. This feat is accomplished only
with the help of `UP2(x,POLY FRAC INT,x,FRAC INT)` , which explicitly maps the `x` in
`POLY FRAC INT` to the `x` (or ?) of `UP(x, FRAC INT)` . It is equivalent to a
substitution map. There is no general coercion from `POLY FRAC INT` to ```
UP(x, FRAC
INT)
``` .
> > 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. > > I don't understand this comment. What do you mean by > "scope problems"?When one constructs `POLY POLY INT` , one tells Axiom to use `Symbol` as the variable
set over `POLY INT` . Thus the `Symbol` in the outer construction should be in a
different lexicon scope so that this copy of `Symbol` can be a family of
algebraically independent elements over `POLY INT` . I don't want to go into the
details of how domains are constructed (I probably don't know anyway), but if we
modify whatever will be used as symbols in `POLY INT` by attaching a context
prefix, say `POLYINT-x` for what we normally use `x` , then we can distinguish
another symbol `x` in this copy for the external `POLY` construction by using
`POLYPOLYINT-x` . Apparently, the Interpreter allows a substitution of
`POLYPOLYINT-x` by `POLYINT-x` , giving the user the impression that the two are
identified, and this is the flaw I was discussing. The Interpreter should not do
that with coercion. A substitution should be explicitly requested by the user. A
coercion should not involve a hidden substitution.
Let me repeat this mathematically. Let be a ring, a set and You can substitute by The construction of A big big question in computer algebra should be how to handle "canonically isomorphic" mathematical objects. Mathematicians assume these identifications without a thought in most cases, but there are occasions where distinction is important. For example, they would rarely identify two vastly differently defined finite sets just because they have the same cardinality. > > (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. > > I agree that simple steps are easier to analyze. I also > think it is a mistake to write something like: > > (x+1)::POLY INT > > or > > x+1::POLY INT > > when > > (x+1)$POLY INT > > will do. In the first two cases the interpreter will do > some extra computation by default before it applies the > coercion operation and the result of coercion is harder > to analyze than the simple package call. |

not a bug--Bill Page, Sat, 18 Feb 2006 11:10:37 -0600 reply