RE: [Axiom-developer] Re: How to expand a fraction

[Bill Page]

On January 26, 2007 7:59 PM Waldek Hebisch wrote:
> 
> Wiesner Thomas wrote:
> 
> > How can i do the following (from Maple) in Axiom:
> >
> >     expand(((-r1*r2*uoff)+((r2+r1)*r3+r1*r2)*ue)/(r2*r3));
> >
> >                          r1 uoff        ue r1   ue r1
> >                        - ------- + ue + ----- + -----
> >                            r3            r2      r3
> 
> Modulo term order:
> 
> (14) -> x := ((-r1*r2*uoff)+((r2+r1)*r3+r1*r2)*ue)/(r2*r3)
> 
>          - r1 r2 uoff + ((r2 + r1)r3 + r1 r2)ue
>    (14)  --------------------------------------
>                           r2 r3
>                           Type: Fraction Polynomial Integer
>
> (15) -> reduce(+, [box(k/denom(x)) for k in monomials(numer(x))])
> 
>               r1 ue   r1 ue     r1 uoff
>    (15)  ue + ----- + ----- + - -------
>                 r2      r3         r3
>                                    Type: Expression Integer
> 
> How does it work: we split fraction into numerator and
> denominator, then split numerator into separate terms (using
> 'monomials' function). We divide each of the terms by the
> denominator and put an invisible box around the resulting
> quotient.  Then we add everything back together.
>

Excellent! I think it is a clever solution. It is more
transparent than Martin's DistributedExpression solution and
it uses some operations that a novice Axiom user might already
understand and find useful for other purposes.

But an explanation is still required about the use of the
Expression domain versus polynomials and the choices that the
Axiom interpreter makes in this case.
 
> Some remarks:
> 
> 1) box operator prevents simplification,

Perhaps you meant to say "evaluation" rather than "simplification".
It is misleading to take about simplification in this context.
It seems to me that Axiom never attempts any simplification as
such. It simply applies each operator that it selects based on
contextual and explicit type information as it parses some input.
The result of the calculation is a member of some domain which
may have an associated "canonical" OutputForm that appears similar
to an simplification of the input expression but really has nothing
directly to do with expression manipulation.

I think it is better to say that 'box' (and the related operator
'paren' in ES) simply remain unevaluated and have a particular
associated OutputForm. But the arguments of box, and expressions
involving box, are in fact evaluated by Axiom as the example below
shows.

> so careful when you use it, otherwise you may get unexpected
> results.
> 

Indeed! For example

(16) -> box(1+2)+box(3)

   (16)  23
                                       Type: Expression Integer

[Note: This must be read a 2 * 3.]

(17) -> %::InputForm

   (17)  (* 2 (%box 3))
                                               Type: InputForm

How to "unbox" an expression?

> 2) AFAIK expand command in Maple is really a cheaper version of
>    simplify (it is enough to simplify polynomials).  More
>    precisely, Maple is doing very little (no??) simplification
>    by default, so you may have a complicated expression which is
>    really 0. Expand gives you "canonical" form for polynomials --
>    if two polynomials are mathematically equal then the expanded
>    forms are equal.  This is not needed in Axiom, Axiom normally
>    keeps polynomials (and rational functions) in "canonical" form.

Rather than speaking about "canonical forms", it is more accurate
to say that Axiom choices a particular internal representation for
each domain.

>    If for some reasons other forms are preferable Axiom offers
>    some extra domains (like Factored).
> 

I would also add "like DistributedMultivariatePolynomial". See
further comment below.

> 3) AFAIU what you really want is a way to control how results
>    are printed.

I disagree that the original intent of the question was necessarily
limited to "control how results are printed". The author asked:
"how do I expand an expression" as in the context of Maple. The
reason why one might want to manipulate an expression this way was
not stated but it certainly might include showing that two expressions
are equal such as you implied above.

>    IIRC Axiom gives only very limited control over formatting the
>    output.
> 

As Martin's example showed, that is not true. Axiom's OutputForm
domain provides a very rich formatting environment (at the cost
of some programming in SPAD).


> 4) In general each systems has hardcoded ideas what looks best,
>    and it can be frustrating trying (with no effect) to match
>    output of the other system.
>  

In Axiom I think it is important to realize that an "object" (i.e.
an member of a domain) has both an internal representation (hidden
except for the explicit operations exported by the interface) and
an external appearance as "hardcoded" by a particular coercion to
the OutputForm domain. How much of this one can or should say to a
novice Axiom user, I am uncertain. But everything else I have seen
written so far seems misleading to me.

> 5) IMHO your Maple solution, the command I gave and Bill Page
>    DMP trick are really abuses: all of the commands perform some
>    computation and the change in printed output is a by-product
>    (possibly unintended).  I wrote above about Maple expand.
>    Axiom DMP was implemented to allow efficient computation of
>    Groebner bases (and some similar computation).

I object to the phrase "trick" and "abuse". It seems to me that
what you, I and Martin wrote as "solutions" make good sense in
the appropriate context. I am not sure why you would claim that
the intended use of DMP is limited to efficient computation of a
given kind, however I agree of course that the choice of internal
representation of a domain does have a big impact on efficiency of
a given algorithm.

>    I know very little about box operator, but I suspect that it
> main intended use was _not_ to control printing.
>

Clearly it is an operation in Axiom that is intended to facilitate
the manipulation of members of the Expression domain in (more or
less) the manner which you demonstrated. That his affects how
expressions are printed seems to me to be a natural consequence.


Regards,
Bill Page.