On Feb 2, 2010, at 12:39 PM, Ondrej Certik wrote: > 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.
The problem I can see with this is that * will default to commutative (of course), so then how do you do noncommutative. Do you have to type out NCMul(x, y), or is some other operator overloaded for that multiplication or what? Also, consider a potential assumption, scalar vs. matrix. If A and B are matrixes (in the assumptions system), and x is a scalar, then it should know that A*B != B*A by default, and it should automatically take the canonical x*A. I do not dispute, however, that there needs to be completely separate classes for the two, so that simplification functions and so on are not so prone to messing up non-commutativity. Aaron Meurer > >> >> 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. > -- 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.
