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.
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
--
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.
