On Saturday, March 31, 2012 2:36:57 AM UTC+5:30, pr...@goodok.ru wrote:
>
> On 30.03.2012 20:40, Bharath M R 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
> >
> >
> >>
> >
>
> 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.
>
I agree that the two things are quite orthogonal. I think I would be done
with the implicit plotting module by the end of 10 weeks and I would
love to have a plotting module which will work on the web.
> 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.
>
svgfig can always take a series of points and plot the graph. Hence we need
not
convert to strings that svgfig understands, though doing it will be better.
The idea behind using svgfig is that it is completely written in python and
can run on the Google App Engine. If SymPy Live has to support plotting,
then we will need a backend either for svgfig, or google charts api. Google
charts api is mainly for plotting statistics and is not a great tool for
plotting
graphs.
>
>
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
>
>
--
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/-/N9tUt4pUeooJ.
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.
