-
Notifications
You must be signed in to change notification settings - Fork 1k
Added shallow search for data.table in tables() #7580
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
base: master
Are you sure you want to change the base?
Conversation
…o feat/adding_list_search_to_tables
|
Hello, I created a new PR in replacement of #7568 Reasons: There was some git issue there and the merge became too complex and I changed the algo because I didnt know previously that rbind or cbind would cost for re-allocation The current PR considers that part and avoids appends Previous PR : creating seperate data.table called info and rbind at the end |
|
In reply to previous comment of @jangorecki An example of when this new feature could be useful? To support lists which occur due to split.data.table or fread like the following The original code supported data.table() top level and this code adds support for list(data.table) if the arg |
|
Example of the original code and the new feature is as follows
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #7580 +/- ##
=======================================
Coverage 99.02% 99.03%
=======================================
Files 87 87
Lines 16896 16937 +41
=======================================
+ Hits 16732 16773 +41
Misses 164 164 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
No obvious timing issues in HEAD=feat/adding_list_search_to_tables Generated via commit c65ff92 Download link for the artifact containing the test results: ↓ atime-results.zip
|
inst/tests/tests.Rraw
Outdated
| xenv2$N = list(a = 1:5) | ||
| setkey(xenv2$M$b, a) | ||
| setindex(xenv2$M$b, b) | ||
| test(2360.1, tables(env = xenv2, shallow_search = TRUE)$NAME, c("DT", "L[[1]]", "L[[2]]", "M$b")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prefer saving the output to re-running tables(env = xenv2, shallow_search = TRUE) many times.
alternatively, just do one test like
test(2360.1, tables(env = xenv2, shallow_search = TRUE)[, .(NAME, NROW, NCOL)], data.table(...))There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
making it one test
| xenv2$M = list(b = data.table(a = 1, b = 4:6), a = 1:5) | ||
| xenv2$N = list(a = 1:5) | ||
| setkey(xenv2$M$b, a) | ||
| setindex(xenv2$M$b, b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I would move setindex() closer to the index=TRUE tests
R/tables.R
Outdated
| } | ||
| } | ||
| else { | ||
| # the original code path when shallow_search=FALSE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this comment doesn't make sense outside the context of this PR, "the original code path" will be a relic within a few months
R/tables.R
Outdated
| tables = function(mb=type_size, order.col="NAME", width=80L, | ||
| env=parent.frame(), silent=FALSE, index=FALSE) | ||
| env=parent.frame(), silent=FALSE, index=FALSE, | ||
| shallow_search=FALSE) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking the best way to go about this is actually something like either depth=0 or recursive=FALSE. Then both cases share the same logic, except that the default cuts out after the shallow search.
If the code to do a recursive walk is proving intimidating, we can do depth=0, and this PR can support depth=1 and error for depth>1 "not yet supported" and leave it for future work.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah we can do a depth = 0, 1 and error at depth >1 for this PR
…o feat/adding_list_search_to_tables
R/tables.R
Outdated
| } | ||
| else { | ||
| # for depth greater than 1L,recursion is not implemented yet | ||
| stop("depth > 1L is not implemented yet", call. = FALSE) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, sorry, the "correct" way to make that lint go away is to use stopf() instead
R/tables.R
Outdated
| list_index = which(is_list & !is_dt & !is_df) | ||
| # obj_list is a list of lists of data.tables found inside lists | ||
| obj_list = vector("list", length(list_index)) | ||
| #make a listof size list_index and add wl in it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| #make a listof size list_index and add wl in it | |
| # make a list of size list_index and add wl in it |

Closes #2606
added arg
depth = 1Lto tables() one for shallow searchif
depthis 0 then its the data.tableif
depthis 1, we loop through list-like objects using is.list and which are not data.table or data.frameif
depth> 1, we throw erroradded name for the nested list found
parent[[1]]orparent$childpre-allocating info to avoid reallocation cost