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 > > > 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.
