> 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).
I do not think that this was ever tried. The original logic was something like "multiprecision evalf is too slow, so translate everything in numpy". It is just that at some point it was decided to do the translation in the "lambdify" way instead what you just suggested (and Aaron suggested mostly the same thing when he proposed "expr.evalf(library=numpy)") flag. Deprecating lambdify and refactoring everything to use a new "library" keyword argument (or something similar) will be great though. -- 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.
