Comprendre exactement quand un ensemble de données.le tableau est une référence à (vs une copie) de l'autre des données.table

Je vais avoir un peu de mal à comprendre le passage par référence à des propriétés de data.table. Certaines opérations semblent à "casser" la référence, et j'aimerais comprendre exactement ce qui se passe.

Sur la création d'un data.table à partir d'un autre data.table (via <-, puis la mise à jour de la nouvelle table en :=, la table d'origine est également modifié. C'est prévu, comme par:

?data.table::copy
et stackoverflow: passage par référence-la-opérateur-dans-la-table de données-paquet

Voici un exemple:

library(data.table)

DT <- data.table(a=c(1,2), b=c(11,12))
print(DT)
#      a  b
# [1,] 1 11
# [2,] 2 12

newDT <- DT        # reference, not copy
newDT[1, a := 100] # modify new DT

print(DT)          # DT is modified too.
#        a  b
# [1,] 100 11
# [2,]   2 12

Cependant, si j'insère un non-:= en fonction de modification entre le <- de cession et de la := lignes ci-dessus, DT n'est plus désormais modifié:

DT = data.table(a=c(1,2), b=c(11,12))
newDT <- DT        
newDT$b[2] <- 200  # new operation
newDT[1, a := 100]

print(DT)
#      a  b
# [1,] 1 11
# [2,] 2 12

Il semble donc que la newDT$b[2] <- 200 ligne en quelque sorte des "pauses" de la référence. Je suppose que cela appelle une copie en quelque sorte, mais je voudrais comprendre pleinement comment R est le traitement de ces opérations, pour m'assurer de ne pas introduire des bugs dans mon code.

Je serais très heureux si quelqu'un pourrait-il m'expliquer cela.

Je viens de découvrir cette "fonctionnalité", et c'est horrible. Il est largement préconisée sur les Internets à utiliser <- au lieu de = pour l'affectation de base dans R (par exemple par Google: google.github.io/styleguide/Rguide.xml#affectation). Mais cela signifie que les données.manipulation de la table ne fonctionne pas de la même façon que le bloc de données de manipulation et est donc loin d'une baisse-dans le remplacement de bloc de données.

OriginalL'auteur Peter Fine | 2012-04-19

128

Oui, c'est subassignment dans R à l'aide de <- (ou = ou ->) qui fait une copie de la ensemble objet. Vous pouvez les retrouver que l'utilisation de tracemem(DT) et .Internal(inspect(DT)), comme ci-dessous. Le data.table caractéristiques := et set() assignation par référence à un objet qu'ils sont passés. De sorte que si l'objet a été précédemment copié (par un subassigning <- ou explicite copy(DT)) ensuite c'est la copie qui se modifie par référence.
```
DT <- data.table(a = c(1, 2), b = c(11, 12)) 
newDT <- DT 

.Internal(inspect(DT))
# @0000000003B7E2A0 19 VECSXP g0c7 [OBJ,NAM(2),ATT] (len=2, tl=100)
#   @00000000040C2288 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 1,2
#   @00000000040C2250 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 11,12
# ATTRIB:  # ..snip..

.Internal(inspect(newDT))   # precisely the same object at this point
# @0000000003B7E2A0 19 VECSXP g0c7 [OBJ,NAM(2),ATT] (len=2, tl=100)
#   @00000000040C2288 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 1,2
#   @00000000040C2250 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 11,12
# ATTRIB:  # ..snip..

tracemem(newDT)
# [1] "<0x0000000003b7e2a0"

newDT$b[2] <- 200
# tracemem[0000000003B7E2A0 -> 00000000040ED948]: 
# tracemem[00000000040ED948 -> 00000000040ED830]: .Call copy $<-.data.table $<- 

.Internal(inspect(DT))
# @0000000003B7E2A0 19 VECSXP g0c7 [OBJ,NAM(2),TR,ATT] (len=2, tl=100)
#   @00000000040C2288 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 1,2
#   @00000000040C2250 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 11,12
# ATTRIB:  # ..snip..

.Internal(inspect(newDT))
# @0000000003D97A58 19 VECSXP g0c7 [OBJ,NAM(2),ATT] (len=2, tl=100)
#   @00000000040ED7F8 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 1,2
#   @00000000040ED8D8 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 11,200
# ATTRIB:  # ..snip..
```
Remarquez comment même les a vecteur a été copié (différents hex valeur indique une nouvelle copie de vecteur), même si a n'a pas été changé. Même l'ensemble de b a été copié, plutôt que de simplement en changeant les éléments qui doivent être modifiés. C'est important pour éviter de données pour les grandes, et pourquoi := et set() ont été introduits à data.table.

Maintenant, avec notre copié newDT nous pouvons la modifier par la référence :
```
newDT
#      a   b
# [1,] 1  11
# [2,] 2 200

newDT[2, b := 400]
#      a   b        # See FAQ 2.21 for why this prints newDT
# [1,] 1  11
# [2,] 2 400

.Internal(inspect(newDT))
# @0000000003D97A58 19 VECSXP g0c7 [OBJ,NAM(2),ATT] (len=2, tl=100)
#   @00000000040ED7F8 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 1,2
#   @00000000040ED8D8 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 11,400
# ATTRIB:  # ..snip ..
```
Avis que tous les 3 valeurs en hexadécimal (le vecteur colonne des points, et chacun des 2 colonnes) restent inchangés. Donc c'était vraiment modifié par référence avec aucune copie.

Ou, nous pouvons modifier l'original DT par la référence :
```
DT[2, b := 600]
#      a   b
# [1,] 1  11
# [2,] 2 600

.Internal(inspect(DT))
# @0000000003B7E2A0 19 VECSXP g0c7 [OBJ,NAM(2),ATT] (len=2, tl=100)
#   @00000000040C2288 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 1,2
#   @00000000040C2250 14 REALSXP g0c2 [NAM(2)] (len=2, tl=0) 11,600
#   ATTRIB:  # ..snip..
```
Ces valeurs hexadécimales sont les mêmes que les valeurs d'origine nous l'avons vu pour DT ci-dessus. Type example(copy) pour plus d'exemples sur l'utilisation de tracemem et à la comparaison des data.frame.

Btw, si vous tracemem(DT) puis DT[2,b:=600] vous verrez un exemplaire signalé. C'est une copie de l'10 premières lignes que le print méthode. Lorsque enveloppé avec invisible() ou lorsqu'il est appelé à l'intérieur d'une fonction ou d'un script, la print méthode n'est pas appelée.

Tout cela s'applique à l'intérieur des fonctions trop; c'est à dire, := et set() n'avez pas de copie sur écriture, même à l'intérieur des fonctions. Si vous avez besoin de modifier une copie locale, puis d'appeler x=copy(x) au début de la fonction. Mais, rappelez-vous data.table est pour des données de grande taille (ainsi que plus rapidement avantages de la programmation pour les petits de données). Nous avons délibérément ne veux pas copier les grands objets (jamais). En conséquence, nous ne devons pas permettre l'habituel 3* la mémoire de travail facteur de règle générale. Nous essayons seulement de la mémoire de travail à une colonne (c'est à dire un travail de mémoire, le facteur 1/ncol plutôt que 3).

Quand est ce comportement souhaitable?

OriginalL'auteur Matt Dowle
93

Juste un rapide résumé.

<- avec data.table est juste comme la base; c'est à dire, aucune copie n'est prise jusqu'à ce qu'un subassign est fait par la suite avec <- (comme changer les noms de colonne ou de la modification d'un élément comme DT[i,j]<-v). Ensuite, il faut une copie de l'ensemble de l'objet comme base. Connu sous le nom de copie sur écriture. Serait mieux connu sous le nom de copie sur subassign, je pense! Il NE copie PAS lorsque vous utilisez le spécial := exploitant, ou de la set* fonctions fournies par data.table. Si vous avez de grandes données, vous souhaiterez probablement de les utiliser à la place. := et set* de ne PAS COPIER le data.table, MÊME à l'INTÉRIEUR des FONCTIONS.

Donné cet exemple de données :
```
DT <- data.table(a=c(1,2), b=c(11,12))
```
La suite que "lie" un autre nom DT2 aux mêmes données de l'objet lié est lié au nom de DT :
```
DT2 <- DT
```
Ce ne copie jamais, et jamais des copies de base. Elle marque simplement l'objet de données de sorte que R sait que les deux noms différents (DT2 et DT) pointent vers le même objet. Et donc R aurez besoin de copier l'objet, si l'un et l'autre sont subassigned pour la suite.

Qui est parfait pour data.table, trop. Le := n'est pas pour le faire. Donc la suite est une faute intentionnelle comme := n'est pas juste pour la liaison des noms d'objets :
```
DT2 := DT    # not what := is for, not defined, gives a nice error
```
:= est pour subassigning par référence. Mais vous ne l'utilisez pas comme vous le feriez dans la base :
```
DT[3,"foo"] := newvalue    # not like this
```
vous l'utiliser comme ceci :
```
DT[3,foo:=newvalue]    # like this
```
Qui a changé DT par référence. Dites vous ajoutez une nouvelle colonne new par référence à l'objet de données, il n'est pas nécessaire pour ce faire :
```
DT <- DT[,new:=1L]
```
parce que le membre de droite déjà changé DT par référence. L'extra DT <-, c'est mal comprendre ce que :=. Vous pouvez l'écrire là, mais c'est superflu.

DT est modifié par référence, par :=, MÊME à l'INTÉRIEUR des FONCTIONS :
```
f <- function(X){
    X[,new2:=2L]
    return("something else")
}
f(DT)   # will change DT

DT2 <- DT
f(DT)   # will change both DT and DT2 (they're the same data object)
```
data.table est pour les grands ensembles de données, n'oubliez pas. Si vous avez un 20 GO data.table dans la mémoire, alors vous besoin d'un moyen pour ce faire. C'est un très délibérée décision de conception de data.table.

Des Copies peuvent être faites, bien sûr. Vous avez juste besoin de raconter des données.la table que vous êtes sûr que vous voulez copier vos 20 GO jeu de données, à l'aide de la copy() fonction :
```
DT3 <- copy(DT)   # rather than DT3 <- DT
DT3[,new3:=3L]     # now, this just changes DT3 because it's a copy, not DT too.
```
Pour éviter les copies, ne pas utiliser de base de type affectation ou de mise à jour :
```
DT$new4 <- 1L                 # will make a copy so use :=
attr(DT,"sorted") <- "a"      # will make a copy use setattr() 
```
Si vous voulez être sûr que vous êtes la mise à jour par l'usage de référence .Internal(inspect(x)) et de regarder l'adresse de la mémoire de valeurs de composantes (voir Matthieu Dowle de réponse).

Écrit := dans j comme qui vous permet subassign par référence par groupe. Vous pouvez ajouter une nouvelle colonne en référence par le groupe. C'est pourquoi := est fait de cette façon à l'intérieur de [...] :
```
DT[, newcol:=mean(x), by=group]
```
OriginalL'auteur statquant

Vous devez vous connecter pour publier un commentaire.

Juste un rapide résumé.