R help - Jul 2006 - curiosity question: new graphics vs. old graphics subsystem

I just read paul murrell's new book, R graphics.

now, I have always used the traditional graphics system.  apparently,
the new (trellis?) system is an entirely separate graphics system.
after reading the book, I cannot figure out what the intrinsic
capability advantage of the old graphics system is that cannot be
replicated in the trellis system.

if the new system's capabilities are practically a subset of the old
system, why don't we design a compatibility layer so that we can just
have one graphics subsystem, instead?  it seems weird that newbies
learn the standard system first, and then, instead of building on it
with more complex functions, are told to forget about things and start
with something new.  I do like the simplicity of learning of the old
system, but this would be the same if it were to come through a
compatibility layer, too.  and then it would be easy to build learning
on it.

but maybe I have it all wrong.  maybe there is something unique about
the old system that the new system cannot do.  curious:  what is it?

I also found the naming of the new system confusing.  there is
trellis, there is lattice, there is grid.  how exactly should the new
system be called?  paul calls the old system "traditional."  the new
one seems to rear its head in different forms.

some other opinions (which follow the old rule that everyone has one):

* if we had one graphics subsystem, paul's book, and for this matter
any explanation of the R graphics system, would become more
parsimonious.

* R is, IMHO, the premier "programmed graphics" package today.  I may
be complaining, but I also recognize that it is great.  so, please
consider this to be only a suggestion.

* we have a pixmap image function.  we should also have a pdf
includegraphics function, which can import an existing graphics image.
 if a device (X11) is incapable of displaying it, we should just
display a rectangle of the bounding box.  this would open up even more
avenues to the ability of R to create graphics.

regards,

/ivo

Well, as a newbee, I believe your idea is great. However, the R Core team is, in
my humble opinion, way too stretched (for a free software development team) to
do this. A complementary development team (similar to, say, the Tinn-R team)
might be able to address this issue. I wish I would have the skills to
contribute :-) Just my 2c.

The least of learning is done in the classrooms.
  - Thomas Merton

----------------------------------------
> Date: Sun, 2 Jul 2006 09:34:39 -0400
> From: ivowel at gmail.com
> To: m_nica at hotmail.com
> Subject: Re: [R] curiosity question: new graphics vs. old graphics
subsystem
> 
> hi mihai:  it is more likely that the developers will take this more
> seriously if you echo my concern on r-help itself.  regards, /iaw
> 
> On 7/1/06, Mihai Nica <m_nica at hotmail.com> wrote:
> >
> > Wow, this is what I would say if I knew how to say it :-)!!!! For
newbees
> > (such as myself) or those who lack programming expertise (and, why
not, for
> > those not interested in programming) this approach would be great.
> > mihai
> >
> > ________________________________
> > Express yourself instantly with Windows Live Messenger
_________________________________________________________________
Express yourself: design your homepage the way you want it with Live.com.

Hi


ivo welch wrote:
> I just read paul murrell's new book, R graphics.
> 
> now, I have always used the traditional graphics system.  apparently,
> the new (trellis?) system is an entirely separate graphics system.
> after reading the book, I cannot figure out what the intrinsic
> capability advantage of the old graphics system is that cannot be
> replicated in the trellis system.
> 
> if the new system's capabilities are practically a subset of the old
> system, why don't we design a compatibility layer so that we can just
> have one graphics subsystem, instead?  it seems weird that newbies
> learn the standard system first, and then, instead of building on it
> with more complex functions, are told to forget about things and start
> with something new.  I do like the simplicity of learning of the old
> system, but this would be the same if it were to come through a
> compatibility layer, too.  and then it would be easy to build learning
> on it.
> 
> but maybe I have it all wrong.  maybe there is something unique about
> the old system that the new system cannot do.  curious:  what is it?

The main problem is that traditional graphics thinks everything is a
plot.  This is good because it makes things like this possible ...

plot(1)
text(1, 1, "whoop-dee do")

... the important bit is that the 'text()' call has a reliable meaning:
it adds text to the current plot.  The downside is that if what you want
to draw is not a plot, you have to fight the system to do it.

The grid system thinks everything is a picture.  This is good because if
you want to draw something other than a plot, you can.  It is bad
because if I do something like ...

grid.text("la-dee da")

... that is not necessarily going to be added to a plot (unless I first
make sure that I am in an appropriate viewport).

There are other issues such as the fact that grid is generally more
memory hungry and slightly slower.

A "compatibility layer" has been discussed and it is perhaps possible,
BUT it would require reimplementing the traditional graphics system on
top of grid, which would be a pretty icky task.  Contributions always
welcome :)

> I also found the naming of the new system confusing.  there is
> trellis, there is lattice, there is grid.  how exactly should the new
> system be called?  paul calls the old system "traditional."  the
new
> one seems to rear its head in different forms.

Reread Section 1.2 :)  There are two basic graphical systems
("traditional" and grid) and numerous graphical packages built on top
of
each.  Lots of packages build on top of the traditional system.  Several
packages now exist on top of 'grid' (notably 'lattice',
'vcd', 'ggplot',
and 'hexbin').

> some other opinions (which follow the old rule that everyone has one):
> 
> * if we had one graphics subsystem, paul's book, and for this matter
> any explanation of the R graphics system, would become more
> parsimonious.
> 
> * R is, IMHO, the premier "programmed graphics" package today.  I
may
> be complaining, but I also recognize that it is great.  so, please
> consider this to be only a suggestion.
> 
> * we have a pixmap image function.  we should also have a pdf
> includegraphics function, which can import an existing graphics image.
>  if a device (X11) is incapable of displaying it, we should just
> display a rectangle of the bounding box.  this would open up even more
> avenues to the ability of R to create graphics.

There is now a 'grImport' package on CRAN for this sort of thing (also
see http://www.r-project.org/useR-2006/Slides/Murrell.pdf).

Paul
-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
paul at stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/