"Bill Page" <[EMAIL PROTECTED]> writes: > 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.
well, I'd be happier if I could defend my point of view. Just, I can't, currently. Still I'll try to (partially) respond to this message... Please bear with me. > > 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. Why should this be wrong? Here's a definition for polynomial from wikipedia: In mathematics, a polynomial is an expression in which constants and variables are combined using (only) addition, subtraction, and multiplication. Thus, 7x^2+4x-5 is a polynomial; 2/x is not. I recall that in the Algebra course I attended, the polynomial ring was defined as a ring (of coefficients) together with a variable which is to be transcendent over that ring. I guess you know that, so there is probably a misunderstanding somewhere. Just to be clear: sin x + y*cos x + y^2* tan x is perfectly allright a polynomial in y. > 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? I think that 'differentiate' does not exhibit odd behaviour. Why do you think it's odd? Of course, if you claim that x+1/sin(x) is a polynomial, than I'm out of luck. You said, given > > > > 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) > 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 wouldn't say that this violates the "mathematical definition of derivative". The derivative of a univariate polynomial is defined by sending x^n to n*x^(n-1) and linear extension. There is no such thing as 1/x in the polynomial world. If you want a domain that contains x and 1/x, consider using Laurent polynomials. In fact I cannot see a single reason to consider a domain DMP(vars, EXPR INT) at all, except for the fact that we do not have a domain EXPR(vars, coefficients) yet. > > Note that b::UP([x], INT) or b::POLY INT give errors! > > Obviouse 'b' has no representation in these domains. Yes it has: 1 is a UP([x], INT). Martin _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
