You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Should be able to refer to i's .SD during a join. #935
Adding my hat to the ring for this, as it would help solve a problem I encountered recently, basically what @matthieugomez mentioned--
Namely, updating many columns by reference during a join operation, especially when the inner table may have hard-to-predict column names.
That is, DT1[DT2, (names(DT2) := mget(paste0("i.", names(DT2)))] works (though looks clunky), but this approach doesn't work if we're doing something like:
DT1[DT2[,(summarize some variables),by=list(other_variables)],
(what_to_use?):=(hard/inconvenient to predict/control names),on=other_variables]
At least with i.SD, we'd only have to keep track of the number of variables to be joined.
I spotted it is already possible to refer to i's .SD, but using .iSD name rather than i.SD, and only when using by=.EACHI. But it doesn't really give any meaningful answer.
Here, I also have the x column allocated but it's pretty close. So, it seems like this would be easy to implement if we used some of what is done with .SD.
I assume .iSD would by default remove the joining columns. I think the other question is whether .iSD is always allocated or whether it depends on NSE detecting the use of get, mget, eval, or .iSD. To be consistent with .SD memory allocation approach, I assume we would use NSE.
Activity
matthieugomez commentedon Nov 9, 2014
That's be nice.
i.SDwould also be useful if one wants to merge in placedt1[dt2, :=]and keepsdt2columnsMichaelChirico commentedon Sep 3, 2015
Adding my hat to the ring for this, as it would help solve a problem I encountered recently, basically what @matthieugomez mentioned--
Namely, updating many columns by reference during a join operation, especially when the inner table may have hard-to-predict column names.
That is,
DT1[DT2, (names(DT2) := mget(paste0("i.", names(DT2)))]works (though looks clunky), but this approach doesn't work if we're doing something like:At least with
i.SD, we'd only have to keep track of the number of variables to be joined.Here's an example:
It's easy to merge, but not to update
DT1by reference.aryoda commentedon May 4, 2016
Any news on that FR?
Since the i.col and x.col syntax is now supported in joins since 1.9.7 this may be a good code base for implementing x.SD and i.SD variables?
Allow x's cols to be referred to using 'x.' prefix
I'd love to see this feature in the data.table!
UweBlock commentedon Oct 29, 2017
There is a related question on SO: How can I access all columns of
iwhen using .EACHI in data.tableMichaelChirico commentedon Apr 11, 2019
A bit strange that
getworks on'i.col'strings butevaldoes not (as pointed out in #1180).This answer is very clunky; revisit when this is closed
jangorecki commentedon Apr 8, 2020
I spotted it is already possible to refer to
i's.SD, but using.iSDname rather thani.SD, and only when usingby=.EACHI. But it doesn't really give any meaningful answer.ColeMiller1 commentedon Jul 14, 2020
Adding to Jan's observation, we can trick
jisvarsandjiscolsby just includingquote(mget)in a{...}expression:Here, I also have the
xcolumn allocated but it's pretty close. So, it seems like this would be easy to implement if we used some of what is done with.SD.UweBlock commentedon Jul 14, 2020
For the sake of completeness, we can get the same result as in ColeMiler1's comment with
dt1[dt2, lapply(mget(names(dt2)), function(x) sum(y >= x)), by = .EACHI]or
dt1[dt2, lapply(mget(names(.iSD)), function(x) sum(y >= x)), by = .EACHI]BTW, we can get rid of the redundant second
xcolumn bydata.tableversion 1.12.9 used.ColeMiller1 commentedon Jul 14, 2020
@UweBlock that seems more logical 😀
I assume
.iSDwould by default remove the joining columns. I think the other question is whether.iSDis always allocated or whether it depends on NSE detecting the use ofget,mget,eval, or.iSD. To be consistent with.SDmemory allocation approach, I assume we would use NSE.