[R] Using expression in Hmisc Key()

[Greg Snow]

> -----Original Message-----
> From: r-help-bounces at r-project.org 
> [mailto:r-help-bounces at r-project.org] On Behalf Of Michael Kubovy
> Sent: Thursday, December 06, 2007 2:12 AM
> To: Dieter Menne
> Cc: r-help at stat.math.ethz.ch
> Subject: Re: [R] Using expression in Hmisc Key()
> 
[snip]
> This is one of the cases where I wish there were a function 
> that "exercised" all the arguments of a graphics function by 
> visualizing the effect of changing  two or three levels of 
> each argument (one by one, of course). This might have the 
> side effect of allowing authors to shorten documentation. I 
> have in mind adding a method to each graphics function, and 
> having the author specify the two or three instructive levels 
> of each argument. See the exhaustive exploration by J.R. 
> Lobry, A.B. Dufour & D. Chessel of the graphical parameters 
> accessible by par(), at http://pbil.univ-lyon1.fr/R/fichestd/tdr75.pdf

There are some tools that already exist to help with creating these
types of visualization tools.  The playwith package appears to be one
such set of tools (I have not played with it much, so don't expect
details from me).

The tkrplot package is another one (I am more familiar with this one).
The slider function (relax and TeachingDemos package) and sliderv
function (TeachingDemos) also help here.  Try running the example for
the sliderv function and move the sliders around to see the effects.
(one of these days I am going to rewrite many of the demos in
TeachingDemos to use tkrplot)

Yes, it would be nice to have a general function that could look at the
arguments of a function, but this is not an easy task, for example, how
many arguments can you pass to the plot function?  Also which arguments
should use slider bars and which text widgets? (radio buttons are a bit
easier).  One option (that I think you are possibly suggesting above) is
to have each writer of a function include some type of metadata that a
general function could query and use to make decisions about what type
of control to use for that option including possible ranges of values.
I'll think some more about this approach.  I have plans to add some more
graphical demos to the TeachingDemos package that would do what you want
with subsets of the par arguments (there are too many to do all at once,
but one function could let you modify plotting type, cex, lwd, lty, col,
and similar options, it gets tricky when mar and mai both modify the
same thing in different ways and both take vectors rather than a single
number).

Some functions have arguments that depend on each other, making the GUI
for these cases is a bit more dificult in that you need to build in
those relationships (see the vis.gamma function in TeachingDemos for one
example, the rate and scale arguments are 2 different ways of specifying
the same thing).

One option (I would be willing to put this into TeachingDemos, or it may
want its own package at some point) is to write a general function that
takes a plotting expression/function as the first argument and a list as
the 2nd argument.  The list would include information on which type of
widget (slider, radio buttons, entry, ...) to use, what the range of
values are, and which argument to the plotting function they correspond
to.  The function would then create a gui (using tkrplot would be my
preference) that would modify those values.  Any function author that
wants users to be able to use this with their function just needs to
provide the list and possibly a not run example in the docs (and we can
create several predone lists in the package for common plotting
functions and subsets of "par" arguments).

I'm adding this to my list of bus projects to think about.

Any other thoughts,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.snow at intermountainmail.org
(801) 408-8111