From Mark.Bravington at csiro.au  Sat Jul  7 03:10:39 2007
From: Mark.Bravington at csiro.au (Mark.Bravington at csiro.au)
Date: Sat, 7 Jul 2007 11:10:39 +1000
Subject: [Rd] rbind.data.frame: bug?
Message-ID: <D79013E40FEF254AAF0D72DFC94F2748545BAF@extas4-hba.tas.csiro.au>

Consider the following, which is new behaviour under R 2.5+:

> df1 <- data.frame( x=2, y='cat')
> df2 <- data.frame( x=3, y='dog')
> rbind( df1[-1,], df2)$y == rbind( df1, df2)[-1,]$y
Error in Ops.factor(rbind(df1[-1, ], df2)$y, rbind(df1,  : 
        Level sets of factors are different
        
To me this seems illogical; it shouldn't matter whether you remove the first row of the data.frame before or after augmenting the rows (and didn't, in R prior to v2.5). And there's more!

> levels( rbind( df1[-1,], df2)$y)
[1] "dog"

> levels( rbind( df1[-1,], df2[-1,])$y)
[1] "cat"

but why should rbind suddenly acknowledge the levels of its first argument in the second case and not the first?

If the data.frames have more than one row, these issue don't arise; they occur because (as the documentation says) "The 'rbind' data frame method first drops all zero-column and zero-row arguments.  (If that leaves none, it returns the first argument with columns otherwise a zero-column zero-row data
     frame.)...". So this behaviour is documented-- but isn't it nevertheless a bug?

>From the release notes, I gather that the new zero-row-stripping behaviour was introduced to get round a specific problem with 0*0 data.frames. Given the above, though, wouldn't it be preferable to just include special code to deal with the 0*0 case, leaving 0*N cases unaffected?

Mark Bravington



[Rd] rbind.data.frame: bug?
Mark.Bravington at csiro.au