-
Notifications
You must be signed in to change notification settings - Fork 998
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
nomatch=0 fires incorrect (?) warning #2399
Comments
No, that is not what the join is meant to do. A join
Currently, there is no join/index/"bmerge" functionality for |
But in the case of |
Warning comes not from
Thus recycling does not occur in resulting table but in input table that you want to join to. Closing then. |
Consider the following
This is a reasonable warning - as we can see, the first column has been recycled. However:
I don't think this is reasonable - since we've specified
nomatch=0
there should be no issue. This is a toy example, but the use case is to return all rows which contain a value in some candidate vector (here1:2
andLETTERS[1:3]
) i.e.a %in% 1:2 & b %in% LETTERS[1:3]
.As a separate aside
dt[.(1:2, LETTERS[1:4]), nomatch=0]
doesn't throw an error, because (I guess) it deems that recycling is expected when lengths are multiples (as per normal R behaviour). However, it means the appearance of this bug depends on the length of the candidate vectors I provide (specifically, whether the smaller is a divisor of the other), which is not intuitive for this use case: if I know columna
only contains1:2
then I should be able to specify1:2
or1:12345
as my candidate vector, and get the same result. This isn't the case here.Again - it makes sense with
nomatch=NA
, but notnomatch=0
. I'm not sure how easy it is to fix this ... I suspect it's just internal reordering of code so thatnomatch=0
gets implemented before passing toas.data.table.list
.The text was updated successfully, but these errors were encountered: