Re: [R] curiosity question: new graphics vs. old graphics subsystem

2006-07-04 Thread Paul Murrell
Hi


ivo welch wrote:
> hi paul:  thank you.  great explanation.
> 
> * what you describe seems like a fairly modest advantage of the
> traditional system.  I have never used the new system, but this part
> of the translation should be simple: if a plot() is called, set the
> current viewport.  emulation done.  (if the user has issued a plot()
> and then screws around with the viewport, R could complain and tell
> the user that she is now on her own.)  I am probably way too naive
> here.  there must be a lot trickier stuff.


There is the package 'gridBase' which provides some support for this
"naive" approach.


> * R regularly makes small changes that break old R code in order to
> improve R.  This is good.  IMHO, emulating the old graphics system
> would not have to be perfect one-to-one.


But the person maintaining the emulation code would have to support more
than just YHO :)


> * when new graphics features are added, there must be duplication of
> effort to get it into both graphics systems.  would it not be easier
> in the long-run to have just one system to maintain?


Yes!


> * grImport and your slides look nice.  alas, I am searching for
> grImport in your book, and it ain't there.  ;-).  also, pdf should be
> as important as postscript to include these days.


The book preceded work on grImport.

grImport imports PostScript because that is possible without writing a
PostScript interpreter (it uses ghostscript).  Many tools exist to
convert from other vector formats to PostScript (e.g., pdf2ps
[ghostscript], pdftops [xpdf]).


> * speed and memory size for graphics are less of an issue now than it
> used to be.


Right.  Otherwise grid would not exist.  But some datasets and
visualization problems are getting larger at an even greater rate.


> sheesh, this almost sounds ungrateful.  don't mean to be.  thanks to
> the R team for having put this graphics together.  it really is the
> best thing out there.  this discrepancy in graphics systems is really
> nothing more than a minor nuisance.


Suggestions are welcome, as long as they are not accompanied by a
deadline :)  You are of course correct.  It would be much better if
there were only one graphics system.  The only sensible solution would
be an emulation layer, but it needs to become enough of an itch for
someone that they have to scratch it.  At this stage it just seems to be
a bit of a rash;  unsightly, but the cure is worse than the disease.

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

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


Re: [R] curiosity question: new graphics vs. old graphics subsystem

2006-07-04 Thread ivo welch
hi paul:  thank you.  great explanation.

* what you describe seems like a fairly modest advantage of the
traditional system.  I have never used the new system, but this part
of the translation should be simple: if a plot() is called, set the
current viewport.  emulation done.  (if the user has issued a plot()
and then screws around with the viewport, R could complain and tell
the user that she is now on her own.)  I am probably way too naive
here.  there must be a lot trickier stuff.

* R regularly makes small changes that break old R code in order to
improve R.  This is good.  IMHO, emulating the old graphics system
would not have to be perfect one-to-one.

* when new graphics features are added, there must be duplication of
effort to get it into both graphics systems.  would it not be easier
in the long-run to have just one system to maintain?

* grImport and your slides look nice.  alas, I am searching for
grImport in your book, and it ain't there.  ;-).  also, pdf should be
as important as postscript to include these days.

* speed and memory size for graphics are less of an issue now than it
used to be.

sheesh, this almost sounds ungrateful.  don't mean to be.  thanks to
the R team for having put this graphics together.  it really is the
best thing out there.  this discrepancy in graphics systems is really
nothing more than a minor nuisance.

best,

/iaw

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


Re: [R] curiosity question: new graphics vs. old graphics subsystem

2006-07-03 Thread Paul Murrell
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
[EMAIL PROTECTED]
http://www.stat.auckland.ac.nz/~paul/

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


Re: [R] curiosity question: new graphics vs. old graphics subsystem

2006-07-02 Thread Mihai Nica
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: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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.

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


[R] curiosity question: new graphics vs. old graphics subsystem

2006-07-01 Thread ivo welch
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

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html