RE: [Axiom-developer] about Expression Integer

[Bill Page]

Martin,

On February 22, 2006 3:54 AM you wrote:
> 
> I'm currently out of time. But I'm a little afraid of the 
> direction the discussion takes currently.

I on the other hand am very happy that this discussion
seems to accurately reflect the concept of type in Axiom.

> 
> I believe that the intension of a constructor like DMP is
> to cover *polynomials*.

I agree. "cover" is the operative word. This does not
preclude that the type DMP in Axiom might be a little more
general than what is called a polynomial in some mathematical
uses (but perhaps not others).

> 
> If we allow (2*x+1/x)::DMP([x], EXPR INT), i.e., allowing 1/x 
> as a coefficient, then it must be clear that the "x" in 1/x
> is something different than the "x" in 2*x. Otherwise we don't
> get a polynomial, obviously.

I think this is wrong. In fact, it is clear from the
implementation of Axiom that whether the 'x' in these two
cases is the same or not depends on which domain to which
they belong.

Could you please define in what sense "Otherwise we don't get
a polynomial, obviously."? To me this is not obvious - it is
wrong.

> 
> So, I think that
> 
> > > P := DMP([x,y], EXPR INT) 
> > > a :P := x 
> > > b := a/x 
> > > 
> > > differentiate(b,x)                    -- 1/x
> > 
> > (4) -> differentiate(b,x)
> > 
> >         1
> >    (4)  -
> >         x
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> > 
> > I think this result should be classed a bug. The 'differentiate'
> > operation apparently makes some incorrect assumptions about the
> > coefficient domain. I think the result should be the same as:
> 
> is not a bug. If you want to have axiom output 0, then I 
> imagine that you will get into trouble with writing packages,
> variable capture might well occur.

If by "variable capture" you mean the same thing as "escaped
local variables", then I would claim that this can not occur in
Axiom, by nature of it's internal design.

On the other hand a 'differentiate' operator that returns 1/x
in (4) above would violate the mathematical definition of
derivative, so I think it cannot possibly be right.

> 
> I'd rather say that b::EXPR INT giving one is troublesome. I 
> wouldn't really classify it as a bug though, given the nature
> of EXPR INT. 

No! EXPR INT is a domain in which we can ask with the two
uses of 'x' represent the same 'x' and we correctly discover
that in this context they are the same.

> Note that b::UP([x], INT) or b::POLY INT give errors!

Obviouse 'b' has no representation in these domains. This
result is correct. On the other hand one might expect that
'b::FRAC POLY INT' would work, but in this case I think it is
just a limitation of the conversion algorithm.

> 
> PLEASE don't change the behaviour of DMP and company. What 
> should be documented (and I think Ralf did, but I hadn't time)
> is that domains like POLY EXPR INT and friends can lead to
> "surprising" results. This should go into the section "types"
> of the axiom book.
> 

Documentation is a good thing. But why should we retain behaviour
in Axiom that is mathematically incorrect? What advantage does
this odd behaviour of 'differentiate' have over a mathematically
correct implementation?

Regards,
Bill Page.