GSOC proposal (add plot functionality to sympy live and ascii plotting)
Bharath M R
Bharath M R
Sergiu Ivanov
> Text plotting is implemented to a certain extent in sympy.I missed that
> before
> And it looks very nice. What are the improvements that can be done?
While I am far from being critical or claiming any authority in the
domain, I'd still be interested to know: what is the main use-case of
ASCII plotting? I have never tried it and I must confess I can't
imagine an ASCII plot being useful; could anyone enlighten me, please?
:-)
Sergiu
Saptarshi Mandal
useful? I too am curious about the usefulness of ASCII plots.
Bharath M R
Sergiu
Bharath M R
A: Probably by constructing our strings ourself by traversing the (func,
| ||
Aaron Meurer
> Hi,
> I had previously expressed my desire to work on gamma.sympy.org parser.
> After the
> discussion in the group I realized I don't have the required expertise to
> write the parser which would
> satisfy the requirements. So I am changing the ideas for my GSOC proposal.
>
> 1) Support SVGFig for plotting on Google App Engine.
> SVGFig is completely written in python and can be run on Google App Engine.
> If we add the
> backend for plotting in SVGfig then we would be able to plot in sympy Live.
> I would like to
> implement the plotting backend for SVGfig and then integrate with sympy
> Live.
What about using the Google Chart's API, which is built-in to the App Engine.
>
> 2) Plotting module for ASCII plots.
> The idea of having a basic plotting module without any dependencies would be
> great.
> Ascii plotting will be also nice for people working on ipython so that they
> can see their
> results quickly. Both GNUPlot and Matplotlib provide this functionality. I
> would like to
> write the whole module so that there is no dependency.
I think it's useful, though not as important as matplotlib obviously.
I often find myself in an environment where it could be useful. If
you just want the basic idea of a plot in 2d, an ascii plot is often
enough. I wouldn't devote too much of the proposal to it, though.
>
> 3) Improve the matplotlib backend ( which is not merged) so that it can plot
> all
> sympy functions.
>
> I will create a wiki page detailing how I am going to do the above. Any
> suggestions for the
> above ideas?
>
> 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/-/rwA_cL3QyskJ.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
Bharath M R
Bharath M R
krastano...@gmail.com
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).
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.
Aaron Meurer
<krastano...@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.
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
krastano...@gmail.com
Moreover, the experimental_lambdify, while better than lambdify still
has many rough edges. I will document all this and bring it back
latter. Anyway, the gsoc project discussed here does not depend on
such changes.
Bharath M R
On Sunday, March 25, 2012 2:45:43 AM UTC+5:30, Aaron Meurer wrote:
On Sat, Mar 24, 2012 at 3:04 PM, krastano...@gmail.com
<krastano...@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.
On Sat, Mar 24, 2012 at 3:04 PM, krastano...@gmail.com
<krastano...@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
krastano...@gmail.com
> extending matplotlib backend and implementing svgfig backend.
> Will it be a problem? Because I think experimental_lambdify might change a
> lot.
will not have a choice as the code there depends on
experimental_lambdify. Using simply lambdify will not permit you to
plot a substantial part of the possible expressions as lambdify does
not support them. Anyway, experimental_lambdify is not public and the
docstring clearly explains that it is not ready for use outside the
plotting module.
Moreover, I doubt that you will have to use it. The backends do not
use it directly - the matplotlib backend is mostly done and the svgfig
backend can just mimic it and nowhere in that part of the code one
uses experimental_lambdify directly. Of course there are many
potential bugs to be fixed there, but this is another problem.
It would be more interesting to add another types of plots as
mentioned on the ideas page. This is the only reason you would have to
work on the matplotlib backend (besides bug fixes (the module is not
well tested so you will have many such fixes to do)).
Finally, I am not a professional programmer and it may turn out that
the code I have written is an unsustainable mess :) (hopefully it is
not). Before starting work on it, you should really review it and
criticize strongly any drawbacks that you see, even if they are in the
basic architecture of the module.
Bharath M R
On Sunday, March 25, 2012 5:36:38 PM UTC+5:30, Stefan Krastanov wrote:
> 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.
If you use https://github.com/sympy/sympy/pull/673 for your work, you
will not have a choice as the code there depends on
experimental_lambdify. Using simply lambdify will not permit you to
plot a substantial part of the possible expressions as lambdify does
not support them. Anyway, experimental_lambdify is not public and the
docstring clearly explains that it is not ready for use outside the
plotting module.Moreover, I doubt that you will have to use it. The backends do not
use it directly - the matplotlib backend is mostly done and the svgfig
backend can just mimic it and nowhere in that part of the code one
uses experimental_lambdify directly. Of course there are many
potential bugs to be fixed there, but this is another problem.It would be more interesting to add another types of plots as
mentioned on the ideas page. This is the only reason you would have to
work on the matplotlib backend (besides bug fixes (the module is not
well tested so you will have many such fixes to do)).
Finally, I am not a professional programmer and it may turn out that
the code I have written is an unsustainable mess :) (hopefully it is
not). Before starting work on it, you should really review it and
criticize strongly any drawbacks that you see, even if they are in the
basic architecture of the module.
Joachim Durchholz
> I am in favor of using experimental_lambdify explicitly for plotting and
> nothing else. I think this will allow us to separate the plotting module
> from the main codebase. This I think will allow us to add more features
> to the plotting backend without having to worry about breaking the
> features of sympy. Though this will have lots of code duplication, I think
> it is justified by the ease with which we can add/ manipulate evaluation of
> series for plotting.This is just my opinion which might not agree with
> software programming practices.
Software programming practices generally agree :-)
One exception though: It is advisable to move the duplicate code into a
common function or class, and call it from the places where the original
code was ripped out.
Particular care should be taken to make the new deduplicated code so
that it has a nice, as-narrow-as-possible interface. (A "narrow"
interface is one that has a small number of functions, with short
parameters lists, and a small number of preconditions under which a
function may be called. The narrower the better.)
krastano...@gmail.com
>
> One exception though: It is advisable to move the duplicate code into a
> common function or class, and call it from the places where the original
> code was ripped out.
> Particular care should be taken to make the new deduplicated code so that it
> has a nice, as-narrow-as-possible interface. (A "narrow" interface is one
> that has a small number of functions, with short parameters lists, and a
> small number of preconditions under which a function may be called. The
> narrower the better.)
start to hate the name that I choose :)
lambdify has evolved to be used in several strange ways, but it is
important for numerical evaluation. The problem is that it does not
work very well.
experimental_lambdify works better but lacks some of the features (and
bugs) of lambdify.
They are both well separated from the rest of the code base.
lambdify is not very narrow (quite narrow according to the
documentation, not narrow at all in the real and undocumented way in
which it is used).
experimental_lambdify is very narrow.
They are both far from the best solution.
krastano...@gmail.com
> field
> plots etc. That would require me to use numpy for getting the points and
> I think I will have to use the experimental_lambdify.
Vector field plots will use experimental_lambdify in a very trivial
way (check any other DataSeries class for an example).
Implicit plots are the most interesting and important addition. They
are quite nontrivial. I do not know how you plan to implement them.
Joachim Durchholz
> lambdify is not very narrow (quite narrow according to the
> documentation, not narrow at all in the real and undocumented way in
> which it is used).
>
> experimental_lambdify is very narrow.
I meant to talk about the common code that could be factored out.
krastano...@gmail.com
after some testing and refactoring only one should survive) however
they achieve them in very different ways.
Aaron Meurer
You should also thinking about changing the interface as presently
given in that pull request. I'm not a fan of trying to squash all
possible plot types into a single interface. Sure, plot() can try to
guess what is meant by the user, but I think the main interface should
be either several functions, or else keyword arguments to plot(), to
specify exactly what kind of plot you want.
And even as it is now, I'm not a fan of the confusing way you have to
do things to plot multiple equations at once.
>
>>
>> Finally, I am not a professional programmer and it may turn out that
>> the code I have written is an unsustainable mess :) (hopefully it is
>> not). Before starting work on it, you should really review it and
>> criticize strongly any drawbacks that you see, even if they are in the
>> basic architecture of the module.
>
> Even I am not a professional programmer. I learnt programming mostly
> to solve algorithmic problems and implement most of the things I need
> in Electrical Engineering. I have gone through most of your code and it
> looks fine to me, though experimental_lambdify looks a more like
> a hack at certain places which you have acknowledged in the QnA and the
> comments..
Don't worry, very few of us are professional programmers :)
This is why we have code review, so that even if you end up doing it
wrong, maybe someone else will notice it and point you in the right
direction. IMHO, you end up with much better code with
non-professional programmers and a review process than with
professional programmers with no review process.
Aaron Meurer
> I am in favor of using experimental_lambdify explicitly for plotting and
> nothing else. I think this will allow us to separate the plotting module
> from the main codebase. This I think will allow us to add more features
> to the plotting backend without having to worry about breaking the
> features of sympy. Though this will have lots of code duplication, I think
> it is justified by the ease with which we can add/ manipulate evaluation of
> series for plotting.This is just my opinion which might not agree with
> software programming practices.
> 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/-/5bsHQeNh5L4J.
Joachim Durchholz
> IMHO, you end up with much better code with
> non-professional programmers and a review process than with
> professional programmers with no review process.
As a professional programmer, I can fully confirm that.
krastano...@gmail.com
> given in that pull request. I'm not a fan of trying to squash all
> possible plot types into a single interface. Sure, plot() can try to
> guess what is meant by the user, but I think the main interface should
> be either several functions, or else keyword arguments to plot(), to
> specify exactly what kind of plot you want.
in the docstring). The original more explicit interface is still
there. I have added plot() after there were some requests for more
automatic and short way to create interactive plots. Of course one can
add even more explicit functions like plot_surface and so on, but
those will be one line functions.
>
> And even as it is now, I'm not a fan of the confusing way you have to
> do things to plot multiple equations at once.
plot multiple equations (actually it was the same interface that you
proposed).
krastano...@gmail.com
fairly easy to add for 2d and quite useful is adaptive resolution and
discontinuity detection.
Aaron Meurer
part of the plot automatically when you don't specify a range.
Aaron Meurer
Bharath M R
Bharath M R
Aaron Meurer
to include it. You could also look at the references and the final
section for ways to improve upon it. Does the mpmath mpi object
provide the functionality needed for this algorithm?
An idea for discontinuity detection would be to do it symbolically.
This would involve writing a framework for doing this, which would be
useful outside of graphing as well. Even if this is limited, it could
still produce better results for those expressions that it works for.
Aaron Meurer
> --
> 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/-/D78kFyCp6uMJ.
someone
> [...] the paper I mentioned for implicit equation
> plotting(http://dl.acm.org/citation.cfm?doid=383259.383267).
I read that paper this evening, and I think that if we
can implement all up to algorithm 3.4 this would be
really great!
Probably, this would give us the most advanced FOSS
plot routines available for two-dimensional plotting
of (symbolic) expressions and functions.
For example, the star in figure 15 is awesome,
I never imagined it to be possible to plot such
things by using mathematical functions!
Aaron Meurer
numerics, not just numpy. Figure 13 is an equation that enumerates
all possible j x 17 bitmaps. The one for k =
9960939379918958884971672962127852754715004339660129306651505519271702802395266424689642842174350718121267153782770623355993237280874144307891
325963941337723487857735749823926629715517173716995165232890538221612403238855866184013235585136048828693337902491454229288667081096184496091
705183454067827731551705405381627380967602565625016981482083418783163849115590225610003652351370343874461848378737238198224849863465033159410
054974700593138339226497249461751545728366702369745461014655997933798537483143786841806593422227898388722980000748404719
just happens to be one that looks like the equation itself. Clearly
we need a high precision library like mpmath to do this.
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
someone
> This also shows that we should definitely support using mpmath to do
> numerics, not just numpy.
The question is for speed, I assume numpy to be much
faster than mpmath. Maybe one should support both
as "backends" for the interval arithmetic.
> Figure 13 is an equation that enumerates
> all possible j x 17 bitmaps. The one for k =
> 9960939379918958884971672962127852754715004339660129306651505519271702802395266424689642842174350718121267153782770623355993237280874144307891
> 325963941337723487857735749823926629715517173716995165232890538221612403238855866184013235585136048828693337902491454229288667081096184496091
> 705183454067827731551705405381627380967602565625016981482083418783163849115590225610003652351370343874461848378737238198224849863465033159410
> 054974700593138339226497249461751545728366702369745461014655997933798537483143786841806593422227898388722980000748404719
> just happens to be one that looks like the equation itself.
A nice example, too :-)
> Clearly we need a high precision library like mpmath to do this.
And we need a very good interval arithmetic library.
What is available inside of mpmath? What is missing?
How to implement the missing parts?
All these questions are obviously part of the project
although they do not deal with plotting directly.
Bharath M R
On Tuesday, March 27, 2012 5:20:55 AM UTC+5:30, rl wrote:
Hi,
> This also shows that we should definitely support using mpmath to do
> numerics, not just numpy.The question is for speed, I assume numpy to be much
faster than mpmath. Maybe one should support both
as "backends" for the interval arithmetic.
> Figure 13 is an equation that enumerates
> all possible j x 17 bitmaps. The one for k =
> 9960939379918958884971672962127852754715004339660129306651505519271702802395266424689642842174350718121267153782770623355993237280874144307891
> 325963941337723487857735749823926629715517173716995165232890538221612403238855866184013235585136048828693337902491454229288667081096184496091
> 705183454067827731551705405381627380967602565625016981482083418783163849115590225610003652351370343874461848378737238198224849863465033159410
> 054974700593138339226497249461751545728366702369745461014655997933798537483143786841806593422227898388722980000748404719
> just happens to be one that looks like the equation itself.A nice example, too :-)
> Clearly we need a high precision library like mpmath to do this.
And we need a very good interval arithmetic library.
What is available inside of mpmath? What is missing?
How to implement the missing parts?
krastano...@gmail.com
interesting than just adding a backend / plot type, I was wondering
what are you thinking about the structure of the module. Do you think
that you will need to restructure the module for example? How will the
interval arithmetics couple to lambdify?
Moreover, concerning lambdify, do you think that you will have to work
on it? I am asking as there is an extensive todo list for that piece
of code that can make your work unnecessary hard. Especially if
lambdify and the interval arithmetics are not well separated.
Finally, have you fulfilled your patch requirement? If you need any
help with this, just ping us.
Aaron Meurer
feedback on it. Something to think about: you have a lot of ideas and
you may not be able to get to all of them over the summer. This is
fine, but you should think about prioritizing them so that you do the
most important things first, and put the less important things to the
end of the summer for if you have time. Consider not only the
relative importance of each idea, but also which things will depend on
one another (e.g., will you need to fix up the structure of the new
plotting module before implementing this algorithm, or can they be
done independently?).
Aaron Meurer
Bharath M R
On Wednesday, March 28, 2012 2:42:34 AM UTC+5:30, Stefan Krastanov wrote:
@Bharath, as the ideas for your project are becoming much more
interesting than just adding a backend / plot type, I was wondering
what are you thinking about the structure of the module. Do you think
that you will need to restructure the module for example? How will the
interval arithmetics couple to lambdify?
Moreover, concerning lambdify, do you think that you will have to work
on it? I am asking as there is an extensive todo list for that piece
of code that can make your work unnecessary hard. Especially if
lambdify and the interval arithmetics are not well separated.
Finally, have you fulfilled your patch requirement? If you need any
help with this, just ping us.
Thanks,
Bharath M R
On Wednesday, March 28, 2012 4:16:59 AM UTC+5:30, Aaron Meurer wrote:
You should also start writing up your application, so you can get some
feedback on it. Something to think about: you have a lot of ideas and
you may not be able to get to all of them over the summer. This is
fine, but you should think about prioritizing them so that you do the
most important things first, and put the less important things to the
end of the summer for if you have time. Consider not only the
relative importance of each idea, but also which things will depend on
one another (e.g., will you need to fix up the structure of the new
plotting module before implementing this algorithm, or can they be
done independently?).
Aaron Meurer
On Tue, Mar 27, 2012 at 3:12 PM, krastano...@gmail.com
<krastano...@gmail.com> wrote:
> @Bharath, as the ideas for your project are becoming much more
> interesting than just adding a backend / plot type, I was wondering
> what are you thinking about the structure of the module. Do you think
> that you will need to restructure the module for example? How will the
> interval arithmetics couple to lambdify?
>
> Moreover, concerning lambdify, do you think that you will have to work
> on it? I am asking as there is an extensive todo list for that piece
> of code that can make your work unnecessary hard. Especially if
> lambdify and the interval arithmetics are not well separated.
>
> Finally, have you fulfilled your patch requirement? If you need any
> help with this, just ping us.
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+unsubscribe@googlegroups.com.
someone
> > You should also start writing up your application, so you can get
> > some feedback on it. Something to think about: you have a lot of
> > ideas and you may not be able to get to all of them over the
> > summer. This is fine, but you should think about prioritizing them
> > so that you do the most important things first, and put the less
> > important things to the end of the summer for if you have time.
> > Consider not only the relative importance of each idea, but also
> > which things will depend on one another (e.g., will you need to fix
> > up the structure of the new plotting module before implementing
> > this algorithm, or can they be done independently?).
>
>
> I have started working on my application. I think it will be ready by
> Friday.
> I am thinking about implementing the svgfig plotting backend at the
> end of summer, if I have time.
> I want to purely concentrate on interval arithmetic and the implicit
> plotting
> module. I won't be fixing the structure of the new plotting module as
> they are not at all dependent of each other. The primary goal of my
> plotting module will be the ability to plot implicit functions, while
> the plotting module by Krastanov will handle functions of the type
> y = f(x) . So I think they will be completely independent.
No they are not independent, at least not if you use the algorithms in the paper:
"Reliable Two-Dimensional Graphing Methods for Mathematical Formulae with Two Free Variables".
If you can plot f(x,y) = 0 then you get the case y = f(x) for free!
> I would like to know whether I can edit mpmath codebase in sympy.
> This is necessary as mpmath interval arithmetic library does not
> support all the functions.
These additions should better find their way upstream into the
mpmath sources. But I assume you could do this later.
> Also I would like to extend their module to allow property checking.
> What do you think will be better?
Is property checking a worthwhile goal in general interval arithmetic
or is it just a helper tool for plotting?
krastano...@gmail.com
the applications.
> I want to purely concentrate on interval arithmetic and the implicit
> plotting
the discontinuity detection described in the paper?). However, be
*extremely* wary about not rediscovering the wheel when you work on
interval arithmetics. It is very important to use mature code base for
that and not reimplement everything from scratch.
> I won't be fixing the structure of the new plotting module as they
> are not at all dependent of each other. The primary goal of my plotting
> module will be the ability to plot implicit functions, while the plotting
> module
> by Krastanov will handle functions of the type y = f(x) . So I think they
> will be
> completely independent.
need to create a Series subclass, otherwise your stuff will have to be
handled explicitly by every single backend that we may add in the
future and this will not be sustainable. But this should not be a
problem, as you still have complete liberty in your approach.
> The only problem will be whether I will be using experimental_lambdify?
> Yes. I will be using experimental_lambdify to evaluate functions. I think I
> won't have the time to work on it though.
problems. If you need something else, there will be many problems.
>
> I would like to know whether I can edit mpmath codebase in sympy. This is
> necessary as mpmath interval arithmetic library does not support all the
> functions.
> Also I would like to extend their module to allow property checking. What do
> you
> think will be better?
them with your questions.
krastano...@gmail.com
ImplicitSeries(BaseSeries) and a function plot_implicit that just
calls Plot(ImplicitSeries) and implement everything there. Then we can
remove from the code that I have written the useless stuff and
substitute it with yours.
You can just create another py file with those two objects and work
from there. That way the api is unified but the different algorithms
are well separated.
Bharath M R
On Wednesday, March 28, 2012 8:19:22 PM UTC+5:30, Stefan Krastanov wrote:
I think that the cleanest solution in terms of API is to create class
ImplicitSeries(BaseSeries) and a function plot_implicit that just
calls Plot(ImplicitSeries) and implement everything there. Then we can
remove from the code that I have written the useless stuff and
substitute it with yours.
You can just create another py file with those two objects and work
from there. That way the api is unified but the different algorithms
are well separated.
Alan Bromborsky
--
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/-/8gs-3oskAAEJ.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Bharath M R
Ronan Lamy
> I would like to know whether I can edit mpmath codebase in sympy. This
> is necessary as mpmath interval arithmetic library does not support
> all
> the functions. Also I would like to extend their module to allow
> property checking. What do you think will be better?
No, non-trivial changes *must* be made upstream. Otherwise we'd be
creating a fork of mpmath.
Alexey U. Gudchenko
Bharath M R
krastano...@gmail.com
> What would be the best way to implement the new functions. I don't think
> mpmath will consider taking in the code for domain tracking in functions
> into their codebase, as it doesn't serve any purpose for them. One way is
> to derive from mpi class and create the required functions. Is there any
> better option?
>
am sure that they will be interested in good interval arithmetics. The
lead developer of mpmath is on the list, so you should ask him
directly.
Bharath M R
> I would like to know whether I can edit mpmath codebase in sympy.
> This is necessary as mpmath interval arithmetic library does not
> support all the functions.These additions should better find their way upstream into the
mpmath sources. But I assume you could do this later.> Also I would like to extend their module to allow property checking.
> What do you think will be better?Is property checking a worthwhile goal in general interval arithmetic
or is it just a helper tool for plotting?
krastano...@gmail.com
> like to handle plots like y < sqrt(x).
> mpmath gives a result something like below for sqrt([-0.5,0.5])
>
> In [10]: a = iv.mpf([-0.5,0.5])
> In [11]: a**0.5
> Out[11]: ([-0.70710678118654757274, 0.70710678118654757274] +
> [-0.70710678118654757274, 0.70710678118654757274]*j)
I don't get this. How is interval arithmetics defined over the complex numbers?
Are you saying that there is a bug in mpmath's interval arithmetics?
Bharath M R
krastano...@gmail.com
result. Can you give an explicit example why the implementation in
mpmath does not do what you want. After all [-5,-3] is indeed less
than [-0.5, 0.5] in the example that you supplied.
krastano...@gmail.com
made upstream for the plotting module to work well. Just be mindful of
that.
Aaron Meurer
I guess you should write to their mailing list and ask. If they
consider it outside the scope of mpmath, I think the subclassing mpi
idea should work.
Aaron Meurer
Aaron Meurer
stuff and put it into sympy/interactive, and then have the IPython
sympy profile just call that. That we, we can easily modify it
without having to send patches to IPython. It would also make it easy
to implement isympy -c qtconsole and isympy -c notebook.
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
Bharath M R
Joachim Durchholz
> Sorry. I gave the wrong example.
> a**0.5> b will give an exception saying complex
> numbers cannot be compared. This functionality is right, but
> the exception won't help in plotting. I wan't to have a property
> which turns false seeing which of the arguments for a is negative.
You can't compare complex numbers, but you can compare real and
imaginary parts.
> It is possible to catch the exception and not plot the points where
> I received an exception.
That sounds useful to me.
The user needs to know that the plot is incomplete.
And, preferably, why (but be sure not to drown him in a gazillion
problem reports if a gazillion points can't be plotted.
> The paper says it will give erroneous plots,
> which I am not sure.
My guess is that he's talking about exceptions caused by software bugs
(as opposed to math failure).
In that case, the plot will not have all points.
It is extremely hard to classify exceptions as "this is a failure of the
math" (i.e. domain errors) or "this is a software bug".
It is much better to filter out invalid-domain constellations before
running the function you're trying to plot.
Bharath M R
On Thursday, March 29, 2012 11:38:34 AM UTC+5:30, Joachim Durchholz wrote:
Am 29.03.2012 04:16, schrieb Bharath M R:
> Sorry. I gave the wrong example.
> a**0.5> b will give an exception saying complex
> numbers cannot be compared. This functionality is right, but
> the exception won't help in plotting. I wan't to have a property
> which turns false seeing which of the arguments for a is negative.You can't compare complex numbers, but you can compare real and
imaginary parts.> It is possible to catch the exception and not plot the points where
> I received an exception.That sounds useful to me.
The user needs to know that the plot is incomplete.
And, preferably, why (but be sure not to drown him in a gazillion
problem reports if a gazillion points can't be plotted.
Joachim Durchholz
>
> The plot is not "incomplete". The user will be plotting on Real
> Cartesian coordinates and complex numbers are not part of it.
> Hence not plotting the points is the right way to do it and you need
> not give any information to the user that the plot is incomplete.
Ah. Then I didn't understand what the problem is that you're having.
Can you clarify?
Bharath M R
Bharath M R
Alan Bromborsky
--
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/-/viS6iaIBrWIJ.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
krastano...@gmail.com
> https://github.com/sympy/sympy/wiki/GSoC-2012-Application--Bharath-M-R-:-Plotting-Module.
> Can you please review the application and suggest any changes?
Before giving my feedback I should repeat yet one more time that I am
not among those that decide which applications get accepted.
# In synopsis:
I think that you mean a backend and not a whole new module when you
speak about svgfig.
# In week 1:
What do you mean by parse implicit functions? Anyway, you should not
overcharge lambdify with stuff it was not meant to be. This is the
reason that the old lambdify is such a mess. If you need some
functionality from lambdify just use it in whatever abstraction you
need to build.
There are a few problems with the syntax that you are proposing. You
are using strings instead of expressions, you are using lists instead
of tuples and the order of the arguments is not the one used in other
parts of sympy.
# In week 3:
The mpmath stuff should be discussed with them *much* in advance.
# In week 4:
I do not get the example with min and max (and they are not
necessarily binary in python). Moreover, could you elaborate on what
subpixel computation is and why do we need it. Finally, what is the
use for `IntervalSet`.
# Week 6
Branch cut plotting?
# Week 7
Why is this not possible already by week 1. What is so special about x**(1/3)
# Week 8
About "ploting every 2D function". Be aware that there are some
nontrivial expression (the old lambdify does not work on them, the new
one usually works). Will you be able to plot for example
`Integral(awful_expression_of_x, (x,y,z)) <
real(complex_valued_expression_of_y_and_z`)?
# Week 9
Could you elaborate? I do not get a clear idea what you mean here.
# Week 12
Elaborate on what do you need this adaptive method for? Is it part of
all that is implemented already? Is it well abstracted, so there is no
code duplication?
One last important thing. I was left with the impression that you will
rely on experimental_lambdify to return mpmath functions. This is not
what experimental_lambdify does. The only cases when mpmath is used in
this function is when there is no numpy function to translate to
(which happens often), however even then mpmath is hidden in the
evalf() methods of the expressions.
The old lambdify can return mpmath functions but it works on a *very*
limited subset of sympy expressions.
In one sentence: if you rely only on mpmath or numpy for evaluation
you will be able to plot only a very limited subset of expressions.
Maybe a useful idea will be to implement your interval arithmetics
directly in sympy independently of the library that actually does the
computations.
krastano...@gmail.com
the possibility to do implicit plots that good in sympy. Good luck
with the project.
You may want to compare this to RegionPlot and co. from Mathematica.
krastano...@gmail.com
thing that I see as very problematic - the interval arithmetics
implementation:
For example we want to evaluate Integral(awful_expressions_of_x,
(x,0,y)) with respect to y.
lambdify will fail to produce a numeric value.
experimental_lambdify will succeed by using evalf (there are also
checks for complex number, for numpy functions and what not, but in
this case they are not important). Evalf is using mpmath for that
evaluation. But how will you force it to use mpi?
krastano...@gmail.com
> (x,0,y)) with respect to y.
>
> lambdify will fail to produce a numeric value.
> experimental_lambdify will succeed by using evalf (there are also
> checks for complex number, for numpy functions and what not, but in
> this case they are not important). Evalf is using mpmath for that
> evaluation. But how will you force it to use mpi?
It seems that if you implement the interval arithmetics in one of the
numerical libraries instead of sympy itself you guarantee the
existence of expressions that can not be evaluated. But I may be
wrong, I don't know enough about this part of sympy.
Aaron Meurer
- The link http://www.shaatra.org/2011/main/home takes me nowhere.
- Include Tupper's thesis in the references section.
- As Stefan noted, the syntax in your pseudo-code is not the best:
You should use expressions instead of strings. The expression should
go first (ideally, including the interval would be optional, and it
would just compute it automatically). You have to somehow note which
interval is for x and which is for y; there's no way for it to know
which one you want to be on which axis.
- min and max are called Min and Max in SymPy.
- Assumedly the min/max example is wrong. They should have more than
one argument.
- You have an extra bracket in the first week 3 example.
- I think abs, floor, and acos are all implemented in mpmath already.
- I'm also confused about x**(1/3). I understood the paper to mean
that it has difficulty with "exponential" functions like exp(x).
- In the "Continuity Tracking" section, you need to add newlines before the *'s.
- Could you talk a little more about how much will be involved in
writing the interval library for numpy?
- Note where the midterm is in the timeline.
- "Get the code reviewed in week 11" is not good. You should be
submitting your code for review whenever you have an atomic patch.
Otherwise, you will develop a very large branch that will be very
difficult for us to review, and it will be very likely to take a long
time before it can get merged. Many GSoC students in the past have
done this (myself included), and have had branches not merged for a
long time as a result.
Actually, I think this is something we need to make an extra effort to
do better this year, so I'll start a new discussion on it.
- As I've told all the other students so far, please include a list of
your contributions to SymPy, so that we can see what you've done so
far, and so that we know that you've completed the patch requirement.
- Go ahead and submit this at google-melange.com. You will be able to
modify it up to the deadline. This way, it will be there, so you
won't have to worry if you have any issues as the deadline approaches.
Also, it will allow the mentors to get a head start on privately
reviewing your application, which help us tremendously.
Aaron Meurer
> --
> 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/-/viS6iaIBrWIJ.
Alexey U. Gudchenko
With the similar notes as Stefan wrote ("I am not among those that
decide which applications get accepted.") I have only two remarks.
The first one:
* Project Synopsis.
...
a)
> SymPy already has an plotting module for plotting explicit functions.
> I would like to implement the plotting module for implicit funtions.
...
b)
> I will also implement a plotting backend for svgfig and integrate it
with SymPy Live
My vision of the use-case for the plotting is like those:
User
----
(1. work with the SymPy CAS)
2. want to plot something:
- determine the command what to plot, what the expression to plot
(explicit functions, implicit functions, etc)
3. tune the visualization (grid, labels, colors, scale).
Stefan's branch classifed those options on a few classes.
4. Use resulted plot further (convert to other formats: pixeslized
png, jpg. for vectors graphic - eps, pdf)
Plot module
-----------
1. Receive user's request
2. Analyze and allocates what type of plot it is.
3. Solve something if it is needed with the help of Sympy
or other modules.
4. Prepare intermediate set of meta-data, which are common for the
all of rendereres or backends : points (or lambdefy),
text for labels, axes, pathes for splines.
5. Prepare the meta-data specific for the chosen render.
(e.g. for matplot prepeare lambdefy, arrays,
options), what render have to draw.
For pixels it can be one meta-data, for vectors - not
necessary the same.
6. render it
Renderer
--------
1. render it to png
2. render it to svg
3. other formats
Shell (ipython, python, qtconsole, livesympy, browser)
------------------------------------------------------
1. receive rendered data and show it.
2. give users some control (scale by keyboard, or convert to other formats)
I guess that your task (a) is related with one parts (Plot 2,3,4), while
(b) with the another (render, shell).
I would to concentrate on one task.
The second remark is about svgfig.
I think that it is an extra layer. despite the fact that he has some
features.
The one feature: It can plot.
Draw axes, calculate pythonic expression). Example is described in [1].
But at the same time this is and limitation too:
- we must convert what we want to draw to the string. String which
svgfig understand.
- we depends on the not implemented options, of this bugs and restrictions.
Imagen that we want in SymPy plotter something that is not implemented
or not fixed in svgfig)
Moreover, if we will (possibly, as I don't know exactly) prepare
meta-data which the same for the all renderer (Plot 4.), then it is the
duplicates of code and a-synchronized behavior.
Another featcher of this module is that, that module uses SVG.
It is noteworthy, but there is no problems to use SVG directly.
In this case we can control and tune the desired result not dependent on
svgfig.
At least the example [2] of svgfig
>>> from svgfig import *
>>> s = SVG("rect", x=10, y=10, width=60, height=60)
>>> print s.xml()
<rect x="10" y="10" width="60" height="60" />
I don't see a big problem to create this with the help of primitive
'xml.dom'.
So in your application I would to concentrate on one task: (a) or (b).
All the more so the (a) have more described details in yor application.
But, it seems, have more problems too, which are not pure the technical
problems.
[1] http://code.google.com/p/svgfig/wiki/PlottingTutorial
[2] http://code.google.com/p/svgfig/wiki/Introduction
--
Alexey Gudchenko
Bharath M R
One last important thing. I was left with the impression that you will
rely on experimental_lambdify to return mpmath functions. This is not
what experimental_lambdify does. The only cases when mpmath is used in
this function is when there is no numpy function to translate to
(which happens often), however even then mpmath is hidden in the
evalf() methods of the expressions.
The old lambdify can return mpmath functions but it works on a *very*
limited subset of sympy expressions.
In one sentence: if you rely only on mpmath or numpy for evaluation
you will be able to plot only a very limited subset of expressions.
Maybe a useful idea will be to implement your interval arithmetics
directly in sympy independently of the library that actually does the
computations.
Bharath M R
On Friday, March 30, 2012 11:41:42 PM UTC+5:30, Aaron Meurer wrote:
This looks very good so far. Here are some comments:- The link http://www.shaatra.org/2011/main/home takes me nowhere.
- Include Tupper's thesis in the references section.
- As Stefan noted, the syntax in your pseudo-code is not the best:
You should use expressions instead of strings. The expression should
go first (ideally, including the interval would be optional, and it
would just compute it automatically). You have to somehow note which
interval is for x and which is for y; there's no way for it to know
which one you want to be on which axis.- min and max are called Min and Max in SymPy.
- Assumedly the min/max example is wrong. They should have more than
one argument.- You have an extra bracket in the first week 3 example.
- I think abs, floor, and acos are all implemented in mpmath already.
- I'm also confused about x**(1/3). I understood the paper to mean
that it has difficulty with "exponential" functions like exp(x).
- In the "Continuity Tracking" section, you need to add newlines before the *'s.
- Could you talk a little more about how much will be involved in
writing the interval library for numpy?- Note where the midterm is in the timeline.
- "Get the code reviewed in week 11" is not good. You should be
submitting your code for review whenever you have an atomic patch.
Otherwise, you will develop a very large branch that will be very
difficult for us to review, and it will be very likely to take a long
time before it can get merged. Many GSoC students in the past have
done this (myself included), and have had branches not merged for a
long time as a result.Actually, I think this is something we need to make an extra effort to
do better this year, so I'll start a new discussion on it.- As I've told all the other students so far, please include a list of
your contributions to SymPy, so that we can see what you've done so
far, and so that we know that you've completed the patch requirement.- Go ahead and submit this at google-melange.com. You will be able to
modify it up to the deadline. This way, it will be there, so you
won't have to worry if you have any issues as the deadline approaches.
Also, it will allow the mentors to get a head start on privately
reviewing your application, which help us tremendously.Aaron Meurer
On Fri, Mar 30, 2012 at 10:40 AM, Bharath M R <catchmr...@gmail.com> wrote:
> My GSoC Application can be found at
> https://github.com/sympy/sympy/wiki/GSoC-2012-Application--Bharath-M-R-:-Plotting-Module.
> Can you please review the application and suggest any changes?
>
> 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/-/viS6iaIBrWIJ.
>
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to
Bharath M R
The second remark is about svgfig.
I think that it is an extra layer. despite the fact that he has some
features.The one feature: It can plot.
Draw axes, calculate pythonic expression). Example is described in [1].
But at the same time this is and limitation too:
- we must convert what we want to draw to the string. String which
svgfig understand.
- we depends on the not implemented options, of this bugs and restrictions.
krastano...@gmail.com
> 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.
krastano...@gmail.com
expressions like integrals and so on. You said that it is because the
behavior between the end points is important for the calculations. But
I think that it is extremely important to support all expressions in
sympy, thus my question:
Is it possible just to have a simpler and inexact interval arithmetics
for all the expressions that are not explicitly supported by your
code?
A simple linear or quadratic interpolation should do the trick in most cases.
Otherwise your code will be useful only for a very constrained subset
of sympy functions (no special functions (gamma or bessel), integrals,
nsolve expressions and so on).
krastano...@gmail.com
> In [17]: f(1,2)
> Out[17]:
>
> log(cos(2) + 1)
> log(-1 + cos(2))
> - ─────────────── + 2.99489845376757 - 0.5⋅ⅈ⋅π + ──────────────── > 1
> 2
> 2
The problem here seems to be in the rounding:
In [32]: a = log(cos(y) - 1)/2 - log(cos(y) + 1)/2 + 2.99489845376757 - 1j*pi/2
In [33]: a.subs(y, 2).evalf()
Out[33]: 3.43792117788449 - .0e-21⋅ⅈ
In [34]: a.subs(y,1.1).evalf()
Out[34]: 2.50567973267913
Alexey U. Gudchenko
On 31.03.2012 15:43, krastano...@gmail.com wrote:
>> 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
>
> The problem here seems to be in the rounding:
>
> In [32]: a = log(cos(y) - 1)/2 - log(cos(y) + 1)/2 + 2.99489845376757 - 1j*pi/2
>
> In [33]: a.subs(y, 2).evalf()
> Out[33]: 3.43792117788449 - .0e-21⋅ⅈ
>
There is undocumented chop parameter for evalf
In [9]: a.subs(y, 2).evalf(chop=True)
Out[9]: 3.43792117788449
Which is like the chop function from mpmath library.
--
Alexey Gudchenko
Bharath M R
> 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.
Bharath M R
On Saturday, March 31, 2012 4:43:41 PM UTC+5:30, Stefan Krastanov wrote:
Also you said that your interval arithmetics will not support
expressions like integrals and so on. You said that it is because the
behavior between the end points is important for the calculations. But
I think that it is extremely important to support all expressions in
sympy, thus my question:Is it possible just to have a simpler and inexact interval arithmetics
for all the expressions that are not explicitly supported by your
code?
A simple linear or quadratic interpolation should do the trick in most cases.
Otherwise your code will be useful only for a very constrained subset
of sympy functions (no special functions (gamma or bessel), integrals,
nsolve expressions and so on).
krastano...@gmail.com
> functions
> I implement in interval arithmetic, then it can be handled.
But many do not simplify. And when an expression is hard to understand
(a complicated integral for example) one tries to plot it to get more
information. It is not only integrals, there are also nsolve
expressions, infinite sums and so many other thing that are not
restricted to the small number of mpmath functions.
>>
>> A simple linear or quadratic interpolation should do the trick in most
>> cases.
>>
>
> For gamma/ bessel functions we can use interval arithmetic based on their
> series expansions. As the recursion goes from a larger block to a smaller
> block, it is impossible without knowing how the function behaves to do
> interval
> arithmetic. A linear/ quadratic interpolation is equivalent to series
> expansion and
> hence can be done, though it has to be atleast quadratic to get decent
> results.
>
If you are saying that interpolations (not power series expansions as
they are not the same thing in the general case) are good enough, then
why not use them also for integrals and all the other complicated
expressions that can not be expressed in mpi?
I may very well be mistaken, but to me it seems like you will try to
extend mpmath a bit and then be forced to redo all this in sympy using
interpolations for all the expressions that can not be translated to
mpmath.
Bharath M R
On Saturday, March 31, 2012 10:07:15 PM UTC+5:30, Stefan Krastanov wrote:
> If the integral can be simplified to an expression that contains the
> functions
> I implement in interval arithmetic, then it can be handled.But many do not simplify. And when an expression is hard to understand
(a complicated integral for example) one tries to plot it to get more
information. It is not only integrals, there are also nsolve
expressions, infinite sums and so many other thing that are not
restricted to the small number of mpmath functions.>>
>> A simple linear or quadratic interpolation should do the trick in most
>> cases.
>>
>
> For gamma/ bessel functions we can use interval arithmetic based on their
> series expansions. As the recursion goes from a larger block to a smaller
> block, it is impossible without knowing how the function behaves to do
> interval
> arithmetic. A linear/ quadratic interpolation is equivalent to series
> expansion and
> hence can be done, though it has to be atleast quadratic to get decent
> results.
>If you are saying that interpolations (not power series expansions as
they are not the same thing in the general case) are good enough, then
why not use them also for integrals and all the other complicated
expressions that can not be expressed in mpi?
krastano...@gmail.com
> implementation.
> I don't think the implicit equations involving such expressions can be
> plotted
> even in mathematica / Matlab.( haven't verified it though). Plotting using
> interpolation is possible, but it might lead to erroneous plots and hence
> it is better not to implement a interpolating plots for such functions.
Matlab can not (matlab is not good for anything symbolic or implicit
anyway) but Mathematica definitely can plot such expressions.
Why is interpolating a problem? All that you need to know is that your
function is monotone on the interval on which you are working, thus
just calculating one or two points inside your interval should be a
good guess. Of course there will be pathological cases, but better
fail only on patological cases than fail on every single expression
that is more complicated than a combination of sin, sqrt and abs.
Again, maybe I am missing something, but for the moment I do not see what it is.
Bharath M R
On Saturday, March 31, 2012 10:40:24 PM UTC+5:30, Stefan Krastanov wrote:
> I think most of the explicit equations can be handled by your
> implementation.
> I don't think the implicit equations involving such expressions can be
> plotted
> even in mathematica / Matlab.( haven't verified it though). Plotting using
> interpolation is possible, but it might lead to erroneous plots and hence
> it is better not to implement a interpolating plots for such functions.Matlab can not (matlab is not good for anything symbolic or implicit
anyway) but Mathematica definitely can plot such expressions.Why is interpolating a problem? All that you need to know is that your
function is monotone on the interval on which you are working, thus
just calculating one or two points inside your interval should be a
good guess.
krastano...@gmail.com
> and evaluated. If I have a false positive on one of the big blocks, the plot
> will be outright wrong. One thing we can do is to break down the whole
> region
> into a grid and assume that the function is monotonic in each cell and
> evaluate the expression. I think this will be the best solution to such
> functions.
I suppose this is the problem that I was unable to see. Nonetheless,
the solution you propose seems interesting.
One other thing - using `fill_between` will work for the big blocks
but it will fail for the smaller ones. If you will be working on
pixels you may want to check `showimage`. Another thing that may be
better than fill_between is to use directly the polygon collection
class. I don't know a good way to do this for the vector formats
(svgfig).
Bharath M R
krastano...@gmail.com
Aaron Meurer
Why do you need to support nsolve expressions? Isn't the whole point
of implicit plotting that you don't have to use nsolve to plot the
expression?
Aaron Meurer
Aaron Meurer
The AppEngine now supports numpy, so this is no longer an issue.
Aaron Meurer
Aaron Meurer
So should the example in your proposal be sqrt(x) instead of x**0.5?
Aaron Meurer
>> > sympy+un...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/sympy?hl=en.
>
> --
> 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/-/1ViBNl1hWEkJ.
>
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+un...@googlegroups.com.
krastano...@gmail.com
>> Otherwise your code will be useful only for a very constrained subset
>> of sympy functions (no special functions (gamma or bessel), integrals,
>> nsolve expressions and so on).
>
> Why do you need to support nsolve expressions? Isn't the whole point
> of implicit plotting that you don't have to use nsolve to plot the
> expression?
As you said, nsolve is not a good example, but the other still apply.
However Bharath mentioned a possible solution (something about
starting with smaller domains).
Bharath M R
Aaron Meurer
you always do the arithmetic in mpmath, and then only convert to numpy
at the end? That would defeat the purpose of using numpy.
Probably it's better to create a library that is backend agnostic, and
plug numpy and mpmath into it (but do it in such a way so that you can
still take advantage of the mpi functionality that is already in
mpmath).
Aaron Meurer
> --
> 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/-/_PSpO9E6gNcJ.
Bharath M R
On Tuesday, April 3, 2012 1:18:00 AM UTC+5:30, Aaron Meurer wrote:
I don't get the point of doing it that way. Wouldn't that mean that
you always do the arithmetic in mpmath, and then only convert to numpy
at the end? That would defeat the purpose of using numpy.