Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: assign names to CJ() like data.table() does #1596

Closed
franknarf1 opened this issue Mar 17, 2016 · 3 comments · Fixed by #2977
Closed

FR: assign names to CJ() like data.table() does #1596

franknarf1 opened this issue Mar 17, 2016 · 3 comments · Fixed by #2977
Milestone

Comments

@franknarf1
Copy link
Contributor

franknarf1 commented Mar 17, 2016

I frequently do

DT[CJ(colA = colA, colB = colB, unique=TRUE), on=c("colA","colB")]
# to complete missing levels

# or 
DT[, CJ(colA = colA, colB = colB, unique=TRUE)][!DT, on=c("colA","colB")]
# to identify missing levels
# http://stackoverflow.com/a/36065607/1191259

It would be nice if I could get away with writing colA and colB fewer times. The FR here is for

CJ(colA, colB, unique=TRUE, names=TRUE) 

to infer the names colA and colB, perhaps using whatever method is used by data.frame() and data.table() (make.names?).

(The name repetition could be reduced further if on=.Icols were a thing, I suppose, but I'll leave that for a separate FR.)

SO posts to update...

@jangorecki
Copy link
Member

CJ takes ... as first argument, and that function is going to be generic method, so AFAIK we will need to change it into CJ(x, ...), those changes can be made together #1090

@eantonya
Copy link
Contributor

eantonya commented May 18, 2016

+1 and I don't see the need for the names argument - this should be the only behavior. With the join syntax change to using "on" instead of setkey this has become a big sticking point for me.

I'd also like to see unique = TRUE be the default - I can't think of ever not needing to unique the arguments to CJ.

@MichaelChirico
Copy link
Member

MichaelChirico commented Jul 17, 2018

@jangorecki I didn't touch the #1090 / #814 stuff yet. better as self-contained, I think, unless I'm missing something

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants