axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] about Expression Integer


From: Bill Page
Subject: RE: [Axiom-developer] about Expression Integer
Date: Sat, 18 Feb 2006 09:06:06 -0500

On February 18, 2006 4:28 AM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> > There are however more complex domains which do include 
> > expressions of the same form as you wrote above. The
> > interpreter is not able to find these automatically, but
> > you can help by specifying more exactly what you want. In
> > the compiler you must always provide this additional
> > information. For example:
> > 
> > (2) -> (x+1/(y+1))$DMP([x,y],EXPR INT)
> > 
> >               1
> >    (2)  x + -----
> >             y + 1
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> 
> This is very dangerous!
>

No. I think you are confusing a "bug" with a "feature" here. You can
see this "danger" more clearly in the following simple example:

(1) -> ex1:=(x+1/x)$DMP([x,y],EXPR INT)

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

(2) -> ex2:=ex1*x

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

The second term in (2) is obviously unexpected. The reason is that
Axiom interprets the 'x' in '1/x' that occurs in the coefficient as
a different 'x' than the 'x' that occurs as a variable of the
polynomial. Axiom is continuing to make the distinction between the
use of variables that is allowed in this domain. This is a perfectly
reasonable expression as it stands - it is just not as simple as we
might expect.

But when we ask Axiom to consider this expression as a member of
the 'Expression Integer' domain, we get the simple result that we
probably expected:

(3) -> ex2::EXPR INT

         2
   (3)  x  + 1
   Type: Expression Integer

So this is not really "dangerous" in the way I think you meant
above.

> > 
> > (3) -> (y+1/(x+1))$DMP([x,y],EXPR INT)
> > 
> >               1
> >    (3)  y + -----
> >             x + 1
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> DON'T!
>

Do you mean do not do this in order to avoid unexpected results?
Or do you mean never. If the latter, than I disagree strongly.
 
> > but notice that the 2nd term is a monomial of degree 0 
> > since this domain has coefficients that can be expressions.
> > You might consider this result ambiguous since the entire
> > expression could be consider a term degree 0, but apparently
> > the domain DMP attempts construct a polynomial of highest
> > degree?
> 
> This has been thoroughly discussed, see 
> 
> http://wiki.axiom-developer.org/WhereDoVariablesBelong
> 
> and the threads mentioned therein.
>

I have reviewed the discussion again, and I think the conclusions
might be wrong. I am not convinced that this is a bug in the way
Axiom works or design flaw even though the behaviour is radically
different than most other computer algebra systems. In Axiom you
have to be very careful about when and where you test for the
equality of two things.
 
> The main problem you will encounter with the expression above 
> is that you are really introducing two *different* variables
> x, so, some time later you may have Axiom saying x <> x.

No that is not true as expression (3) above illustrates.

> 
> The construction above somehow works if you can make sure 
> that your sets of variables are separated, i.e., when the
> coefficients contain variables a,b,c,... and the variables
> of the polynomial are x,y,z. This is clearly not the case
> above.
> 

No it is not necessary that the variables be separated, but it
is necessary to remain focused on the domain to which a given
expression belongs. This is one of the features that distinguishes
Axiom from more "primitive" computer algebra systems.

Regards,
Bill Page.






reply via email to

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