[R] A Few Suggestions to help out newbies

Peter Dalgaard BSA p.dalgaard at biostat.ku.dk
Tue Apr 2 17:35:49 CEST 2002


Laurent Gautier <laurent at genome.cbs.dtu.dk> writes:

> On Tue, Apr 02, 2002 at 03:28:13AM -0800, Zed Shaw wrote:
> > Hey Folks,
> > 
> > I may have some suggestions for you, based on my experience as a newbie
> > with R.  Implementing these very simple resources would be fairly easy
> > to do and would give volumes of help in return:
> > 
> > 1)  An R Cookbook section of the site where people can submit pieces of
> > interesting code that satisfies a need.  This would be similar to the
> > Perl/Python/Java Cookbook texts that O'Reilly puts out, but with a more
> > dynamic activity.  The python folks have something like this, and people
> > love it.  I learned a lot of python this way.
> 
> 
> You may try get in contact with the author of the following web document
> 
> http://lark.cc.ukans.edu/~pauljohn/R/statsRus.html
> 

Or start building a Wiki (cf. wiki.tcl.tk), one of my long-time
desires. It's not quite as simple as it sounds, since you need
procedures to keep the information up to date, create a sensible
superstructure, and for that matter also to ensure that the
information is sound in the first place.

(Paul's page is generally sound, but every once in a while there's a
spot where you think "there's a better way". E.g. plotting the Normal
density with

 x<-seq(-3,3,.1) 
 plot(x,dnorm(x,0,1), type="l")

Yes, it works, but how about curve(dnorm(x), -3, 3) ?)

> > 6)  Better layout of packages listed on CRAN.  This listing format will
> > collapse under its own weight once it gets too large.
> 
> 
> Memory has become more expensive over the last few months but displaying a
> html document that weights even few hundred kilobytes remains a reasonable
> assumption (the document is currently 164 kb).

Yes, but I think Zed meant that it needs some kind of superstructure
or keyword system attached. Could be true but someone need to invent
the structure or keyword set...

> > And, related to R:
> > 
> > 8) Command completion and contextual help in R.  The first one is
> > probably fairly easy.  The second one is probably impossible.  It would
> > involve giving out detailed help messages when things go wrong.  Not
> > sure how to do that.
> 
> I am not certain about how 'easy' is the first, but I am surely happy a
> brave soul did it (I am an humble user, I am not sure I could have done it).
> Did you check ESS ?
> (accessible through the menu 'Other' at www.r-project.org).

ESS does name completion, yes. And the readline front end could be
made to do likewise on Unix-alikes.

> If you are not sure about how to accomplish what you believe being
>  impossible...    :)

It sounds rather easy with ESS. (Basically just search backwards to the
function name, then call help() or args() on it). Not massively
difficult with other interfaces either. Someone needs to do it,
though... 

> > 9) Finally, my personal pet peeve of R:  tell me the line number of
> > errors.  It's nearly impossible to fix a broken function when I don't
> > know where it is broken.
> > 
> 
> I usually reach the faulty part in my function within an acceptable time.
> Did you try 
> help(traceback)
> help(debug)
> 
> ?

and help(dump.frames). The line number issue is somewhat nasty, due to
the non-uniqueness of parse/deparse in R (and S). Essentially, once a
function is parsed, the line numbers are lost, and deparsing may cause
statements to end up on lines different from where they originated.
Similar issues relate to comment handling. It requires rather intimate
knowledge of parser generators to get a handle on this, I'm afraid. 

> > 
> > Anyway, those are just a few suggestions.  You'll notice that there is a
> > common thread through all of them:  record the knowledge somewhere, make
> > it easy to find.  I think doing at least some of these things would
> > improve support for R, and make it fairly famous (especially if the
> > statistics encyclopedia worked out). 

Once you've been in the game for a while, you realize that it is
extremely important to make documentation *writable*. Only if you have
rather fixed rules for what needs to be documented, and some minimum
standards for what must be in the documentation, then there is a
reasonable chance that things will actually be written down. So the
developers tend to be looking for structural ways of improving the
documentation system, and some new ideas are currently being explored
(have a look at Sweave when 1.5.0 comes out at the end of this month).

And don't be mistaken: The documentation level of R is already much
higher than average for open source software and even than some
commercial packages (esp. SPSS is notorious for its attitude of "You
want to do one of these things. If you don't understand what the
output means, click help and we'll pop up five lines of mumbo-jumbo
that you're not going to understand either.")

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._



More information about the R-help mailing list