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). On Mon, Jul 16, 2012 at 5:41 PM, [email protected] <[email protected]> wrote: > On 16 July 2012 16:29, Bharath M R <[email protected]> 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. 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 -- 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.
