[Axiom-developer] RE: symbolic manipulation of expressions in Axiom

[Bill Page]

On April 1, 2007 5:45 AM Gaby wrote:
> 
> >> Why should InputForm be preferable over Expression T?
> >>
> ... 
> > For me to answer your question it is important to understand
> > what Expression in Axiom really is. One way to do that is to
> > look at the internal representation.
> >
> >  Rep:=Fraction SparseMultivariatePolynomial(T, Kernel %)
> >
> > So Expression is a mathematical domain of rational functions
> > (ratio of two polymonials) where the polynomial variables
> > are extended to kernels including various special functions.
> 
> Sorry, I don't think I'm satisfied with an answer that has to
> look at the internal representation before explaining why I
> should not believe the interface.
>

Of course you should believe the interface! There is no need to
look at the internal representation. I just thought it might be
easier since we are developers and are able to take a "white box"
view. But if you prefer that I express this only in terms of the
interface, please review the following Axiom session.

Consider the three strings:

(1) ->   a1:="(a/x)+(a/y)"

   (1)  "(a/x)+(a/y)"
                                                     Type: String

(2) ->   a2:="(a/x) + (a/y)"

   (2)  "(a/x) + (a/y)"
                                                     Type: String

(3) ->   a3:="(a*x+a*y)/(x*y)"

   (3)  "(a*x+a*y)/(x*y)"
                                                     Type: String

Of course as members of the Domain String these are all different.

(4) -> (a1=a2)::Boolean

   (4)  false
                                                     Type: Boolean

(5) -> (a1=a3)::Boolean

   (5)  false
                                                     Type: Boolean

(6) -> (a2=a3)::Boolean

   (6)  false
                                                     Type: Boolean

While as members of the Domain Expression Integer these are equal.

(7) -> interpretString(a1."=".a2)::Boolean

   (7)  true
                                                     Type: Boolean

(8) -> interpretString(a1."=".a3)::Boolean

   (8)  true
                                                     Type: Boolean

(9) -> interpretString(a2."=".a3)::Boolean

   (9)  true
                                                     Type: Boolean

But when we evaluate them as symbolic expressions in the domain
InputForm:

(10) -> x:INFORM:=x

   (10)  x
                                                   Type: InputForm

(11) -> y:INFORM:=y

   (11)  y
                                                   Type: InputForm

(12) -> a:INFORM:=a

   (12)  a
                                                   Type: InputForm

The first two are equal but the third is something different!

(13) -> interpretString(a1."=".a2)::Boolean

   (13)  true
                                                     Type: Boolean

(14) -> interpretString(a1."=".a3)::Boolean

   (14)  false
                                                     Type: Boolean

(15) -> interpretString(a2."=".a3)::Boolean

   (15)  false
                                                     Type: Boolean

So equality of these "algebraic" objects in Expression Integer
is not the same as equality in a purely symbolic domain like
InputForm.

In fact, after completing this exercise I realized that the
original Axiom developers actually did already anticipate the
need for an OutputForm for InputForm that is equivalent the
actual input to the Axiom interpreter. The function that I was
looking for is called 'expr' in the domain InputForm.

(16) -> map(expr,map(interpretString,a1=a2)::Equation(INFORM))

         a   a  a   a
   (16)  - + -= - + -
         x   y  x   y
                                      Type: Equation OutputForm

(17) -> map(expr,map(interpretString,a2=a3)::Equation(INFORM))

         a   a  a x + a y
   (17)  - + -= ---------
         x   y     x y
                                      Type: Equation OutputForm

(18) -> map(expr,map(interpretString,a1=a3)::Equation(INFORM))

         a   a  a x + a y
   (18)  - + -= ---------
         x   y     x y
                                      Type: Equation OutputForm

So once again as Tim Daly has said main times, the problem is
just that :( as usual ): there is not enough documentation.

Regards,
Bill Page.