[Top][All Lists]

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

RE: [Axiom-developer] about Expression Integer

From: Page, Bill
Subject: RE: [Axiom-developer] about Expression Integer
Date: Fri, 24 Feb 2006 14:39:45 -0500


On Friday, February 24, 2006 8:07 AM you wrote:
> Any scientific literate person, when (s)he wrote down:
>    2*x + 1/x
> would mean that there is only ONE x, the x means the same
> thing throughout the expression.


> So
> (1) -> (2*x+1/x)::DMP([x], EXPR INT)
>           2
>         2x  + 1
>    (1)  -------
>            x
>               Type:
> DistributedMultivariatePolynomial([x],Expression Integer)
> (2) -> degree(%)
>    (6)  [0]
> is perfectly correctly interpreted by Axiom. The entire
> expression is a coefficient, in EXPR INT.

It is a correct interpretation, but it is not the only
possible interpretation. The reason it is interpreted as
entirely with 'EXPR INT' is because you used a conversion
'::' instead of a package call $. Axiom processes what is
inside the parenthesis first. Since there is no package
specification there, the interpreter assumes we are talking
about 'EXPR INT'. Then it applies the coercion from 'EXPR INT'
to 'DMP([x], EXPR INT)' which simply embeds the expression
as a term of degree 0.

Try this instead:

(1) -> (2*x+1/x)$DMP([x], EXPR INT)

   (1)  2x + -
   Type: DistributedMultivariatePolynomial([x],Expression Integer)

(2) -> monomials(%% 1)

   (2)  [2x,-]
   Type: List DistributedMultivariatePolynomial([x],Expression Integer)

In this case we told Axiom to use only operations from the
domain 'DMP([x], EXPR INT)'. It sees '2*x' and selects the
'*' with signature '?*? : (Integer,%) -> %'. The result is
a term of degree 1. Then it looks at '1/x' and selects
'?/? : (%,Expression Integer) -> %'. The result is a term
of degree 0.

This also is correctly interpreted by Axiom. But these two
expressions are not equivalent in this domain.

> However, I think Axiom is wrong in allowing that, since x,
> being an indeterminate over EXPR INT, should not be in

I suppose what you are saying is that the ring over which
DMP is defined should not be 'EXPR INT' but rather
'SubDomain(EXPR INT, not member?(x::Symbol,variables(#1))'.
This is a possible definition but it seems unnecessarily
complicated. Further it would explicitly prevent the kind
of coercion that Axiom was apparently carefully designed
to do (see below).

There is no danger that Axiom will confuse the two uses of
'x' and to the user this result looks perfectly reasonable -
it looks like just a different way of formatting the
expression - but of course as "advanced users" we know the
difference is more subtle than that.

>The coercion should simply fail, or end up in

I do not see how it could possibly end of in
'FRAC DMP([x], EXPR INT)' in either version of (1) above.

> Note that even if the following is used, Axiom continues to
> "retract" the x from 1/x to EXPR INT. This is simply wrong.
> x:DMP([x], EXPR INT):=x
> 2*x + 1/x
> degree(%)
>           [1]

It is not wrong. I agree that it might be unexpected if
one does not keep in mind the domains from which Axiom will
select functions. One might (incorrectly) thought that the
1/x must be evaluated in 'FRAC DMP([x],EXPR INT)' but once
again Axiom first considers the '/' function defined in
domain that it already knows: 'DMP([x],EXPR INT)' before it
attempts anything more complex. It discovers that it can
evaluate 1 in 'DMP([x],EXPR INT)' and that since 'x' is a
variable of type 'DMP([x],EXPR INT)', it knows that it can
always coerce such polynomials into 'EXPR INT'. This allows
it to apply the operator '/' from 'DMP([x],EXPR INT)'.

> On the other hand, the following is correct, and should
> be the case no matter what the coefficient domain is.
> y:DMP([y], INT):=y
> 2*y+1/y
>            2
>          2y  + 1
>          -------
>             y
>                 Type: Fraction
> DistributedMultivariatePolynomial([y],Integer)
> The two cases should not be handled differently.

I agree that this result is correct but I disagree that
these two cases can be handled the same way (i.e. by
selecting the '/' operation in 'DMP([y], INT)'. This is
not possible because Axiom cannot coerce polynomials of 
type 'DMP([y], INT)' into 'INT'.

> If a user wants to push the result down to the coefficient
> domain, it should be done with a substitution map,
> explicitly, and the user should not use x in EXPR INT.

This sort of coercion is only possible when the coefficient
domain has 'PDRING Symbol' or at least 'PDRING OVAR vl'
where 'vl' is polynomial variable list. Apparently Axiom
attempts to use it during the function selection process.

Bill Page.

reply via email to

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