It was gently suggested to me in a private message that to achieve
*complete* control over the inputs and outputs in R graphics one should be
using grid graphics. I concur with that suggestion and wish to amend my
previous statement accordingly.
With kindest thanks,
Dennis
On Wed, Jan 5, 2011 at 3:02 AM, Dennis Murphy <djmu...@gmail.com> wrote:
> Hi Bert:
>
> On Tue, Jan 4, 2011 at 8:39 PM, Bert Gunter <gunter.ber...@gene.com>wrote:
>
>> Dennis:
>>
>> Can't speak to ggplot2, but your comments regarding lattice are not
>> quite correct. Many if not all of lattice's basic plot functions are
>> generic, which means that one has essentially complete latitude to
>> define plotting methods for arbitrary data structures. For example,
>> there is an xyplot.ts method for time series -- class ts -- data.
>>
>> Of course, for most lattice methods, the data do naturally come in a
>> data frame, and a standard lattice argument is to give a frame from
>> which to pull the data. But this is not required.
>>
>> I'm aware of that, but thank you for clarifying matters. I didn't state
> explicitly whether lattice required data frame input or not (my lattice
> example indicated no and indeed it does not), but the message was evidently
> muddled further down the post. Your comments speak to some of the
> differences in the design and philosophy of lattice and ggplot2, and I have
> no disagreement with your remarks about lattice.
>
> The point I was trying to make was that by using data frames and the
> several packages/base functions that support their manipulation, one can
> simplify the coding of graphics within both ggplot2 and lattice. There are
> many things one can do with data frames that one cannot with vectors, as you
> well know - e.g., extensions with new data (rbind) or new variables
> (cbind/transform, etc.), or reshaping, among others. These features can be
> used to advantage in both ggplot2 and lattice. The OP's example is a simple
> one - had he used
>
> df <- data.frame(x = sqrt(1:10), y = log(1:10)) # oops, forgot 1:10...
>
> qplot(as.numeric(rownames(df)), x, data = df, geom = 'line', colour =
> I('darkgreen')) # ...but it's OK
> # or
> xyplot(x ~ as.numeric(rownames(x)), data = df, type = 'l', col.line =
> 'darkgreen')
>
> there would have been no problem. A little inconvenient for a new user,
> maybe, but hardly 'very restrictive'.
>
>
> As for other types of R data objects that are not data frames, offhand I
> can't think of too many that are incapable of being converted to data frames
> somehow for the purposes of graphics, although I wouldn't be remotely
> surprised if some existed. [For example, one can extract fitted values,
> residuals and perhaps a model matrix from a model object and place the
> results in a data frame.] ggplot2 has a fortify() method to allow one to
> transform data objects for use in the package. There is some discussion in
> Chapter 9 of Hadley's book, but I'm not in a position to add insight as I
> haven't used it personally.
>
> I do think this is a fair statement, though, and it's been said before: if
> one wants *complete* control and flexibility of inputs and outputs, use base
> graphics. Both lattice and ggplot2, by virtue of being structured graphics
> systems, impose certain constraints (e.g., default actions) on the user
> which are system-dependent. Prof. Vardeman's quote still applies :)
>
> Dennis
>
>
>
>
> -- Bert
>>
>> >
>> > Please explain to me how
>> >
>> > df <- data.frame(x, y, index = 1:10)
>> > qplot(index, x, geom = 'line', ...)
>> >
>> > is 'very restrictive'. Lattice and ggplot2 are *structured* graphics
>> systems
>> > - to get the gains that they provide, there are some costs. I don't
>> perceive
>> > organization of data into a data frame as being restrictive - in fact,
>> if
>> > you learn how to construct data for input into ggplot2 to simplify the
>> code
>> > for labeling variables and legends, the data frame requirement is
>> actually a
>> > benefit rather than a restriction. Moreover, one can use the plyr and
>> > reshape(2) packages to reshape or condense data frames to provide even
>> more
>> > flexibility and freedom to produce ggplot2 and lattice graphics. In
>> > addition, the documentation for ggplot2 is quite explicit about
>> requiring
>> > data frames for input, so it is behaving as documented. The complexity
>> (and
>> > interaction) of the graphics code probably has something to do with
>> that.
>> >
>> > Since Josh left you a quote, I'll supply another, from Prof. Steve
>> Vardeman
>> > in a class I took with him a long time ago:
>> > "There is no free lunch in statistics: in order to get something, you've
>> got
>> > to give something up."
>> >
>> > In this case, if you want the nice infrastructure provided by ggplot2,
>> you
>> > have to create a data frame for input.
>> >
>> > Dennis
>> >
>> >>
>> >> Thanks in advance, and best regards!
>> >>
>> >> Eduardo Horta
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> ______________________________________________
>> >> R-help@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-help
>> >> PLEASE do read the posting guide
>> >> http://www.R-project.org/posting-guide.html
>> >> and provide commented, minimal, self-contained, reproducible code.
>> >>
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ______________________________________________
>> > R-help@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-help
>> > PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> > and provide commented, minimal, self-contained, reproducible code.
>> >
>>
>>
>>
>> --
>> Bert Gunter
>> Genentech Nonclinical Biostatistics
>>
>
>
[[alternative HTML version deleted]]
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
