[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] about Expression Integer

From: Ralf Hemmecke
Subject: Re: [Axiom-developer] about Expression Integer
Date: Mon, 20 Feb 2006 12:28:42 +0100
User-agent: Thunderbird 1.5 (X11/20051201)

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)


(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


also gives

       Type: DirectProduct(2,NonNegativeInteger)



    (5)  - 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():

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

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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]