[R] aggregate function - na.action

[Matthew Dowle]

Hadley,

That's fine; please do. I'm happy to explain it offline where the 
documentation or comments in the
code aren't sufficient. It's GPL code so you can take it and improve it, or 
depend on it.
Whatever works for you. As long as (of course) you don't stand on it's 
shoulders and then
restrict users' freedoms (not that I'd ever think you'd do that).

One thing that did make it into R was the improvement to unique.c in R 
2.12.0.

Another that we hope happens one day is changing duplicate.c to use memcpy.
That would automatically benefit all users anywhere R copies data (including 
data.frame).
That wasn't our idea; that's been a FIXME in the R source for many years. 
See thread
on r-devel a while back (search for duplicate.c in subject). It probably 
just needs someone
to send a working patch file that passes checks. That's an example of 
something in the
data.table C code that (hopefully) will make it into base R.

Matthew


"Hadley Wickham" <hadley at rice.edu> wrote in message 
news:AANLkTi=SeTPQuiYr1+AVb4-Ga1-FYh9uffA6mskk+bqC at mail.gmail.com...
> Does FAQ 1.8 answer that ok ?
> "Ok, I'm starting to see what data.table is about, but why didn't you
> enhance data.frame in R? Why does it have to be a new package?"
> http://datatable.r-forge.r-project.org/datatable-faq.pdf

Kind of.  I think there are two sets of features data.table provides:

 * a compact syntax for expressing many common data manipulations
 * high performance data manipulation

FAQ 1.8 answers the question for the syntax, but not for the
performance related features.

Basically, I'd love to be able to use the high performance components
of data table in plyr, but keep using my existing syntax.  Currently
the only way to do that is for me to dig into your C code to
understand why it's fast, and then implement those ideas in plyr.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/