[datatable-help] data.table and aggregating out-of-order columns in result from by

[Clayton Stanley]

Copied from this SO post: http://stackoverflow.com/questions/23097461

Here's some interesting behavior that I noticed with data.table 1.9.2

>   testFun <- function(val) {
        if (val == 'geteeee') return(data.table(x=4,y=3))
        if (val == 'get') return(data.table(y=3,x=4))
    }>   tbl = data.table(val=c('geteeee', 'get'))>   tbl[,
testFun(val), by=val]
       val x y1: geteeee 4 32:     get 3 4>

When the column order of the data tables returned from each call to testFun
are mixed (but have the same name and number of columns), data.table
silently binds the tables together without taking into account that they
are out of order. This was probably done for speed, but I found the
behavior quite unexpected, and would have appreciated at least a warning.

Is there a way that I can get data.table to warn or error when this
situation happens?

This happened in my analysis code and caused values for two DVs to be
intermixed. The reason why it happened is that in the 'testFun' there is a
branch and the returned data table is created within both sides of the
branch. The branch is necessary to handle the case where the data table
used to create the final returned data table is empty. So on one side of
that branch I basically create an empty data table with the correct
columns, and on the other side the data table is created from the first.
The point is that the column order for the data tables returned from each
side of the branch are different. Now this is certainly a bug on my part in
'testFun'. However I could have caught the issue much earlier if I had
received a warning from data.table when the by operation completed and the
resulting tables were bound together.

Also since there isn't a check for column order, it does make me worry that
there are other places in my analysis code where the same thing could be
happening. What would be ideal is if there was some way for me to tell if
that is the case. Perhaps a warning, temporarily increasing a 'safety'
level as an options call, etc. Usually data.table is great at warning me
when things are not quite right, so I was surprised when I noticed the
current behavior. I understand that this was done for speed. So maybe
temporarily increasing a 'safety' level is a way to keep things fast by
default and have additional checks (for a speed cost) when the user wants
them? This sort of mimics how compiler optimization declarations are done
in common lisp.

-Clayton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/datatable-help/attachments/20140416/49f06e94/attachment.html>