On Sun, May 22, 2011 at 7:27 PM, Aaron S. Meurer <asmeu...@gmail.com> wrote: > > On May 22, 2011, at 12:12 PM, Mateusz Paprocki wrote: > > Hi, > > On 22 May 2011 18:17, Aaron S. Meurer <asmeu...@gmail.com> wrote: >> >> Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])? > > It works: > In [2]: import operator > In [3]: reduce(operator.mul, [x, y, z]) > Out[3]: x⋅y⋅z > In [4]: type(_) > Out[4]: <class 'sympy.core.mul.Mul'> > but I wouldn't use it on large examples because it takes O(n**2) steps to > canonicalize the inputs (similar problem with sum([x,y,z]), we have even an > issue open for this). > > No, I mean is there a way for literally "x*y*z" to call (essentially) > reduce(operator.mul, [x, y, z])? > But like you said, it is O(n**2), so I guess it doesn't matter (unless you > can also do it O(n)). > Aaron Meurer
Well it wouldn't work either. It would be an infinite loop. operator.mul just calls the dispatches to the appropriate .__mul__/.__rmul -- Andy > > >> >> Aaron Meurer >> >> >> On May 21, 2011, at 9:11 PM, Andy Ray Terrel <andy.ter...@gmail.com> >> wrote: >> >>> My experience with developing languages in Ignition, is largely the >>> same as what Brian outlined. Another solution though is to instead of >>> doing much of the Mul(args) in the core, to do reduce(operator.mul, >>> args). Since things get expanded into Mul objects they don't hit my >>> own mul objects. Right now I have to do ugly hack that fix things up >>> after the fact. >>> >>> -- Andy >>> >>> On Sun, Jul 25, 2010 at 1:04 PM, Brian Granger <elliso...@gmail.com> >>> wrote: >>>> >>>> >>>> On Sat, Jul 24, 2010 at 5:14 PM, Ronan Lamy <ronan.l...@gmail.com> >>>> wrote: >>>>> >>>>> Le samedi 24 juillet 2010 à 13:10 -0700, Brian Granger a écrit : >>>>>> >>>>>> 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. >>>>> >>>>> I'm not sure this is the best design, but it's better than the current >>>>> situation, so +1 on the idea. Two remarks though: >>>> >>>> Any other ideas of different approaches? I followed this one because it >>>> has >>>> been well tested in numpy. >>>> >>>>> >>>>> * Since the whole point of this is to untie binary operators from Expr, >>>>> the mechanism (i.e. call_other()) shouldn't be implemented in expr.py. >>>> >>>> OK >>>> >>>>> >>>>> * The repetitiveness of the code should be abstracted away in a >>>>> decorator. >>>>> >>>> >>>> I was thinking that as well. This is especially true because people who >>>> want to define their won special methods that respect the priority will >>>> need >>>> to use the decorator. >>>> Cheers, >>>> Brian >>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "sympy" group. >>>>> To post to this group, send email to sympy@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. >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 sympy@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. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy" group. >>> To post to this group, send email to sympy@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. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sympy@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. >> > > Mateusz > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@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. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@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. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@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.
