On Sat, Mar 24, 2012 at 3:04 PM, [email protected] <[email protected]> wrote: > The important part: > About the backend: I suppose (not sure) that the community will be > mostly interested in the svgfig backend. Then about pyglet: rewrite > will definitely be useful, as the current code is in the form of > spaghetti, but it will not be a very interesting task. I would leave > it for the end of gsoc if I have the time. I doubt that Google Charts > API will be used much (as you said it is not for plotting functions).
I agree with this. matplotlib (and I guess svgfig) are the most important. Pyglet can be translated, but put it at the end of the summer, as it's lower priority. > > A rant: > About lambdify and experimental_lambdify: > > IMO lambdify is an unpythonic abomination: > It tries to serve multiple unrelated and sometimes exclusive purposes > (1. compiler to numpy/mpmath, 2. useless additional syntax for `lambda > x: blah_x` 3. check all the other strange examples in the tests.). > > The tests and docstrings contradict each other (is it for "fast > _numerical_ calculations" or for this `lambda x : > UNevaluated_expression_of_x`) > > The code is unmaintainable: is it a compiler? If it is, where is the > AST tree processing? To what does it compile? The way that it uses > `exec` on an enormous uncontrolled namespace... Yes, I dislike this > piece of code very strongly. > > The lambdify function was created (according to git log) to be used > for fast(therefore not subs().evalf()) numerical(therefore numpy) > evaluation for use in the old plotting module. Then it got used in > other places for completely unrelated tasks. Then it evolved to take > care of those tasks (badly) but the documentation was not updated. > > My experimental_lambidify is slightly less ugly and it is good only > for numerical calculations (better than lambdify) but it can be > rewritten in a much cleaner way (using python AST). In the plotting > examples you can see all the cases where lambdify fails but > experimental_lambdify works. > > This all was just to point out how unsustainable the use of lambdify > is. I would like to see it removed (it will break some code). This is > my opinion on the question, but the core developers should decide. > > I propose to check all the places where lambdify is used in our > codebase (mostly numerical stuff like nsolve and the old plotting > module). Then test it with one of the many trivial expressions that > make it crash and the see what must be done to substitute it with > experimental_lambidify in this particular place (which has many rough > edges, but much less than lambidfy). That way lambdify can be removed. > This way there will be an api change in the next version, but it will > work better. Aside from our code base, a *lot* of people use lambdify, mostly to go from sympy to numpy. So I would try to get community input (probably on another thread) as well. Perhaps you could create a branch where lambdify is replaced with experimental_lambdify that people can test their code on. Are there any features of lambdify that are not in experimental_lambdify? Aaron Meurer -- 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.
