On Sat, Mar 31, 2012 at 5:07 AM, [email protected] <[email protected]> wrote: > My comments: > >> I will be using/modifying experimental_lambdify str2tree for parsing the >> expression. > > What do you mean by this? Can you give a very precise example? Do you > mean that you want to return a True/False answer for the inequality, > because this already works: > > In [1]: from sympy.plotting.experimental_lambdify import experimental_lambdify > In [3]: f = experimental_lambdify([x,y], x<y) > In [4]: f(1,1) > Out[4]: False > In [5]: f(1,2) > Out[5]: True > > A more complicated one: > In [15]: f = experimental_lambdify([x,y], x<integrate(1/sin(z), (z,0.1,y))) > In [16]: f(1,1.1) > Out[16]: True > > And a complication: > In [17]: f(1,2) > Out[17]: > > log(cos(2) + 1) > log(-1 + cos(2)) > - ─────────────── + 2.99489845376757 - 0.5⋅ⅈ⋅π + ──────────────── > 1 > 2 > 2 > > > >> During the initial stages, when I am not using my extended interval >> arithmetic library, I will be using lambdify for my evaluations. > > But if it works with lambdify, why do you need interval arithmetics? I > understand that my question is stupid by I really do not know the > answer. > >> When I start using my extended interval arithmetic library I will modify >> experimental_lambdify to evaluate functions differently( call the functions >> in Interval Arithmetic class). > > That would be great. > >> The recursion goes on till we reach to a block size of 1 pixel. > > Neither matplotlib nor svgfig nor any other high-level plotting > backend works well with points. Moreover, plotting points in svg will > be hard (you need rectangles, and not points if you wish to have > something useful for zooming). The one and only option that I see is > to use 2D numpy arrays and then matplotlib.showimage (and you will > have to reimplement this for svgfig). The plotting module that I have > written already depends on numpy so this will not limit the usability > any further. If someone wants to run this without numpy he can always > create a simple class emulating np arrays in lists. > >> Subpixel Computation probes into regions inside the pixel and decides >> whether the pixel has to be included. > > Same comment as above. > >> Interval Arithmetic > > More detailed examples of the class structure will be useful. Why do > you prefer to write the code twice (for mpmath and numpy) instead of > writing it directly in sympy. The reason of performance (which is a > very good reason) comes to mind, but on the other hand whatever you > write will be very hard to maintain. I think it would be better to > write it in sympy and then fix the places where evalf is slow. > > An argument against that is that mpi already does part of the work. > But you still have much to add. And you also want to repeat all this > for numpy. > > You have thought about this more than I have, so maybe your plan is > better. It is just still unclear to me what exactly will you > implement. > > Maybe it will be more productive to focus on mpi interval arithmetics > and leave numpy out. And it will be great if the mpi stuff is sent > upstream. Have you already contacted them? > >> svgfig Backend > > You speak about using numpy because GAE and other reasons, but > actually you do not have a choice. The plotting module depends > (although very loosely) on numpy. Evaluations are done in lambdify > which may or may not use numpy, but at the end the results are stored > in numpy arrays. On the other hand, creating a small class emulating > numpy arrays in list will be useful.
The AppEngine now supports numpy, so this is no longer an issue. 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.
