R-beta: image(x,y,z)?

I can get at data$x, data$y, data$z. I want to do an image plot.  Ideally
image (or a relative of image) would accept the vectors data$x, data$y,
data$z as arguments. (After all, if you can do plot(x,y) on vectors x and
y, why can't you do image(x,y,z) on vectors x, y, and z?) However it
doesn't work like that.

The real reason is that it isn't written that way.  There is a good
rationalisation, though.  image() is a surface plot, not a 3-d
scatterplot, and so it is necessary that z is defined at every point on
the x,y grid (otherwise we don't know what color to plot). This is hard to
ensure when you have image(x,y,z) for vectors

Anyway, can someone please explain how to get my data into a form
acceptable to image?  Thanks very much!

In fact, you don't need z to be a matrix.  What you need is 
length(z)=length(x)*length(y)
x increasing
y increasing

The idea is that values of z are ordered in the same way as if it were
generated by outer(x,y,somefunction), which will generally be how it was
generated.

We probably shouldn't require x and y to be increasing -- we could still
assume z is ordered as if it were outer(x,y,somefunction).

Anyway, one thing you can do if you have the full x and y vectors is

	image(unique(x),unique(y),z)

If you have full-length x and y vectors that are not in the right order
you can use 

o<-order(y,x)
image(unique(x[o]),unique(y[o]),z[o])

which should probably be built in to image().

Thomas Lumley
------------------------
Biostatistics		
Uni of Washington	
Box 357232		
Seattle WA 98195-7232	
------------------------


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Thanks very much Thomas!  Your solution works well!

I can get at data$x, data$y, data$z. I want to do an image plot.  Ideally
image (or a relative of image) would accept the vectors data$x, data$y,
data$z as arguments. (After all, if you can do plot(x,y) on vectors x and
y, why can't you do image(x,y,z) on vectors x, y, and z?) However it
doesn't work like that.

The real reason is that it isn't written that way.  There is a good
rationalisation, though.  image() is a surface plot, not a 3-d
scatterplot, and so it is necessary that z is defined at every point on
the x,y grid (otherwise we don't know what color to plot). This is hard to
ensure when you have image(x,y,z) for vectors

OK I get it.
I guess it would be possible to use x,y,z vector inputs (all same length)
as scatterplot; where is z is not defined at some (x,y), the colour of
that cell could be white or black. One could think of this plot as a
picture of a marked spatial point process if most of the cells are empty.
I am not saying this would necessarily make sense as image(), but maybe as
scatterimage().

Thanks again.

Bill

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Thomas Lumley writes:

> 
 > > 
 > > I can get at data$x, data$y, data$z. I want to do an image
 > > plot.  Ideally image (or a relative of image) would accept
 > > the vectors data$x, data$y, data$z as arguments. (After all,
 > > if you can do plot(x,y) on vectors x and y, why can't you do
 > > image(x,y,z) on vectors x, y, and z?) However it doesn't
 > > work like that.
 > > 
 > 
 > The real reason is that it isn't written that way.  There is a
 > good rationalisation, though.  image() is a surface plot, not
 > a 3-d scatterplot, and so it is necessary that z is defined at
 > every point on the x,y grid (otherwise we don't know what
 > color to plot). This is hard to ensure when you have
 > image(x,y,z) for vectors
 > 

Interestingly enough, Tr*llis seems to be on Bill Simpson's side.
lev*lplot(), wir*frame() and contourpl*t() all require x, y and z
of equal length, *but* with the necessary grid structure, thank
you.  The first job these functions do, of course, is to collapse
x and y to short vectors and make z (effectively) a matrix.  It
seems to me the restriction is a bit unnecessary, and if the
cross structure were not there some default (or even specified)
interpolation process could be used to fudge it.

\begin{idleMusing}
Apropos of that, has any thought been given to implementing a
Tr*llis-style graphics system in R?  I presume the copyright
protection issues would be extreme (hence my paranoid caution in
not even mentioning full names...:-), but I do think the matter
is important.  I don't pretend to have a full answer to this one.
Tr*llis looks to me like about a decade's work, off an on, in the
planning and design stages and the result is wonderful.  The
designer should have full recognition of that and entitled to
copyright protection on his work, but if R is to be a modern
graphics system it has to have multi-paneled conditioning at
least.  Has anyone thought about graphics in R, perhaps with a
view to putting together a quite different scheme of high quality
graphics procedures?  Tr*llis may be excellent, but it does not
have to be unique.  I would even favour an entirely different
scheme that could stand as a real alternative to Tr*llis rather
than a simple immitator, but that is going to take real talent.
\end{idleMusing}

Bill.

Bill Venables, Head, Dept of Statistics,    Tel.: +61 8 8303 5418
University of Adelaide,                     Fax.: +61 8 8303 3696
South AUSTRALIA.     5005.   Email: Bill.Venables at adelaide.edu.au

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Bill Venables writes:
 > \begin{idleMusing}
 > Apropos of that, has any thought been given to implementing a
 > Tr*llis-style graphics system in R?  I presume the copyright
 > protection issues would be extreme (hence my paranoid caution in
 > not even mentioning full names...:-), but I do think the matter
 > is important.  I don't pretend to have a full answer to this one.
 > Tr*llis looks to me like about a decade's work, off an on, in the
 > planning and design stages and the result is wonderful.  The
 > designer should have full recognition of that and entitled to
 > copyright protection on his work, but if R is to be a modern
 > graphics system it has to have multi-paneled conditioning at
 > least.  Has anyone thought about graphics in R, perhaps with a
 > view to putting together a quite different scheme of high quality
 > graphics procedures?  Tr*llis may be excellent, but it does not
 > have to be unique.  I would even favour an entirely different
 > scheme that could stand as a real alternative to Tr*llis rather
 > than a simple immitator, but that is going to take real talent.
 > \end{idleMusing}

I have also come to the conclusion that the R graphics model has to
go.  It was a quick hack which was meant to fill a gap until the real
thing happened.  The present model is an imitation of the GRZ package
developed at Bell Labs before S came on the scene.  It is based on
arcane notions which are appropriate for pen plotters, but not modern
raster devices.

The major problem happens when graphics windows are resized.  To see
this have a look at
	> data(islands)
	> dotplot(islands)
Now reshape the graphics window.  The labels don't stay in the right
places.  This is because after a resize the "mar" and "mai" parameters
are in conflict.  (I have a band-aid for this particular problem, but
it a general one).

S gets around this by not allowing resizing of devices.  Yes, you can
reshape windows, but if you look at the device dimensions in inches
they never change.

At some point I would like to completely redo the graphics system in
the light of what I've learned from one of our PhD student's research
(and some of mny own tinkering).  But it won't happen for a while.  My
priority at present is to get something out which will be stable,
documented and useful for a reasonable subset of statistics.


As for trellis.  I don't really think that it is all that deep or
difficult.  It would be pretty easy to implement a passable "copy" and
there would be no legal problems provided that it was a clean room
implementation.  It's patents that create the real problem and as far
as I know there is no trellis patent (prior art can probably be traced
as far back as Decartes).

I even have a name.  How do you like "lattice". :-)

	Ross
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._