On Sunday, March 25, 2012 2:45:43 AM UTC+5:30, Aaron Meurer wrote: > > On Sat, Mar 24, 2012 at 3:04 PM, krastanov.ste...@gmail.com > <krastanov.ste...@gmail.com> 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. >
Thanks. I think I will mainly concentrate on matplotlib and svgfig for the GSOC project. Also, I will put the pyglet translation at the end of the summer. I will also be using experimental lambdify for writing the backend for both matplotlib and svgfig. Will it be a problem? Because I think experimental_lambdify might change a lot. By using experimental_lambdify we will have to make sure that experimental_lambdify should be in our code base. Thanks, Bharath M R > > > 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 > > On Sunday, March 25, 2012 2:45:43 AM UTC+5:30, Aaron Meurer wrote: > > On Sat, Mar 24, 2012 at 3:04 PM, krastanov.ste...@gmail.com > <krastanov.ste...@gmail.com> 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 > > On Sunday, March 25, 2012 2:45:43 AM UTC+5:30, Aaron Meurer wrote: > > On Sat, Mar 24, 2012 at 3:04 PM, krastanov.ste...@gmail.com > <krastanov.ste...@gmail.com> 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. > Thanks. I think I will mainly concentrate on matplotlib and svgfig for the GSOC project. Also, I will put the pyglet translation at the end of the summer. I will be using experimental lambdify for writing the backend for extending matplotlib backend and implementing svgfig backend. Will it be a problem? Because I think experimental_lambdify might change a lot. By using experimental_lambdify we will have to make sure that experimental_lambdify should be in our code base. Thanks, Bharath M R > -- You received this message because you are subscribed to the Google Groups "sympy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/2YxdBP6v4BkJ. 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.
