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
There is wide range of features that data.table has in context of ordered observations, if one works with timeseries data it is definitely worth to be aware of those:
key - clustered index
rleid
shift
rolling funs (yet to be completed)
nafill, setnafill
between
inrange
rolling join
non-equi .EACHI join
foverlaps
A while ago I gave a data.table presentation at work, and now I realize that some of the material in the .Rmd file for the slides possibly may be of some use during the preparation of this vignette.
So far I have short text snippets, and in most cases visualizations, for the following topics:
brief on normal join
rolling join: nearest, Inf. -Inf, fixed distance
non-equi join
between & inrange
rleid
shift
nafill & setnafill
Please let me know if this may be something you wish to have a look at. I'm happy to share. And of course: just feel free to ignore it.
@jangorecki A first draft of the .Rmd file is soon ready. Two questions of a more PR technical character: (1) Is it correct to assume that a test is not relevant for a vignette? At least I could find one for e.g. New vignette -- Usages of .SD. (2) Should I create a NEWS entry despite this is, at least from my perspective, very much work in progress?
Yes, we don't need new unit tests for vignette. If you want to make your vignette future proof, one good option is to add hidden R chunks (include=F) in Rmd. In those chunks stopifnot()'s, so whenever a code will not meet expectations defined there, the vignette will terminate and not be built, we will easily spot that. But this is not really that important.
We will need NEWS entry ultimately, but vignette is likely to be evolving before it will be merged, so not really important yet.
Please ensure you push to Rdatatable org repo, so it will be easy for others to push commits there.
Yes, we don't need new unit tests for vignette. If you want to make your vignette future proof, one good option is to add hidden R chunks (include=F) in Rmd. In those chunks stopifnot()'s, so whenever a code will not meet expectations defined there, the vignette will terminate and not be built, we will easily spot that. But this is not really that important.
Activity
Henrik-P commentedon Apr 22, 2020
Hi @jangorecki!
A while ago I gave a
data.tablepresentation at work, and now I realize that some of the material in the .Rmd file for the slides possibly may be of some use during the preparation of this vignette.So far I have short text snippets, and in most cases visualizations, for the following topics:
Please let me know if this may be something you wish to have a look at. I'm happy to share. And of course: just feel free to ignore it.
jangorecki commentedon Apr 22, 2020
@Henrik-P sure!
Henrik-P commentedon Apr 22, 2020
OK, thanks! I'm not a very skilled github user, so I will need to re-read the Contribution guidelines on how to share the .Rmd file the proper way ;)
Henrik-P commentedon Apr 24, 2020
@jangorecki A first draft of the .Rmd file is soon ready. Two questions of a more PR technical character: (1) Is it correct to assume that a
testis not relevant for a vignette? At least I could find one for e.g. New vignette -- Usages of .SD. (2) Should I create aNEWSentry despite this is, at least from my perspective, very much work in progress?Cheers
jangorecki commentedon Apr 24, 2020
include=F) in Rmd. In those chunksstopifnot()'s, so whenever a code will not meet expectations defined there, the vignette will terminate and not be built, we will easily spot that. But this is not really that important.Please ensure you push to Rdatatable org repo, so it will be easy for others to push commits there.
MichaelChirico commentedon Apr 27, 2020
very nice trick!