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.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
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.
