On 22.04.2013 23:27, Aaron Meurer wrote:
On Mon, Apr 22, 2013 at 2:54 PM, Tom Bachmann<e_mc...@web.de> wrote:
On 22.04.2013 17:54, Aaron Meurer wrote:
Another way to optimize might be to check for common noop inputs and
figure out how to efficiently short circuit them.
Hm. It seems that (at least in the case I'm testing) by far the most common
case is two-argument flatten, where one of the arguments is a rational, +-I,
or a constant (pi). I could reduce execution time by 20% by hard-coding the
case of +-I times a symbol.
That's because x + y + z is evaluated as (x + y) + z, so any time you
manually write out an expression, it is going to be a two-arg flatten.
Proper use of Mul(*args) or Add(*args) when the args are all known at
once can mitigate this. You could also play with somehow caching the
state of flatten inside the object itself, so that it doesn't have to
start from scratch. There have been many discussions on this sort of
thing in the past.
These ideas are starting to creep away from the assumptions, though,
Yes. This is why I am trying to focus on a simple solution, which allows
me to press forward with the assumptions (at the expense of not really
solving the caching problems, but only circumnavigating them).
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
