+1 for T and F, but definitely not because it's that way in read.csv (which imo is not a good reason), but rather because those are commonly used substitutes for TRUE and FALSE. On Sep 14, 2013 5:29 AM, "Arunkumar Srinivasan" <[email protected]> wrote:
> Matthew, > > +1 for retaining T and F like read.csv. > +1 for the dropins() feature as well. > > Arun > > On Saturday, September 14, 2013 at 11:53 AM, Matthew Dowle wrote: > > On 14/09/13 06:48, Chinmay Patil wrote: > > I didn't mean changes in data.table's interface but the way data.table > works in itself compared to normal data frames. I know there are valid > reasons for structuring data.table's interface the way it is but not all > users get it immediately. > > > The bottom line in my mind is that even if base syntax was sped up > (assignment to an unnamed data.frame needn't copy the whole data.frame > for example), I would still move from > subset()/transform()/with()/DF[i,j]<-value syntax, to i,j and by inside > [...] with .SD,.I,.N and := in j. I can do things with that syntax > that I need to do which aren't always so easy with base syntax (like > adding columns by reference by group). > > And base R syntax is indeed being sped up by pqR, Renjin, Riposte, TERR, > CXXR, fastr which may feed into GNU R. Once that is mature and the dust > has settled, I would still move from data.frame to data.table on each of > them. Maybe we should market the things that data.table does that base > R doesn't. Rather than speed differences. > > > As for data.table, I am not complaining, just saying what other users > complaints I have heard of. > I personally love data.table and am willing to put the effort to learn > best ways to use it while most users aren't. > > > Great. data.table is for people like you. > > So we'll keep the default fread'ing of "T" and "F" as logicals then for > consistency with read.csv. > > And I still hope to produce a drop-in replacement for read.csv which > returns a data.frame but uses fread under the hood. That will speed up > existing code, but users can use the extra features of fread if they > want, too. > > Matthew > > > Chinmay > > On 14 Sep, 2013, at 1:29 PM, Steve Lianoglou <[email protected]> > wrote: > > Thanks for the quick response. > > As for the "learning curve" stuff -- no real comment there, but: > > For eg. I recently heard complains about data.table itself from due to > changes in interface > > Could you provide some concrete examples about which changes have > stumped users? Perhaps we can learn from these critiques. I had > thought we were pretty good about discussing any (breaking) changes on > list, but I'd be interested to see where this has failed so it might > perhaps be avoided in the future. > > and learning curve that data.table comes with... I hear > similar complaints about some packages like ggplot2, plyr.. > > Even though all these are great packages.. people don't like radical > changes > to interfaces as it makes refactoring older code even more painful. > > Still curious to hear what radical changes have come down the pipe. > > Thanks for taking the time to comment. > > Cheers, > -steve > > -- > Steve Lianoglou > Computational Biologist > Bioinformatics and Computational Biology > Genentech > > _______________________________________________ > datatable-help mailing list > [email protected] > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help > > > _______________________________________________ > datatable-help mailing list > [email protected] > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help > > > > _______________________________________________ > datatable-help mailing list > [email protected] > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help >
_______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
