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: Sun, 19 Feb 2006 16:11:02 -0500

Martin,

On February 19, 2006 1:41 PM you wrote:
> 
> Bill Page writes:
> 
> > Since DMP is the highest level domain constructor, I would 
> > expect it to interpret 'x' as being in the polynomial domain
> > first and only if forced treat is as being in the underlying
> > coefficient domain.
> 
> I believe that this is not always the case, although I don't 
> have an example at hand.

That is why we need some proper and detailed documentation.
Failing that, we can always read and analyze the source code.
(Actually, it order to write such documentation we have to
do this anyway.)

> 
> However, I would like to restate what William Sit and I were 
> able to agree upon, when we discussed these matters:
> 
>   Axiom is able to deal (more or less) properly with 
>   variables bearing the same name but having different
>   meanings.

Yes! I agree, except I having looked at a lot of source code
I would no longer feel the need to "hedge my bets" by adding
"more or less". I think it can always deal properly with this
situation. If we find some situation where it does not, then
we should treat this as a bug and correct it.

> 
> We did not agree on whether we should allow this to happen
> or not...
>

There may be some situations, such as in the Axiom interpreter
where you might wish to warn the user about the sometimes
unexpected consequences of domains that allow this. But I
completely disagree with the suggestion that is should not
be allowed.
 
> In other words, consider the following example:
> 
> >   b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
> > 
> > Can you explain this result?
> > 
> > (23) -> degree b
> > 
> >    (23)  [0,0]
> >    Type: DirectProduct(2,NonNegativeInteger)
> > 
> > (24) -> b+x
> > 
> >    (24)  x + x
> >     Type: 
> DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> Here, we have two *different* "variables", the only happen to 
> bear the same name.

No. That is the wrong analysis. Axiom does not have any concept
of "variable" that would allow you to make this statement without
first giving the context of the domain. By definition the members
of two different domains are *different* by the very nature of
belonging to two different domains. But in the right context
(right domain) we can see in fact that the two 'x' above are in
fact the same symbol but used to two different contexts. The DMP
domain explicitly makes the distinction between polynomial
variables and coefficients. It thus provides the context where
the two uses of 'x' can be distinguished when the coefficient
domain includes expressions containing the symbol 'x'.

> 
> What I consider very problematic is, that
> 
>  (b+x)::EXPR INT
> 
> gives 2x. I believe that this can lead to very "surprising"
> results.
>

This is only surprising if one does not understand the meaning
of expression 'x+x' in (24). Part of the reason for the confusion,
I think, is because the common OutputForm for polynomials does
not typographically identify polynomial variables versus
coefficients. But if, say the polynomial variables were always
printed in bold face roman type but the coefficients were
printed in italic, it might be more clear what is going on.
 
> In any case, I think it is better not to use such types.

I think it would be better to document clear how and when
such types should be used.

> Currently, this is not always possible, it would be necessary
> to introduce a parametrized Expression domain, that takes
> variables as parameters -- this is on the WishList, by the
> way. I don't think it would be too much work.
> 

This might be interesting, but I am not completely convinced. In
fact, I sometimes wonder whether it makes sense to distinquish
the coefficient domain in the case of Expressions.

Regards,
Bill Page.






reply via email to

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