I written tests for this now. Brian
On Sat, Jul 24, 2010 at 10:07 AM, Brian Granger <elliso...@gmail.com> wrote: > Here is an addition patch that adds this capability to all binary special > methods in Expr: > > > http://github.com/ellisonbg/sympy/commit/116acd6ef2bde6d0d0aa8c2f2ec1f380abbabab1 > > The performance penalty is still around 1%. If there is support for this > approach, I would like to merge it to trunk soon as this issue is holding up > the quantum stuff. Also I was thinking that in the long run this could > improve performance. Here is the idea. Currently, all of the basic > operation classes (Mul, Add, Pow) have to have custom logic to non > commutative entities. With the new priority based binary operations, we > could implement an NCMul, and NCPow classes that have all of that logic. > The result is that the work Mul and Pow have to do decreases. It would > also be much simpler. > > Cheers, > > Brian > > On Sat, Jul 24, 2010 at 8:20 AM, Brian Granger <elliso...@gmail.com>wrote: > >> Here is a simple implementation that does a priority based check for >> __mul__ and __rmul__: >> >> >> http://github.com/ellisonbg/sympy/commit/bb449fbdf78f5ef19351640d987d96204c6c3f34 >> >> On my machine the test suite does not slow down a significant amount >> (within 1%). Of course, if we use this approach on all binary ops, we will >> get additional slow down, but this is promising. >> >> Cheers, >> >> Brian >> >> >> On Sat, Jul 24, 2010 at 7:26 AM, Brian Granger <elliso...@gmail.com> >> wrote: >> > Alan, >> > >> > This only works because you have custom scalars as well. Because of >> > this, you have overridden the __mul__ and __rmul__ methods of *every* >> > object that is used in GA. But in quantum mechanics, I still need to >> > use all the regular sympy scalars that use the default Expr.__mul__ >> > and Expr,__rmul__ that return Muls. Anytime a sympy scalar gets >> > multiplied by my classes on the left (scalar*mytype), Expr.__mul__ >> > gets called, not mytype.__mul__. >> > >> > Cheers, >> > >> > Brian >> > >> > On Sat, Jul 24, 2010 at 4:57 AM, Alan Bromborsky <abro...@verizon.net> >> wrote: >> >> Brian Granger wrote: >> >>> >> >>> On Fri, Jul 23, 2010 at 8:30 PM, Ronan Lamy <ronan.l...@gmail.com> >> wrote: >> >>> >> >>>> >> >>>> Le vendredi 23 juillet 2010 à 17:41 -0700, Brian Granger a écrit : >> >>>> >> >>>>> >> >>>>> On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer < >> asmeu...@gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>>> >> >>>>>> First off, pragmatically speaking, is there a reason why you need >> to >> >>>>>> use the core Mul instead of writing your own custom Mul for the >> quantum >> >>>>>> stuff? I am just saying this because even though I agree that we >> need this >> >>>>>> change, changing anything in the core is very difficult and time >> consuming, >> >>>>>> because the code is so fragile, and you also have to pay close >> attention to >> >>>>>> speed concerns. >> >>>>>> >> >>>>> >> >>>>> I would very much like the option of using a custom Mul subclass, >> but >> >>>>> that is currently impossible in sympy. The reason is that my >> >>>>> expressions also have sympy scalars. Anytime one of those appears >> on >> >>>>> the left of a multiplication its __mul__ gets called and everything >> >>>>> becomes a Mul. To use custom Mul classes for anything, we need to >> >>>>> have something like the __array_priority that numpy has built into >> the >> >>>>> core. >> >>>>> >> >>>> >> >>>> I think this can be done with a careful implementation of double >> >>>> dispatch in __mul__ and __rmul__, so I don't see the point of this >> >>>> __array_priority. Though this implementation would require some sort >> of >> >>>> complete ordering of the classes, which is conceptually similar to an >> >>>> __array_priority, it doesn't have to appear explicitly in the code. >> >>>> >> >>> >> >>> The nice thing about the __array_priority is that it is easily >> >>> extensible. You can add new sympy types and fine tune their priority >> >>> without touching the core. Also, like numpy, the priority should be >> >>> used in all special methods like __add__, __mul__, __pow__, etc. >> >>> >> >>> Cheers, >> >>> >> >>> Brian >> >>> >> >>> >> >>>> >> >>>> Ronan >> >>>> >> >>>> -- >> >>>> You received this message because you are subscribed to the Google >> Groups >> >>>> "sympy" group. >> >>>> To post to this group, send email to sy...@googlegroups.com. >> >>>> To unsubscribe from this group, send email to >> >>>> sympy+unsubscr...@googlegroups.com<sympy%2bunsubscr...@googlegroups.com> >> . >> >>>> For more options, visit this group at >> >>>> http://groups.google.com/group/sympy?hl=en. >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> >> >> >> >> I don't see the problem. Here is how it is done in the geometric >> algebra >> >> module (see below). In >> >> "geometric_product(mv1,mv2)" you test to see if mv1 and mv2 are both >> >> multivectors >> >> and if they are you use the geometric product. If not you use the >> scalar >> >> product of a multivector and >> >> a scalar. >> >> >> >> def __mul__(self,mv): >> >> """See MV.geometric_product(self,mv)""" >> >> return(MV.geometric_product(self,mv)) >> >> >> >> def __rmul__(self,mv): >> >> """See MV.geometric_product(mv,self)""" >> >> return(MV.geometric_product(mv,self)) >> >> >> >> >> >> @staticmethod >> >> def geometric_product(mv1,mv2): >> >> """ >> >> MV.geometric_product(mv1,mv2) calculates the geometric >> >> product the multivectors mv1 and mv2 (mv1*mv2). See >> >> reference 5 section 3. >> >> """ >> >> product = MV() >> >> if isinstance(mv1,MV) and isinstance(mv2,MV): >> >> bladeflg1 = mv1.bladeflg >> >> bladeflg2 = mv2.bladeflg >> >> if bladeflg1: >> >> mv1.convert_from_blades() >> >> if bladeflg2: >> >> mv2.convert_from_blades() >> >> mul = MV() >> >> for igrade in MV.n1rg: >> >> gradei = mv1.mv[igrade] >> >> if isinstance(gradei,numpy.ndarray): >> >> for ibase in range(MV.nbasis[igrade]): >> >> xi = gradei[ibase] >> >> if xi != ZERO: >> >> for jgrade in MV.n1rg: >> >> gradej = mv2.mv[jgrade] >> >> if isinstance(gradej,numpy.ndarray): >> >> for jbase in >> range(MV.nbasis[jgrade]): >> >> xj = gradej[jbase] >> >> if xj != ZERO: >> >> xixj = >> >> MV.mtable[igrade][ibase][jgrade][jbase].scalar_mul(xi*xj) >> >> product.add_in_place(xixj) >> >> product.bladeflg = 0 >> >> if bladeflg1: >> >> mv1.convert_to_blades() >> >> if bladeflg2: >> >> mv1.convert_to_blades() >> >> if bladeflg1 and bladeflg2: >> >> product.convert_to_blades() >> >> else: >> >> if isinstance(mv1,MV): >> >> product = mv1.scalar_mul(mv2) >> >> else: >> >> product = mv2.scalar_mul(mv1) >> >> return(product) >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "sympy" group. >> >> To post to this group, send email to sy...@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> sympy+unsubscr...@googlegroups.com<sympy%2bunsubscr...@googlegroups.com> >> . >> >> For more options, visit this group at >> >> http://groups.google.com/group/sympy?hl=en. >> >> >> >> >> > >> > >> > >> > -- >> > Brian E. Granger, Ph.D. >> > Assistant Professor of Physics >> > Cal Poly State University, San Luis Obispo >> > bgran...@calpoly.edu >> > elliso...@gmail.com >> > >> >> >> >> -- >> Brian E. Granger, Ph.D. >> Assistant Professor of Physics >> Cal Poly State University, San Luis Obispo >> bgran...@calpoly.edu >> elliso...@gmail.com >> >> > > > -- > Brian E. Granger, Ph.D. > Assistant Professor of Physics > Cal Poly State University, San Luis Obispo > bgran...@calpoly.edu > elliso...@gmail.com > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
