#11266: Wrapper for R graphics commands.
---------------------------+------------------------------------------------
Reporter: JoalHeagney | Owner: was
Type: enhancement | Status: new
Priority: minor | Milestone: sage-4.7.1
Component: interfaces | Keywords: R, graphics, cairo, wrapper
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
---------------------------+------------------------------------------------
Description changed by kcrisman:
Old description:
> This ticket links to [http://trac.sagemath.org/sage_trac/ticket/8868] and
> [http://trac.sagemath.org/sage_trac/ticket/11249]
>
> Currently, using R graphics in sage is ugly. A typical session looks like
> ...
> {{{
> #!python
> r.png()
> r.boxplot(.......)
> r.dev_off()
> }}}
> ... for EVERY graphic you want to create. This is a shame as R has some
> very advanced graphics functions.
>
> I would like sage to have a wrapper for R graphics which would:
>
> - handle identification of available graphical interfaces,
>
> - initialization of said interface,
>
> - run a list of R functions and finally
>
> - close the graphical interface and return an image (with the
> possibility of storing the image).
>
> A typical session would look like:
> {{{
> #!python
> graph = Rgraphic(R.Cairo arguments)
> graph.boxplot(arguments)
> graph.histogram(arguments)
> graph.etc......
> show(graph)
> }}}
>
> This would help with [http://trac.sagemath.org/sage_trac/ticket/8868], as
> it would allow us to hide the details of the graphics backend. (Cairo in
> Linux(And possibly Windows), and Quartz/Aqua in MacOS.)
>
> A possible implementation might sound like:
>
> The __init__ method accepts arguments eventually destined for R.Cairo,
> but are stored in a variable.
>
> Then, all method calls that aren't defined in the Rgraphic class could be
> stored in a list inside the instance to be called later.
>
> Finally, the .__show__() method initialises the R.Cairo object with the
> stored __init__ arguments, runs all the non-class calls from the list in
> R, then closes the R.Cairo object, with the possibility of storing the
> returned image inside the object.
>
> Some extra points to consider are covered in the following email snippet.
>
> ----
>
> ''"As for trellis/lattice packages, this highlights what could be a big
> problem with R, as there are literally thousands of different packages, a
> good few that create plots. If we create a list of pre-approved methods,
> this risks leaving a lot out. (There's some cool kriging stuff I'd like
> this wrapper to support.)''
>
> ''I was considering (for my first code-bash this weekend) ignoring
> loading, and storing any non-defined method call to this object and
> attempting to run it in R. It's not secure, but would have the benefit of
> ensuring that any loaded graphic function would run successfully as a
> method. ''
> ''If it's necessary that we have a list of well-defined methods to the
> Rgraphic object, would we be able to escape it using an extra check=False
> argument to the __init__ method.''
>
> ''So a typical session with my object would look like:''
>
> {{{
> #!python
> R.library("a graphics library")
> R.library("another graphics library")
>
> graph1 = Rgraphic(....................., check=False)
> graph1.boxplot(...............)
> graph1.someotherRfunction(..................)
> graph1.somethingelse(..............)
> show(graph1)
> }}}
> ''Still have to sort out how to store the image though. :("''
>
> ----
New description:
Currently, using R graphics in sage is ugly. A typical session looks like
...
{{{
#!python
r.png()
r.boxplot(.......)
r.dev_off()
}}}
... for EVERY graphic you want to create. This is a shame as R has some
very advanced graphics functions.
I would like sage to have a wrapper for R graphics which would:
- handle identification of available graphical interfaces,
- initialization of said interface,
- run a list of R functions and finally
- close the graphical interface and return an image (with the possibility
of storing the image).
A typical session would look like:
{{{
#!python
graph = Rgraphic(R.Cairo arguments)
graph.boxplot(arguments)
graph.histogram(arguments)
graph.etc......
show(graph)
}}}
This would help with #8868, as it would allow us to hide the details of
the graphics backend. (Cairo in Linux(And possibly Windows), and
Quartz/Aqua in MacOS.)
A possible implementation might sound like:
The `__init__` method accepts arguments eventually destined for R.Cairo,
but are stored in a variable.
Then, all method calls that aren't defined in the Rgraphic class could be
stored in a list inside the instance to be called later.
Finally, the `.__show__()` method initialises the R.Cairo object with the
stored `__init__` arguments, runs all the non-class calls from the list in
R, then closes the R.Cairo object, with the possibility of storing the
returned image inside the object.
Some extra points to consider are covered in the following email snippet.
----
''"As for trellis/lattice packages, this highlights what could be a big
problem with R, as there are literally thousands of different packages, a
good few that create plots. If we create a list of pre-approved methods,
this risks leaving a lot out. (There's some cool kriging stuff I'd like
this wrapper to support.)''
''I was considering (for my first code-bash this weekend) ignoring
loading, and storing any non-defined method call to this object and
attempting to run it in R. It's not secure, but would have the benefit of
ensuring that any loaded graphic function would run successfully as a
method. ''
''If it's necessary that we have a list of well-defined methods to the
Rgraphic object, would we be able to escape it using an extra check=False
argument to the __init__ method.''
''So a typical session with my object would look like:''
{{{
#!python
R.library("a graphics library")
R.library("another graphics library")
graph1 = Rgraphic(....................., check=False)
graph1.boxplot(...............)
graph1.someotherRfunction(..................)
graph1.somethingelse(..............)
show(graph1)
}}}
''Still have to sort out how to store the image though. :("''
----
See also #8868 and #11249.
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11266#comment:2>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" 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/sage-trac?hl=en.
