splitting plot into plot, plot_3d, and plot_implicit

[Bharath M R]

Hi,

  During a discussion on IRC, both Aaron and I thought that we should split

the plot heuristic into separate functions and do away with the plot heuristic.

The functions will be

plot - plots only 2d plots.

plot_3d - plots 3d plots.

plot_implicit - plots regions and implicit plots.

Advantages:

- The docstrings will be cleaner.

- Adding new plot types will be easier. The heuristic will become more and more

complicated when we have to add other types of plots.

Disadvantages.

- pollutes the namespace.

What would be better? 

Thanks, 

Bharath M R.

[Aaron Meurer]

On Mon, Jul 16, 2012 at 12:56 AM, Bharath M R <catchmr...@gmail.com> wrote:
> Hi,
> During a discussion on IRC, both Aaron and I thought that we should split
> the plot heuristic into separate functions and do away with the plot
> heuristic.
> The functions will be
> plot - plots only 2d plots.

Would it make more sense to call this plot_2d()?

> plot_3d - plots 3d plots.
> plot_implicit - plots regions and implicit plots.
>
> Advantages:
> - The docstrings will be cleaner.
> - Adding new plot types will be easier. The heuristic will become more and
> more
> complicated when we have to add other types of plots.
>
> Disadvantages.
> - pollutes the namespace.

To make things clearer, I easily envision us creating a bunch of
plotting functions. Just look at systems like Maple or Sage that have
a good plotting system. They have a ton of specialized plotting
functions, which make it easier to plot various kinds of expressions
or concepts. Of course, we may consider that most of these are not
important enough to import by default.

I also thought of another disadvantage. If we want to plot non-Expr
objects, it's not clear what function to use any more. For example,
suppose we wanted to add a way to plot the objects in the geometry
module. If I want to plot Circle, should I use plot_implicit? or
plot_2d? Maybe create a geometry_plot() function. Or should we just
require it to be Circle.plot? With the plot() heuristic, at least
plot(Circle) could work. This is perhaps just a special case of the
above point.

Note that I don't really think that this outweighs the benefits of
deleting plot(), but it's worth thinking about.

Aaron Meurer

>
> What would be better?
>
> 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/-/Zolkn_LUSDMJ.
> 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]

Would it make more sense to call this plot_2d()?

I think ``plot`` will mean 2d plots. I think that is how mathematica

and maple does 2d plots. plot_2d seems to be a overkill. But I don't

really have any strong objection to plot_2d also. 

To make things clearer, I easily envision us creating a bunch of
plotting functions.  Just look at systems like Maple or Sage that have
a good plotting system.  They have a ton of specialized plotting
functions, which make it easier to plot various kinds of expressions
or concepts.  Of course, we may consider that most of these are not
important enough to import by default.

I also thought of another disadvantage.  If we want to plot non-Expr
objects, it's not clear what function to use any more.  For example,
suppose we wanted to add a way to plot the objects in the geometry
module.  If I want to plot Circle, should I use plot_implicit? or
plot_2d?  Maybe create a geometry_plot() function.  Or should we just
require it to be Circle.plot?  With the plot() heuristic, at least
plot(Circle) could work.  This is perhaps just a special case of the
above point.

Yeah this seems to be important. I think in that case, Circle.plot() makes

sense or geometry_plot. I am not that supportive of Circle.plot() because

we would want to plot a combination of geometric objects. I think something

like geometry_plot will be better.  But the number of plot functions can become

very large.We can have, vector plots for differential geometry etc. But it will 

always be better to create new plot functions rather than add new heuristics

to plot.  

[Sergiu Ivanov]

On Mon, Jul 16, 2012 at 9:56 AM, Bharath M R <catchmr...@gmail.com> wrote:
>
> Disadvantages.
> - pollutes the namespace.

I have the strong opinion that what is going to happen if specialised
plotting functions are introduced is not going to be namespace
pollution at all.

I agree with Aaron's point that deciding which plotting function
exactly to use may become a nuisance. The solution to this issue
would be to make it very easy to find the necessary plotting function.
For example, each of the specialised plot_'s could check whether the
type of the supplied object fits within its scope and, if not, produce
a meaningful advice. Such functionality could be easily factored out
in a straightforward private helper function, which should also be
rather easy to extend.

(Of course, I don't mention proper documentation only because I
consider that self-evident :-) )

Sergiu

[krastano...@gmail.com]

Are you certain that the heuristics will become simpler? For the
moment `plot` does only "expression evaluated over range" type of
plots, and that falls in this category (2d lines, 3d lines and
surfaces and parametric lines and surfaces) requires the same type of
heuristics. There are no special cases in the code for the different
types of plots.

I do not have strong opinion on the issue. Whatever results in simpler
code I suppose.

And "heuristics" is misleading. There are documented definite rules by
which the arguments are completed when something is missing.

[Bharath M R]

Are you certain that the heuristics will become simpler? For the
moment `plot` does only "expression evaluated over range" type of
plots, and that falls in this category (2d lines, 3d lines and
surfaces and parametric lines and surfaces) requires the same type of
heuristics. There are no special cases in the code for the different
types of plots.

 

The heuristic might not become simpler. But for a person using it, it

splits the functionality into simpler blocks. The heuristic will be split

across the functions, and hence each function won't have a large amount

of checks.

 

I do not have strong opinion on the issue. Whatever results in simpler
code I suppose.

And "heuristics" is misleading. There are documented definite rules by
which the arguments are completed when something is missing.

 

Yeah agreed. I was thinking of splitting the definite rules into multiple functions.

I am arguing purely from a user point of view. It will be really difficult to look at

a whole page of documentation and then decide how to format an expression

to obtain the plot you want.

[krastano...@gmail.com]

I more or less agree, however

> The heuristic might not become simpler. But for a person using it, it
> splits the functionality into simpler blocks. The heuristic will be split
> across the functions, and hence each function won't have a large amount
> of checks.

The only place where one has a large amount of checks is an if/else
list (**not** a tree) in the Series factory class, not in the plot
functions. I think that keeping only one such list of if/else
statements is much cleaner than splitting it up (if we are still
talking about "expression over range" stuff).

It would be nice to have additional plot functions for geometry, for
plots over -oo,+oo, for asymptotes and so on. However it seems like
the code will become more complex if we split the current `plot`
function. We should just promise that nothing new will be added to it.

[krastano...@gmail.com]

On 16 July 2012 16:29, Bharath M R <catchmr...@gmail.com> wrote:
>
>> Are you certain that the heuristics will become simpler? For the
>> moment `plot` does only "expression evaluated over range" type of
>> plots, and that falls in this category (2d lines, 3d lines and
>> surfaces and parametric lines and surfaces) requires the same type of
>> heuristics. There are no special cases in the code for the different
>> types of plots.
>
>
> The heuristic might not become simpler. But for a person using it, it
> splits the functionality into simpler blocks. The heuristic will be split
> across the functions, and hence each function won't have a large amount
> of checks.

I agree with this. However, as I already said, this requires
spliting/removing the factory class. This is not necessarily a bad
thing.

[Aaron Meurer]

I can attest from experience that the API of plot as it is now is
already confusing. I had a hard time in particular in figuring out
the difference between plotting several equations and plotting a x vs.
y expression.

Another potential "heuristic" is to somehow hook in the implicit
plotter that Bharath is working on. Right now, if you pass an
expression to plot() with two variables, it creates a 3d plot. A
reasonable alternative is to use plot_implicit if given a Relational
(like Eq or Lt). But this is again a heuristic.

And I think the ambiguity that came up with plotting constants should
be enough to show that it is indeed a heuristic API.

But I do agree with you that it's indeed *not* a heuristic API,
because such a thing is actually impossible. Whatever it does will be
considered as the well-defined behavior to users (regardless of what's
in the documentation). Then if we change it in a future release
(perhaps to accommodate new plotting functionality), it will just
break stuff for users. The Eq from 3d to implicit change I suggested
above would be such a change.

Either that, or we don't add any functionality to plot(). And the
situation will be that plot() can only plot 2d and 3d, because those
are what happen to be implemented right now. Everything else will
just be in separate functions, meaning that we will have *both* plot()
and several functions.

Yes, plot_* functions may become many, but we can easily solve that
using namespaces (i.e., don't import the majority of them by default).

I was already discussing with Bharath some changes that need to be
made in the class structure. For example, right now, plotting a list
of expressions is handled by plot(). But really this should be
factored out in some base class, so that any plotting function can
just use it naturally. This will later be extended to things like
plotting different expressions with different colors.

I unfortunately don't know the code well enough yet to suggest the
best class structure, but I would aim to reduce code duplication as
much as possible while not keeping broad functionality specific, and
also to keep known future usage in mind (but I guess that's about as
generic of advice for designing a class structure anyone can give ;-)

Aaron Meurer

[krastano...@gmail.com]

On 17 July 2012 02:20, Aaron Meurer <asme...@gmail.com> wrote:
> I can attest from experience that the API of plot as it is now is
> already confusing. I had a hard time in particular in figuring out
> the difference between plotting several equations and plotting a x vs.
> y expression.

This argument mostly convinces me. However, before I drop it, are you
aware that after you complained about this a few months ago I added
the exact same API that you proposed?

> Either that, or we don't add any functionality to plot(). And the
> situation will be that plot() can only plot 2d and 3d, because those
> are what happen to be implemented right now. Everything else will
> just be in separate functions, meaning that we will have *both* plot()
> and several functions.

Actually, there is better distinction than "because those are what
happen to be implemented right now". It plots "n-dimensional
expressions over m-dimensional parameter space". If what you want to
plot does not fall into the category "function to be sampled" it is
not in `plot()`. This is not necessary the way to do it, however I
wanted to state how it is at the moment.

> I was already discussing with Bharath some changes that need to be
> made in the class structure. For example, right now, plotting a list
> of expressions is handled by plot(). But really this should be
> factored out in some base class, so that any plotting function can
> just use it naturally. This will later be extended to things like
> plotting different expressions with different colors.

I don't see how this makes sense in the current structure. What you
want to do can be added to the `Plot` class (and it makes sense to be
there).

At the moment there is a class representing the whole plot (`Plot`).
It contains each element to be plotted (subclass of `BaseSeries`). The
backends use methods like `get_segments` in order to get coordinates
and plot them. If we add something that represents "a few elements to
be plotted, for instances a number of lines" and call it
`MultipleSeries` what happens when we want to add two instances of
`MultipleSeries` to `Plot`. If the reason for the creation of
`MultipleSeries` was in the first place to be able to change colors
automatically, then we should merge the two instances of
MultipleSeries into one instance. However this is really ugly as it
just adds another layer between Plot and whatever single element is to
be plotted that only repeats what Plot already does.

[Bharath M R]

> I was already discussing with Bharath some changes that need to be
> made in the class structure.  For example, right now, plotting a list
> of expressions is handled by plot().  But really this should be
> factored out in some base class, so that any plotting function can
> just use it naturally.  This will later be extended to things like
> plotting different expressions with different colors.

I don't see how this makes sense in the current structure. What you
want to do can be added to the `Plot` class (and it makes sense to be
there).

I agree with Stefan on this. I think the class structure is very nice, and 

any other class structure will increase the complexity of the code.