Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])?
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.
