On Saturday, March 31, 2012 4:37:07 PM UTC+5:30, Stefan Krastanov 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. > Lambdify works, because mpmath functions can operate on mpmath intervals and give the right result. > > 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. > We will go to a depth of 1 pixel block, only if we cannot decide whether the previous block satisfies the equation or not. The blocks that are already satisfied are colored before and not added into the recursive list. I will be using the matplotlib's `fill_between` to color the blocks. > > Subpixel Computation probes into regions inside the pixel and decides > whether the pixel has to be included. > This is in the case of equality, when it matters whether the pixel has to be colored or not. > 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? > I haven't contacted them, because I wanted to figure out the all the functions that they have implemented. I am going through their sources to see the functions that they have not implemented. Also, something like domain tracking and continuity tracking do not add any functionality to general interval arithmetic. So I think it cannot be taken upstream. Still I will post the idea on their google group. I have been thinking and I feel implementing a new interval arithmetic library in symPy seems to be better idea. I wanted to have a working plotting module before I start writing the interval arithmetic library, so that I will have a better idea about the structure. As you said, I will be doing a lot of redundant things if I do that. I think I will change my application to have interval arithmetic done first. > > 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. > I haven't chosen svg because GAE offers numpy. I was telling that Numpy is an added bonus with GAE, hence I can straightaway use your experimental_lambdify. -- 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/-/kL1L_o1VXeoJ. 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.
