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
warning(_("Coerced j from numeric to integer. Please pass integer for efficiency; e.g., 2L rather than 2"));
I find this warning a bit annoying. It's very common in R to have double "just work" as integer. Why this of all places is there an efficiency concern?
I can't imagine the efficiency concern is real anyway -- unless we are coercing 1e7+ column numbers to integer I can't imagine there's a real performance implication.
I also see two cases where this might come up:
You are passing j as a variable to set():
setDT(DT, , col_idx, val)
In this case, the recommendation is to do as.integer(col_idx), which is what assign.c is doing implicitly. Is there really any difference in efficiency?
You are doing interactive work (as I just was when I came across this) and lazily omitting the L:
setDT(DT, , c(1, 4), NULL)
OK, I could write 1L/4L, and in package/production code, I probably should. But to throw a warning seems a bit heavy-handed. Users really under such use cases should be using lintr::implicit_integer_linter() to catch such cases.
data.table/src/assign.c
Line 428 in afa87e1
I find this warning a bit annoying. It's very common in R to have double "just work" as integer. Why this of all places is there an efficiency concern?
I can't imagine the efficiency concern is real anyway -- unless we are coercing 1e7+ column numbers to integer I can't imagine there's a real performance implication.
I also see two cases where this might come up:
You are passing
j
as a variable toset()
:In this case, the recommendation is to do
as.integer(col_idx)
, which is whatassign.c
is doing implicitly. Is there really any difference in efficiency?You are doing interactive work (as I just was when I came across this) and lazily omitting the
L
:OK, I could write
1L
/4L
, and in package/production code, I probably should. But to throw a warning seems a bit heavy-handed. Users really under such use cases should be usinglintr::implicit_integer_linter()
to catch such cases.Originally added a long time ago: e2cf7e2
The text was updated successfully, but these errors were encountered: