Pull request review and testing (Plotting Module).

[Bharath M R]

Hi,

I am Bharath M R and I will be working on the implicit plotting module as part of GSoC this year.

I will be basing my work on Stefan's pull request [1]. So I would like to get it merged before I start

working on my project. This will help me to have regular atomic pull requests throughout summer.

Otherwise, there will be a dependency chain formed, and as Aaron said, will lead to huge chunks

of code as pull requests. During the community bonding period, I would like to fix all the major 

problems and get it merged. So I request you to please review and test the plotting module [1].

@Stefan Can you add me as an collaborator for the plotting module branch? Or will it be better

if I send pull requests to your branch to fix the problems that come up?

Thanks,

Bharath M R

[1] https://github.com/sympy/sympy/pull/673

  

[krastano...@gmail.com]

Hi Bharath,

First of all, what should I do to add you as a collaborator to the
pull request (I was not aware it was possible)?

Second, we can meet on IRC or skype so I can help you with reviewing
the code. There is one big chunk of documentation missing and one
important change still needs to be done.

The documentation missing is about the Series factory class. It needs
to be explicitly mentioned that this is where most of the heuristics
are done when one wants to guess what type of plot the user wants.

The change that needs to be done is to add the more explicit plotting
routines. Those are easy one-liners. Aaron was worried that this means
that they will use the heuristic plot() function, but it is not the
case. They will just call the appropriate base series class and that
is all.

Before merging, the api should be stable. I think that the best way to
do this is to get the pull request in a polished stated using the
current api, then finish the wiki page with the examples and ask the
community for an opinion.

Can we meet on irc/skype today (I have exams this week so I won't be
able to dedicate more than an hour or so...)

Stefan

[krastano...@gmail.com]

>
> @Stefan Can you add me as an collaborator for the plotting module branch? Or
> will it be better
> if I send pull requests to your branch to fix the problems that come up?
>

I checked that. I think it would be better to send a pull request to
my branch with your changes.

[krastano...@gmail.com]

Things to be changed:

#1
Plot() should not do all this magic. All the magic should be in plot()
and Series().
- Plot() should accept only instances of subclasses of BaseSeries in
its constructor.
- plot() should be fixed to work after the change to Plot()
- the documentation should explicitly mention that if any heuristics
is to be added it should be contained in Series() and plot()
- the name of Series() should change to something like HeuristicSeries()

#2
Add explicit plot functions:
plot_line, plot_surface, plot_parametric_surface, etc
These again should require fully explicit syntax, no guessing like in plot()

#3
The api should be as follows (both for plot() and for the explicit
plot_something()):
- plot_some_type_of_graph(expression, tuple_of_variable_and_range, ...)
ex: plot_surface(x+y, (x, 1, 2), (y, 1, 2))
result: obvious

- plot_some_type_of_graph(list_of_expressions, tuple_of_variable_and_range, ...)
ex: plot_surface([x+y, x-y], (x, 1, 2), (y, 1, 2))
result: plots two surfaces

- plot_some_type_of_graph(many_tuples_of(expression,
tuple_of_variable_and_range, ...))
ex: plot_surface((x+y, (x, 1, 2), (y, 1, 2)), (x-y, (x, 1, 2), (y, 1, 2)))
result: the same as the previous example

#4
The ipython profile should be updated


On 28 April 2012 16:31, krastano...@gmail.com

[krastano...@gmail.com]

There is also the problem with what to do when the result is a complex
number. This is complicated, so I really hope that we can leave this
question out at least for the moment. (the current behavior is to plot
the real part of the expression)

[Aaron Meurer]

That's great that you're looking at this now, so that you can indeed
get atomic pull requests throughout the summer. I think that the main
thing is to get a stable API, as we may end up releasing at some point
in the beginning of the summer. Other things like what to do with
complex numbers can wait, as there's no issue with changing that after
a release.

After that, we can just merge Stefan's branch, and all future fixes
can just come from you to the official sympy repo based off of master.

The best way, as Stefan noted, is to just create a branch based off of
his and send him pull requests. Since Stefan will be active to review
your fixes, this way will work fine. GitHub has a bug relating to
sending pull requests to other people, namely, not all forks show up
in the list, so let me know if you have any issues.

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/-/doqKndwzN3AJ.
> 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]

I had slept off yesterday(thanks to 2 sleepless days). Is it possible to meet

today on IRC around the same time ( 14:30 UTC). If you are busy, then we 

can meet after your/ my exams. I will be having exams till the end of this week.

I will look at the things that you mentioned, which has to be changed. 

Thanks, 

Bharath M R  

[krastano...@gmail.com]

> today on IRC around the same time ( 14:30 UTC). If you are busy, then we
> can meet after your/ my exams. I will be having exams till the end of this
> week.
> I will look at the things that you mentioned, which has to be changed.

It seems that we both have other more pressing work, so let's just
discuss it after our exams (Friday, Saturday or Sunday after 12UTC and
before 20UTC).

Anyway, if you have any questions, I will be on IRC.

[Bharath M R]

Yeah sure. Will ping you on IRC in the weekend.