[Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions)

[Martin Rubey]

Dear William,

I'll only reply to the "mixing up variables" issue, since I do not have a clear
picture of the others yet. On the other hand, it seems to me that our
discussion is more about philosophy, since we agree that MEXPR(vars, Ring) is
the way to go.

William Sit writes:
 > Dear Martin:
 > 
 > Martin Rubey wrote:

 > > Yes. Given x^2 sin(x) - cos(x)/x, no sane mathematician will say that this
 > > could be viewed as a polynomial. Of course, this argument is based on the 
 > > idea
 > > that x=x, i.e, there shouldn't be different x's in one expression.
 > > 
 > > I'm pretty sure that it is next to impossible to do this conversion
 > > consistently. For example:
 > > 
 > > (14) -> x::UP(x, EXPR INT)/x::UP(x, EXPR INT)
 > > 
 > >    (14)  1
 > >                     Type: Fraction UnivariatePolynomial(x,Expression 
 > > Integer)
 > > (15) -> x::UP(x, EXPR INT)/x::EXPR INT
 > > 
 > >          1
 > >    (15)  - x
 > >          x
 > >                              Type: UnivariatePolynomial(x,Expression 
 > > Integer)
 > > 
 > > are both completely correct, given the strange semantics of UP(x, EXPR 
 > > INT).

 > The problem is caused by the user in (15). An undeclared x (as in "x ::") is
 > treated in the interpreter (you must declare for the compiler) as the unique
 > element of Variable(x). Any time such an x is coerced into UP(y, ?), it will
 > check if y is x, and if so, return the monomial x in UP(y,?), otherwise it
 > tries to coerce x into ? when possible, or gives an error if not. As I have
 > pointed out before, Axiom is not confused, the user is. 

Well, the result *is* confusing. And I don't think that this behaviour could be
useful.

 > Axiom cannot possibly rule out such user behavior because each operation
 > (x::UP(x,?), x::EXPR INT, and /) is correctly performed. To do so would
 > require Axiom to "look ahead" when processing x::UP(x,?). This is
 > unreasonable as well as impossible -- how far ahead? what if the x::EXPR INT
 > is something returned by another routine?

I don't understand: it can! Well, I mean: it could. One possibility is the
following: every domain that has (named) variables should have a function vars:
R -> List Symbol and isvar?: Symbol -> Boolean. (I think the latter is not
strictly necessary: it should return true if the Symbol could be a variable in
the domain) Then coercions could be done as I suggested: 

if any?(isvar?, vars(thing)) 

then thing cannnot be regarded as a coefficient.

I do admit that to integrate SUP into this picture might be tricky.
  
 > I see no reason to allow POLY EXPR INT or similar constructs **as Axiom now
 > stands.** Unfortunately, the general and categoric constructs in Axiom make
 > it difficult to "exclude" specific domains (POLY(R) is valid for any ring R;
 > the user is allowed to construct POLY(R) for whatever R, even if R is
 > POLY(S). In fact, I don't know of any Axiom mechanism to exclude specific
 > domains in a constructor's parameters. (Axiom allows declaring domains to
 > HAVE certain attributes, but I believe does not allow them to NOT HAVE
 > certain attributes).

As it now stands, the way to do things is simple: don't use towers of domains
with variables. (One exeption is polynomials with coefficients that are
expressions not containing variables: we have to use POLY EXPR INT here...)

 > Below, I'll try to analyse where the present problem lies and propose a way
 > to correct the problem. Even if you agree with my analysis, whether the
 > correction should be implemented or not is still subject to discussion.

Do I understand correctly: You propose (roughly) that variables should carry a
tag that tells which domain they belong to.
  
 > Let me say that there is pehaps a role for constructs like POLY POLY INT or
 > POLY EXPR INT.  Examples: computing syzygies of polynomials generating an
 > ideal, or more generally the defining set of algebraic polynomial
 > (equations) for algebraic functions -- a (non-linear) system of differential
 > equations is simply algebraic equations for functions and their
 > derivatives. 

Could you give an example here? I do not understand.
  
 > Unfortunately, the current convention is not "outer domain takes all the
 > variables."

Hmmm? I didn't say that it was. By the way, "the outer domain takes all the
variables" is an inprecise summary. That's why I added "it can" from time to
time...

For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a
variable of the outer domain, y a coefficient. No confusion can arise.

Maybe it would be better to say "a variable that can be taken by an outer
domain, cannot appear as a coefficient". To explain that (1/x)::POLY(EXPR INT)
should yield an error, note that the variable is x, not (1/x).

 > )clear all
 > a:=monomial(1,1)$UP(x, INT)
 >   x
 > 
 > a::SUP INT
 >   ?

Note that this does not work in the compiler. You have to use makeSUP
expressively. And in fact, I think it shouldn't work in the interpreter either.
 
 > a::SUP UP(x,INT)
 >   x
  
 > Even though a tower of polynomial rings is involved in the above, these are
 > legitimate mathematical constructs (and correctly done) -- the unspecified
 > variable is intended to be transcendental over ANY coefficient domain, and
 > is often used to work with minimal polynomial of an element algebraic over
 > the coefficient domain. Here it shows that in coercing a variable into
 > SUP(R), the interpreter first try to coerce it into R, and failing that, to
 > to unspecified variable. So in this case, SUP only takes a variable when
 > necessary.

As an aside: towering SUP's is also an interesting issue. Consider

makeSUP(y::UP(y,SUP INT)*x::UP(x,INT)) giving 
   (20)  ? ?
          Type: SparseUnivariatePolynomial SparseUnivariatePolynomial Integer

Well, you know that.
     
 > > I would like to have a mapping from maths to axiom as clear as possible.
 > > And given the convention that the "outermost" domain "takes" all the
 > > variables (it can), EXPR POLY INT and EXPR INT would be the same
 > > mathematically, since any polynomial is an EXPR. Of course, the
 > > representations could be different in the two domains.
  
 > See above discussion on indexed method constructing polynomial rings.

I agree that your proposal (if I understood it) is also clean.

 > > Thus I think the direction to go is to put these checks into the compiler.
  
 > I don't know enough about compilers: Can a compiler single out (12) to
 > disallow it? For now, just don't use the same symbol for two different
 > things, and perhaps fix the error message with a warning instead.

I meant to say: "put these checks into the algebra." This is clearly possible.

Martin