Am 01.07.2012 13:05, schrieb [email protected]:
I suppose that this makes you, as a professional programmer, get a
headache over the fragile design :)
Hehe, sort of.
Not that I should be too critical of that, I have certainly written my
share of ugly code - mostly due to performance constraints.
The horrifying solution employed both in the old lambdify and in my
> code is to use eval() and some string processing. This is (or not?)
> the optimal workaround that was found around the fact that python
> function calls are inherently slow (thus prohibiting the use of
> nested lambdas instead of eval).
I'm rather surprised by such a finding.
I mean, eval() can't be working much differently under the hood - in the
end, you still need to call an evaluator function on each leaf and
internal node of the expression tree.
Or, putting it another way: Whatever calls eval() is doing under the
hood, it should be faster if some Python code iterated over all nodes of
the expression tree and did the same calls. Actually it should be faster
because the eval-parse detour is cut out (except one approach might be
doing more work in C than the other, which could cancel all savings -
still, the difference shouldn't be *that* great).
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
