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