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
However it won't be "as originally", since dcast sorts by the LHS of ~. Not sure if I'm missing something here, but this result does match the direct one DT[, Reduce(+, .SD), keyby=V1:V20, .SDcols=X1:X50]
Indeed you're right. However my particular application here is part of an intro to R so I'm trying to demonstrate reshaping, and Reduce-based stuff should probably be reserved for well beyond when people have gotten their feet wet.
Anyway, I don't think it's unheard of to find data in a .csv in DT_m form to start with, so that we'd need this instead of the Reduce approach.
Good suggestion on just deleting variable... may be the only way to go since I know this FR probably runs up against compatibility with reshape2::dcast.
I agree. I wasn't suggesting the Reduce way as an alternative, just using it to verify that my result was correct (since I was seeing different numbers from those you showed in the OP).
Consider:
I want to reshape
DT_m
back to being "wide". I wantV1:20
to be as originally inDT
, but to aggregate all ofX1:50
by summing into a single column.It seems the way to do this is:
But obviously it's not optimal to need to type all the variables on the LHS. I thought that was the point of
...
, but this doesn't work:...
has includedX
, so the returned table is justDT_m
(withX
renamed to.
).The text was updated successfully, but these errors were encountered: