Re: [Axiom-developer] about Expression Integer

[Ralf Hemmecke]

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.

Maybe one very simple idea would be to write a domain constructor

ExpressionSum(R:OrderedSet): Exports == Implementation where
  Exports ==> -- Same as for Expression(R)
  Implementation ==> List Expression R
  Rep := List Expression R
  (x: %) + (y: %): % == per append(rep x, rep y) -- concat lists
  -- The other functions have to be implemented accordingly.
  -- That will be a lot of work.
  coerce(x: %): OutputForm == map(+, [e::OutputForm for e in rep x])
    -- Maybe some parens should be added if the expression has
    -- a minus sign

I am not sure, however, whether this is the best idea. Unfortunately, I 
don't know all the domains of Axiom so well. So maybe my sugestion is 
completely irrelevant since something like that is already existing in 
Axiom.

> > 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)

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

> Perhaps your concern arises because you have not worked out
> completely how Axiom uses the concept of domain. I know that
> you understand this idea in some depth because of your background
> with Aldor. As a programmer and a long term user of Maple, I
> had, perhaps, a similar background, but it has taken me more
> than two year of working with Axiom to really understand (at
> least I think I now understand :) how it is applied to mathematics.

Well, I agree, that you are probably better in applying Axiom to real 
world problems, but 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.

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

And by the way, 1 is a perfect member of DMP([x,y],Integer) also in 
Axiom. I know you know that.

(1) -> a: DMP([x,y],Integer) := 1

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

> What about? (Notice that Axiom makes you work harder to say something
> like this.)
>
>   b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
>
> Can you explain this result?
>
> (23) -> degree b
>
>    (23)  [0,0]
>    Type: DirectProduct(2,NonNegativeInteger)
>
> (24) -> b+x
>
>    (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] }.

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. Those people 
would probably treat (24) as 2x and that interpretation would be wrong.

> > Now, it is totally clear that
> >
> > degree(a/x)
> >
> > also gives
> >
> > [1,0]
> >        Type: DirectProduct(2,NonNegativeInteger)
> >
> > since
> >
> > a/x
> >
> >          1
> >     (5)  - x
> >          x
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> >
> > yields also a completely correct output. ;-) However, I guess, most
> > people find this confusing.
>
> 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.

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.

> But eventually in order to program in Axiom, it is essential that
> they gain a full appreciation of the object-oriented design
> philosophy.

I would not really like to call Axiom (or Aldor) object-oriented.
We don't write

a.add(b)

in order to add two numbers.

the function "add" is not attached to the object a. It is rather that a 
and b are on equal footing.

Try to program a simple thing as a n-ary polynomial ring in a purely 
object-oriented programming language (like for example JAVA even with 
generics), then it becomes clear that Axiom has more to offer that the 
current trend in programming.

Ralf