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

[Bill Page]

Martin,

I prefer to reply to your email on the axiom-developer list rather
that the axiom-user list because I think the issues that you raise
are not so much related to "how to use" Axiom but rather more about
"how Axiom works" and possibly design and re-design. I would like
to invite Thomas to subscribe to one or both of these Axiom email
lists if he has an interest in following further discussion.

On January 26, 2007 6:20 AM Martin Rubey wrote:
> 
> although for the end-user it probably doesn't matter, I'm afraid
> that the impression the mails by Bill Page and Francois Maltey
> give is not quite "complete".

Yes I agree, which is the reason I think it is worth some time
to continue this thread on the developer list.

> 
> * in Axiom, it is very important to distinguish between 
> internal representation and output.
> 

Yes! But of course this is a problem for novice Axiom users. In
comparison with Maple (and most other CA systems), Axiom's focus
on internal representation makes things immediately seem more
complicated then they "need to be". I think this is very bad for
new users.

Secondly, making Axiom's output non-trivially related to the
internal representation creates a barrier and a steep learning
curve since in many cases it turns out that "things are not what
they appear to be". Thus Axiom as it exists today violates the
"principle of least surprise" many times over. Some people treat
this as a challenge while others find it very repulsive to
continued use of Axiom.

> * "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. Having used Maple extensively I would say that
when using the expand operator I do not have the sense of merely
affecting a desired output. I think it is wrong to say that
"internal representation doesn't matter". Rather it is more that
case that there is only one internal representation - expression -
and one views expand as actively manipulating that representation.
Often one seeks a series of such manipulations that preserve the
algebraic structure but which lead to the desired result, e.g.
prove a theorem or compute some specific unknown.

> * in Axiom, if you want to have a different output, it is 
> best to write a wrapper domain.

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). This requires
a kind of "2nd order" thinking about a problem compared to the
usual straight forward analysis that most people apply to problem
solving. So I think it is important to separate "Axiom Users" into
at least two classes: those interested immediate "engineering-
oriented" results, and those willing to invest time and effort
into more general solutions.

> 
> * 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?

> 
> Here goes the domain. Put it into a file, for example 
> myexpr.spad, type
> 
> )co myexpr.spad
> 
> on the axiom command prompt
> 
> and 
> 
> (((-r1*r2*uoff)+((r2+r1)*r3+r1*r2)*ue)/(r2*r3))::DEXPR INT
> 
> should return
> 
>         r1 ue   r1 uoff   r1 ue
>         ----- - ------- + ----- + ue
>           r3       r3       r2
>

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

I recall that you have in fact presented this very solution
before in the context of a similar question. 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

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

> 
> ---myexpr.spad 
> ----------------------------------------------------------------
> )abb domain DEXPR DistributedExpression
> DistributedExpression(R: Join(Ring, OrderedSet)): Exports == 
> Implementation where
>   AN  ==> AlgebraicNumber
>   SUP    ==> SparseUnivariatePolynomial
> 
>   EXPRR ==> Expression R
> 
>   Exports == FunctionSpace R with
>     if R has IntegralDomain then
>       AlgebraicallyClosedFunctionSpace R
>       TranscendentalFunctionCategory
>       CombinatorialOpsCategory
>       LiouvillianFunctionCategory
>       SpecialFunctionCategory
>       reduce: % -> %
>         ++ reduce(f) simplifies all the unreduced algebraic quantities
>         ++ present in f by applying their defining relations.
>       number?: % -> Boolean
>         ++ number?(f) tests if f is rational
>       simplifyPower: (%,Integer) -> %
>         ++ simplifyPower?(f,n) \undocumented{}
>       if R has GcdDomain then
>         factorPolynomial : SUP  % -> Factored SUP %
>            ++ factorPolynomial(p) \undocumented{}
>         squareFreePolynomial : SUP % -> Factored SUP %
>            ++ squareFreePolynomial(p) \undocumented{}
>       if R has RetractableTo Integer then RetractableTo AN
> 
>   Implementation == EXPRR add
> 
>     Rep := EXPRR
> 
>     out: (Polynomial R, %, List %, List %) -> OutputForm 
> -- coerces the polynomial to OutputForm completely expanded 
> and replaces the
> -- variables in vl with the kernels in kl
>     out(p, q, kl, vl) == 
>       ex: Fraction Rep := (eval(leadingMonomial(p)::%, vl, 
> kl)::Rep)/(q::Rep)
>       if reductum p = 0 
>       then coerce(ex)$Fraction(Rep)
>       else coerce(ex)$Fraction(Rep) _
>            + out(reductum p, q, kl, vl)
> 
>     coerce(ex:%):OutputForm == 
>       kl := kernels ex
>       vl: List % := [subscript('x, 
> [i::OutputForm])::Symbol::% for i in 1..#kl]
>       ex1: % := subst(ex, kl, vl)$%
>       kl1 := map(coerce(#1)$%, kl)$ListFunctions2(Kernel %, %)
>       if R has IntegralDomain then
>           out(retract(numerator ex1)@Polynomial(R), 
>               denominator eval(ex1, vl, kl1), kl1, vl)
>       else
>         out(retract(ex1)@Polynomial(R), 1, kl1, vl)
> ---myexpr.spad 
> ----------------------------------------------------------------
> 
> A note for Thomas: the only bit of code that required some 
> work was "out" and "coerce". Everything else (i.e., everything
> before and including "Rep:=EXPRR") is copy and paste. If the
> Aldor interface would work properly, it wouldn't be there.

Even with Aldor I would not count this as a solution that a novice
Axiom user could possibly apply.

> 
> I'm sure that "out" and "coerce" could be simplified and 
> improved, too. I just didn't bother.
> 
> A note for axiom developers:
> 
> 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.

Personally I think it is a design mistake that Axiom has both a
MultivariatePolynomial domain and DistributedMultivariatePolynomial
domain. I think the model for the domain constructor 'Factored'
should have been followed where we have Polynomial(Integer) and
Factored(Polynomial Integer). Just as in the case of Factored,
the internal representation of Distributed would be different
than the underlying domain, e.g. the representation might be a
List structure those elements come from the underlying domain.
The operations in Distributed have to be "lifted" from the
underlying domain but applied to the new representation.

Then from a novice Axiom User's point of view, the proposed
domain constructor Distributed would (for the most part) just
take the place of Maple's expand operator. Of course in Axiom
there is much more to the story of types and domains then there
is in Maple, but one still has the "feeling" that one is
actively operating a some underlying internal representation
in a transparent and effective manner.

Regards,
Bill Page.