Patrick Burns <pburns@pburns.seanet.com>
> * What were your biggest misconceptions or
> stumbling blocks to getting up and running
> with R?

I came into R from SAS, with its powerful data step language and very 
simplified data types.  Most of my work is data manipulation prior to a 
variety of univariate statistical calculations.  The vector-based nature 
of R, and thus the variety of indexing schemes used, was a big conceptual 
hurdle. 

The often unhelpful attitude of several list respondents, while not unique 
to this list, was and continues to be another block to advancement.  This 
does not occur on the list for SAS, in which asking 'dumb' questions is 
generally supported as an inevitable part of learning.  Having aggregate() 
pointed out to me by one kind soul, hidden amidst the assortment of 
by()/apply() functions, became the basis for much success.

I am currently trying to wrap my mind around how missing values are 
handled; the defaults are quite different than SAS, and mostly in a good 
way.  However the handling of NA values in a slicing statements does not 
seem quite proper, even if it is addressed in the R documents.
        aa <- data.frame('id'=letters[1:5], 'x'=1:5, 
stringsAsFactors=FALSE)
        aa[aa$x == 3,]$x <- NA
        aa[aa$x == '4',]            # 2 rows instead of 1.
        aa[aa$x %in% '4',]          # 1 row as expected.

I am also looking for concise methods for building up dataframes for our 
unit tests.  While there are several ways to accomplish this, depending on 
what is needed, none are elegant though expand.grid() comes close.

next: The R inferno.  I *will* understand more than the first few pages. 
And all those apply()-ish functions, as I'm already good friends with 
aggregate().

> * What documents helped you the most in this
> initial phase?

RSeek.org was and continues to be a big source of help. I've looked at 
several texts aimed at beginners, and all provided simple examples that 
were useful.  The most consistent source of instruction has been to make 
up my own small projects that were either fun or slightly relevant to my 
job.  The ability to make up toy problems, or simplify a complex process 
have been unexpectedly important skills.  Developing unit tests for 
functions, initially seen as an irritant by some, has become an important 
tool for honing our advances.

> I especially want to hear from people who are
> lazy and impatient.

And, I hope, incompetent.  I've found incompetence to be as professionally 
important as hubris.  I wouldn't want one without the other.

cur

-- 
Curt Seeliger, Data Ranger
Raytheon Information Services - Contractor to ORD
seeliger.curt@epa.gov
541/754-4638


	[[alternative HTML version deleted]]

