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. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
