On Thu, Jan 28, 2010 at 6:19 PM, Ronan Lamy <[email protected]> wrote: > Le mercredi 27 janvier 2010 à 17:14 -0800, Ondrej Certik a écrit : >> On Wed, Jan 27, 2010 at 5:11 PM, Ronan Lamy <[email protected]> wrote: >> > Le mercredi 27 janvier 2010 à 16:52 -0800, Ondrej Certik a écrit : >> >> On Wed, Jan 27, 2010 at 4:39 PM, Ronan Lamy <[email protected]> wrote: >> >> > Le mercredi 27 janvier 2010 à 11:19 -0800, Ondrej Certik a écrit : >> >> >> What is the advantage of having two classes instead of one? Just so >> >> >> that I understand the motivation better. Essentially you just want to >> >> >> split Basic into two classes, so that each class is simpler to >> >> >> maintain? I am missing why it is a roadblock, but since you both did >> >> >> some work with assumptions already, I guess there is a good reason >> >> >> for that. >> >> > >> >> > The main problem is circular dependency: assuming we switch to the new >> >> > assumption system, algebraic expressions need assumptions, assumptions >> >> > need the logic module, and logic needs Basic. So if Basic is aware of >> >> > the existence of algebraic expressions, we have a problem. This also >> >> > means that Basic shouldn't be aware of assumptions, by the way. >> >> >> >> Basic should not be aware of assumptions at all, that's clear. >> >> >> >> So let's say I have x^2, which is Pow(Symbol("x"), 2). How does the >> >> Expr come into this? And why does it need to know about assumptions? I >> >> thought that's what refine() is for. >> > Expr is a base class of both Pow and Symbol, so its methods might be >> > called when working with x^2. It probably needs to know about some >> > assumptions (for instance whether x is commutative) in order to evaluate >> > some expressions (for instance (y*x^2)^2). >> >> Besides commutative, does it need to know any other assumption? I >> think we might have a new NCMul for commutative multiplication. > > It would certainly be better to have different classes for commutative > and noncommutative multiplication but this is a somewhat unrelated > problem. It doesn't change the fact that there has to be a way to know > whether x and y are commutative in order to evaluate x*y.
My idea is that there doesn't have to be. "x" and "y" is just a symbol. If you type Mul(x, y) you get (let's say) a commutative operation, if you get NCMul, you get (let's say) a noncommutative operation. If you type x*y, then, depending how we overload the __mul__ methods, it would either return Mul(x, y), or NCMul(x, y), I would vote for the former. > > All the assumptions in the old system have probably been implemented > because they're useful somewhere so they're probably all required to > evaluate some thing or other. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
