[Axiom-developer] Re: [Axiom-mail] How to expand a fraction (like Maple does with'expand')?

[Martin Rubey]

Dear Bill, *,

"Bill Page" <address@hidden> writes:
 
> > * "expand" as provided by Maple, Mathematica, etc., is mainly about output,
> > the internal representation doesn't matter too much there. It can be
> > interpreted as: display the thing with everything multiplied out.

> I do not agree. 

That's exactly why I said that one should make DMP accept arbitrary
variables. Then the problem would go away, and furthermore, one would have an
efficient representation for the desired operations.

> As soon as you suggest creating new types (domains) for specific purposes I
> think you take the discussion beyond what most novice users are whiling to
> accept (at least initially).

I did not say that functionality like "expand" should not be provided. Quite
the opposite, in fact. However, since it is beyond my time to provide a good
solution, I presented a hack, that also shows how to create output you simply
cannot do in Maple et al. For example, I can imagine (but I do not know) that
it might be difficult in certain CAS to expand everything but keep the
denominator factored out. Or expand only with respect to certain variables,
etc.

> > * it is very easy to write such a domain in Axiom. In Aldor, it would be
> > even easier, but unfortunately, currently the necessary functionality
> > ("extend") is not provided by the Axiom-Aldor interface.
 
> Now, surely you realize that when you say "very easy to write", you are not
> satisfying the expectations of the original question which was to presume
> that a "simple" expand operation in Maple should have a direct counter-part
> in Axiom?

well, if "extend" were functional, I'd say, it would be really easy to
write. As of current state, I agree. And, again, I fully agree that "expand"
functionality should be present in Axiom.

> I think this result is wonderful but very unconvincing...

Well, you should take into account that it took me roughly 3 minutes (one of
them being compiling).
 
> I recall that you have in fact presented this very solution before in the
> context of a similar question. 

Yes, but the desired output was different then. It kept the denominator
factored out...

> We previously discussed the issue of whether it would make sense to introduce
> a new domain constructor, say 'distributed' that would operate in a manner
> analogous to Axiom's 'factored' construction. Then one could write for
> example
 
>   Distributed Expression Integer

I think that the idea of "Factored" is nice, I think I stated this before. I'm
not sure that it is to carry out. Furthermore, I'm not sure that the same idea
would make sense for Distributed.

> But the suggestion that the difference is merely one of "appearance" of the
> resulting expression is still very unsatisfying to me.

I did not intend to say that it should be that way. In fact, if you look at
symmetric functions, for example, the internal representation matters a lot. Of
course you can store them as polynomials. But then everything you do will be
horribly inefficient.

My "solution" is a hack, suitable for experimenting.

> > In my opinion, this is not the right approach. The right approach would be
> > to generalize DMP and to allow arbitrary variables, just as SMP does.
> 
> I would like to invite you to explain here in more detail what
> you mean.

The signature of SMP is 

SparseMultivariatePolynomial(R: Ring,VarSet: OrderedSet)

while the signature of DMP is

DistributedMultivariatePolynomial(vl,R): public == private where
  vl : List Symbol
  R  : Ring

I'd propose to make it identical to the signature of SMP.

> Personally I think it is a design mistake that Axiom has both a
> MultivariatePolynomial domain and DistributedMultivariatePolynomial domain.

That may well be. Maybe you can try to design such a domain Distributed? I
think, the first steps would be to see which categories the argument has to
satisfy, and how you can "lift" the functionality of the argument domain.

For example, would Distributed EXPR INT provide exponentiation ^: (%, %) -> % ?

If so, what would the result of (a+b)^n be?

Would you provide eval?

eval((a+b)^n, n=3)

Consider:

(1) -> p: POLY INT
                                                                   Type: Void
(2) -> p := a+x + a+y

   (2)  y + x + 2a
                                                     Type: Polynomial Integer
(4) -> factor p

   (4)  y + x + 2a
                                            Type: Factored Polynomial Integer
(5) -> factor eval(p, x=y)

   (5)  2(y + a)
                                            Type: Factored Polynomial Integer
(6) ->  eval(factor p, x=y)

   (6)  2y + 2a
                                            Type: Factored Polynomial Integer

(although, I must admit that this is simply a bug in Factored and could be
easily corrected. Currently it assumes that specializing does not affect
factorization)

Martin