RE: [Axiom-developer] about Expression Integer

[Bill Page]

Francois,

On February 19, 2006 2:01 PM you wrote:
> 
> So I try :
> 
> > P := DistributedMultivariatePolynomial([x,y],Expression Integer)
> > a: P := x
> > a/x

Axiom replies:

(3) -> a/x

        1
   (3)  - x
        x
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

> 
> > However, I guess, most people find this confusing.
> > Indeed...

But really it is very simple and easy to predict. The problem
is that most people focus is on the wrong thing. This is especially
natural if they have previous experience with other computer algebra
systems.

In Axiom it is necessary to first understand the meaning of the
domain:

DistributedMultivariatePolynomial([x,y],Expression Integer)

What kind of operations does it export? You can ask Axiom:

)sh DistributedMultivariatePolynomial([x,y],Expression Integer)

After that one can consider if and how the expression a/x might
be a member of this domain.

> 
> Why axiom doesn't see the denominator as a DMP([x,y], Expr Int) ?
> The numerator is a DMP([x,y], Expr Int).

Already your question tells me that you are not thinking about
the domain first. An expression which has both a numerator and
a denominator can not be member of the domain DMP(...)

> 
> Numerator and denominator of any fraction are in the same ring, 
> and have the same type.

But the expression 'a/x' is not a fraction. It is a binary
operation that involves 'a' and 'x'. Axiom needs to know what the
'/' represents. To do this it has to match the types of it's
arguments to the signature of a known function. The type of 'a'
is known, Axiom starts by assuming that x is of type Variable
and looks for an operation '/' in DMP with arguments DMP and
Variable, but there is none. Then it looks for the same operation
in Variable and finds none. So next it considers the operation
'/' with signature

  / : (%, Expression Integer) -> %

in DMP. (Note that % means "this domain".) The Axiom interpreter
discovers that it can first coerce the 'x' of type Variable to an
'x' of type Expression Integer, then it can apply the above operation
from DMP. The result is still something in DMP which happens to have
'x' as both the polynomial variable and '1/x' as it's coefficient.
The implementation of DMP is such that it does not attempt to
simply this result - the polynomial variables and the coefficient
domain remain separate.

> 
> The x variable can't be a variable of the Expression Integer Ring, 
> because this a is one of the polynomial.

There are two separate uses of the variable x: once as a polynomial
variable in DMP and once in the '1/x' which is in the domain
Expression Integer. These are the *same* variable, but used in
two different ways (i.e. in two different domains).

> 
> // 1 //
> I was waiting that axiom read a/x as (a::P)/(x::P) because I wait
> the same calculus from my students on a sheet of paper.

This result is easy to obtain and if I was a teacher of computer
algebra, I would probably leave it as an exercise for my students.
:) But this is not a classroom. The answer is almost given in the
way you wrote the question. Try this:

(4) -> b: FRAC P :=x

   (4)  x
   Type: Fraction DistributedMultivariatePolynomial([x,y],Expression
Integer)

(5) -> b/x

   (5)  1
   Type: Fraction DistributedMultivariatePolynomial([x,y],Expression
Integer)

> 
> Is it too difficult ?

I think it is very simple, but my explanation is too long. :)

> 
> // 2 //
> I also wait a fail result for the command :
> b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
> 
> I understand what is R[X], (R[X])[Y], (R[Y])[X], R[X,Y] and R[Y,X].
> 
> I don't understand what is (R[X])[X], so axiom might forget it.
>

Axiom understands (because of the implementation of DMP) the
distinction between the use of 'x' as a polynomial variable and
the use of 'x' as a coefficient. Perhaps it is true that such a
distinction is not commonly made in mathematics, but the
implementation of DMP keeps these uses distinctly separate.
Axiom is not able to "forget it".
 
> And I don't understand why it's not interessing to add this patch :
> .....
> However for our purposes something rather primitive is sufficient: 
> All domains that contain variables need to export a function 
> variables2: % -> List Symbol. Then we can say in 'QFCAT':
> 
>  if S has variables2: S -> List Symbol then
>    variables2: % -> List Symbol
>    variables2 f ==
>       merge(variables2(numer(f)), variables2(denom(f)))
> 
> and add the following to UP and 'MPOLY':
> 
>  if R has variables2: R -> List Symbol then
>    coerce(r:R):% ==
>      if member?(x, variables2(r)) then
>        error "coefficient contains variable"
>      else coerce(r)$Rep
> ......
>

The patch is not interesting because this situation does not
represent an error. It is a situation that Axiom was designed
to handle correctly. The facilities already exist in Axiom to
simplify the polynomial

 1
 - x
 x

(where '1/x' is a coefficient and the right hand 'x' is the
polynomial variable), if it is desirable.

> // 3 // 
> Why DMP doesn't accept OrderedSet but only List Symbol ?
>

I think this difference is only a historical accident and the
fact that the work on different polynomial domains was done at
different times by different people.
 
> * one writes a new domain with a new representation. For
>   'DistributedExpression' I failed to do so, since the proper 
> representation would be 'DMP', but this only accepts a 'List Symbol'
> as variables, for expressions I need to allow an arbitrary
> 'OrderedSet' however.

Perhaps you can send a copy of your source code. I think what
you are trying to do is possible but it might turn out to be
rather complicated. You can however quite easily convert between
an OrderedSet of variables and a list of variables.

> 
> If I'm right Expression are built over POLY which accept
> OrderedSet or <<kernel>> as sin x and so.
> 

I am afraid that Expression is much more complicated. :( In
fact it is one of the most complex domains in Axiom. I agree,
however with you and Martin Rubey, that we need to re-consider
this domain and possibly extend it in various ways.

I hope that in spite this email is too long, perhaps it is
some use to you.

Regards,
Bill Page.