RE: [Axiom-developer] about Expression Integer

[Bill Page]

On February 20, 2006 6:29 AM Ralf Hemmecke wrote:
> 
> On 02/19/2006 06:06 PM, Bill Page wrote:
> > On February 18, 2006 2:37 PM Ralf Hemmecke wrote:
> >>>> 1/ Can I (or cannot) remain Expressions as 
> >>>>
> >>>> x+1/(y+1)             
> >>>> y+1/(x+1)             
> >>>>
> >>>> and do not have a single denominator.
> >> Unfortunately, I have no idea, how to do this. :-(
> 
> > It is obvious, isn't it, that to do this is Axiom you *must*
> > find a domain of which this expression can be a member?
> 
> Of course, you are right. I was just saying that I don't know of
> a domain which behaves as one would expect. So the next thing I 
> would do is to write another domain which behaves (and inherits)
> most things from Expression Integer but does not group expressions
> together so that they are over one denominator.
>

Yes, that is a good idea if you desire to solve the general
problem of defining a domain in which contains all possible
expressions as members. Perhaps this is the kind of "userdomain"
that Jenks and Trager had in mind in the design of BNatural.

http://wiki.axiom-developer.org/BNatural

How would this differ from Aldor's ExpressionTree domain?
 
> ... 
> >> But, I'd like to warn you. Don't follow Bill's suggestion.
> 
> > I think it is strange how confident both of us are in the
> > opposite opinion. :)
> 
> > I don't think you have shown any flaw in my suggestion. It seems
> > to me to be very reasonable solution to the problem originally
> > posed by Francois. In fact this same approach is used on other
> > parts of Axiom.
> 
> Your suggestion does not work if you want to do the following:
> 
> x+1/(y+1)  + y+1/(x+1)
> 
> since
> 
> (x+1/(y+1)  + y+1/(x+1))$DMP([x,y],EXPR INT)
> 
> shows as
> 
>                      y + x + 2
>     (4)  x + y + ----------------
>                  (x + 1)y + x + 1
>     Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
>

You are right that this might quite not produce the type of trigonometric
expansion that Francois has in mind. On the other hand, the result
is still well defined in the sense that the parts of the expression
that are representable as a distributed polynomial remain and
everything else is in the coefficient domain. I think it would be
better than what Axiom currently produces for:

  expand sin((x+1/(y+1)  + y+1/(x+1)))
 
> Of course, ad hoc solutions are not bad as long as one knows 
> what one is doing, but I somehow don't like the ad hoc method.

I don't think this solution should be classed as "ad hoc". It
seems to me to be consistent with other operations of this
kind already done by Axiom. But I do agree that it is not a
fully general solution.

> Either there is a clever program that guesses correctly what
> the user wants, or, if this is not possible, the user should
> think a bit more and perhaps add more knowledge to the system.
> Otherwise Axiom ends up in being like all the other untyped CAS.

I agree.

> ... I hope you agree that if Axiom is not able to do the things
> that Francois wants in a clear way, then it would be better
> (at least for the future) to add a nice feature to the system
> instead of being satisfied that the wish can be fulfilled by an
> ad-hoc-misuse of existing domains.

I agree (except I do not class my proposed solution as an
ad-hoc-misuse :).

> 
> > In particular it is important to realize
> > that the object that is called a DMP in Axiom is almost, but
> > not quite that same thing as what a mathematician would call a
> > polynomial. It is actually something a little more general. It
> > makes a explicit distinction between the underlying coefficient
> > domain and the polynomial domain itself. This is something that
> > one would not (normally) do in mathematics.
> 
> Well, a polynomial in n variables with coefficients in a ring R is
> an element of
> 
>    \Oplus_{e \in N^n} R
> 
> where N is the non-negative integers.
> 
> If you like, you can attach variable names somewhere. Yes, I 
> also know that some people define polynomials differently.
> 

This is good enough for me and apparently to the designers of DMP.
They do attach the polynomial variables names, but on the other hand
they also provide the 'vectorize' operator.

> ... 
> > 
> >    (24)  x + x
> >     Type: 
> DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> So, let me interpret a polynomial as above as a function (with
> finite support) from the domain of exponents to the domain of
> coefficients.
> 
> (24) clearly has support { [1,0], [0,0] } an is therefore by no
> means equal to the polynomial 2x which has support { [1,0] }.

Ok.

> 
> I am not really saying that Axiom is doing something wrong, I am
> just warning that the use of DMP([x,y], Expression Integer) can
> be misleading for people that don't know how Axiom works internally.

To write your interpretation above you did not need to know how
Axiom works internally. If people where equipped with your explanation
I don't think the result would be misleading. This is the type of
documentation that I think we need to have for Axiom's library.

> Those people would probably treat (24) as 2x and that interpretation
> would be wrong.

It is only wrong in the context of DMP([x,y], Expression Integer).
In domain 'Expression Integer' it is correct. That is why I say
that Axiom demands that one first state clearly the domain and
only then consider the expression.

> >>
> >>          1
> >>     (5)  - x
> >>          x
> >>    Type: 
> >>      DistributedMultivariatePolynomial([x,y],Expression Integer)
> >>
> > ... 
> > I think this is only confusing if you try to think of this
> > expression out of context, that is, without thinking about the
> > structure of the domain to which is belongs.
> 
> The context is clearly given. It's the type of (5). Right, I 
> could even predict, that Axiom should give back that expression.
> (How could I otherwise have constructed it?) But the two x's one
> sees, have different origins and are therefore not equal.

It is only in the context of this domain that they are not equal.
If I coerce this result to the domain 'Expression Integer' they
will be treated as equal.

> 
> By the way, you can achieve similar confusing things with Maple.
> 
> f:=proc() local x; x end;
> a:=f(): b:=f():
> evalb(a=b);
> 
> That behaviour had once cost me several days to trace down a bug. 
> Clearly, a looks like x and b looks like x. But they are not equal.
> I haven't found this to be documented.
>

In Maple terminology this is known as an "escaped local variable".
I think this situation is completely different than in Axiom. It is
reasonable to conclude that this odd behaviour in Maple occurs
because Maple does not have any concept of domain, so it cannot
(at least not easily) specify a situation (domain) in which the
equality 'a=b' can be properly evaluated. Notice that in Axiom
'=' is also an operator and we need to know the domain which
provides this operation.
 
> ...

Regards,
Bill Page.