13

好吧，这有点奇怪...似乎通过使用 := 运算符在 data.table 中创建一个新列，先前分配的变量（使用 colnames 创建）会静默变化。

这是预期的行为吗？如果不是，有什么过错？

# Lets make a simple data table
require(data.table)
dt <- data.table(fruit=c("apple","banana","cherry"),quantity=c(5,8,23))
dt
    fruit quantity
1:  apple        5
2: banana        8
3: cherry       23

# and assign the column names to a variable
colsdt <- colnames(dt)
str(colsdt)
 chr [1:2] "fruit" "quantity"

# Now let's add a column to the data table using the := operator
dt[,double_quantity:=quantity*2]
dt
    fruit quantity double_quantity
1:  apple        5              10
2: banana        8              16
3: cherry       23              46

# ... and WITHOUT explicitly changing 'colsdt', let's take another look:
str(colsdt)
 chr [1:3] "fruit" "quantity" "double_quantity"

# ... colsdt has been silently updated!

为了比较起见，我想看看通过 data.frame 方法添加新列是否有同样的问题。它没有：

dt$triple_quantity=dt$quantity*3
dt
    fruit quantity double_quantity triple_quantity
1:  apple        5              10              15
2: banana        8              16              24
3: cherry       23              46              69

# ... again I make no explicit changes to colsdt, so let's take a look:
str(colsdt)
 chr [1:3] "fruit" "quantity" "double_quantity"

# ... and this time it is NOT silently updated

那么这是 data.table := 运算符的错误，还是预期的行为？

谢谢！

4

1 回答 1

18

简答，使用copy

colsdt <- copy(colnames(dt))

那么你们都很好。

dt[,double_quantity:=quantity*2]
str(colsdt)
# chr [1:2] "fruit" "quantity"

通常情况下（即在 base 中R），赋值运算符<-在为对象赋值时会创建对象的新副本。即使在分配给相同的对象名称时也是如此，例如x <- x + 1，或者成本更高， DF$newCol <- DF$a + DF$b。对于大型对象（想想 100K+ 行，数十或数百列。如果列更多，则更糟），这可能会变得非常昂贵。

data.table，通过纯魔法（阅读：C 代码）避免了这种开销。相反，它所做的是将指针设置为指向已存储对象值的同一内存位置。这就是提供巨大效率和加速提升的原因。

但这也意味着您经常拥有看起来完全不同的对象，而独立的对象实际上是相同的

这就是copy进来的地方。它创建一个对象的新副本，而不是通过引用传递。

关于为什么会发生这种情况的更多细节。

注意：我非常松散地使用术语“源”和“目标”，它们指的是分配关系 destination <- source

这实际上是预期的行为，诚然有点混淆。

在 baseR中，当您分配 via 时<-，这两个对象指向相同的内存位置，直到其中一个对象发生更改。这种处理内存的方式有很多好处，即只要两个对象具有相同的精确值，就不需要复制内存。尽可能长时间地推迟这一步。

a <- 1:5
b <- a
.Internal(inspect(a))  # @11a5e2a88 13 INTSXP g0c3 [NAM(2)] (len=5, tl=0) 1,2,3,4,5
.Internal(inspect(b))  # @11a5e2a88 13 INTSXP g0c3 [NAM(2)] (len=5, tl=0) 1,2,3,4,5
                            ^^^^  Notice the same memory location

一旦这两个对象中的任何一个发生了变化，那么这种“联系”就会被打破。也就是说，更改“源”或“目标”对象将导致该对象被重新分配到新的内存位置。

a[[3]] <- a[[3]] + 1
.Internal(inspect(a))  # @11004bc38 14 REALSXP g0c4 [NAM(1)] (len=5, tl=0) 1,2,4,4,5
                             ^^^^ New Location
.Internal(inspect(b))  # @11a5e2a88 13 INTSXP g0c3 [NAM(2)] (len=5, tl=0) 1,2,3,4,5
                          ^^^^^ Still same as it was before; 
                                note the actual value. This is where `a` _had_ been

data.tables 案例中的问题是我们很少重新分配实际的 data.table 对象。请注意，如果我们修改“目标”对象，那么它会被移动（复制）出该内存位置。

colsdt <- colnames(dt)
.Internal(inspect(colnames(dt)))  # @114859280 16 STRSXP g0c7 [MARK,NAM(2)] (len=2, tl=100)
.Internal(inspect(colsdt))        # @114859280 16 STRSXP g0c7 [MARK,NAM(2)] (len=2, tl=100)
                                      ^^^^  Notice the same memory location
# insiginificant change
colsdt[] <- colsdt
.Internal(inspect(colsdt))       # @100aa4a40 16 STRSXP g0c2 [NAM(1)] (len=2, tl=100)

# we can test the original issue from the OP:
dt[, newCol := quantity*2]
str(colnames(dt))   #  chr [1:3] "fruit" "quantity" "newCol"
str(colsdt)         #  chr [1:2] "fruit" "quantity"

要避免的情况：

但是，由于在使用 时data.table，我们（几乎）总是通过引用进行修改，这可能会导致意想不到的结果。即，以下情况：

  • 我们使用标准赋值运算符从data.table 对象赋值<-
  • 然后随后我们更改“源” data.table 的值
  • 我们期望（并且我们的代码可能依赖于）“目标”对象仍然具有先前分配给它的值。

这当然会引起问题。

data.table是一个非常强大的软件包。它的力量来源是它的长毛，它尽可能避免复制。

最佳实践：

这将责任转移到用户在复制和期望复制时要慎重和明智。

换句话说，最佳实践是：当您期望副本存在时，请使用复制功能。

于 2013-05-14T12:39:10.873 回答