From the recent developer.r-project.org “Staged Install” article:
Incidentally, there were just two distinct (very long) lists of methods in the warnings across all installed packages in my run, but repeated for many packages. It turned out that they were lists of exported methods from dplyr and rlang packages. These two packages take very long to install due to C++ code compilation.
dplyr indeed uses
rlang appears to currently be a
C-package. So any problems associated with
rlang are probably not due to
Rcpp. Similarly other tidyverse packages such as
tibble are currently
C packages. I think
purrr once used
C++, but do not know about the others.
The (matter of opinion) claim:
“When the use of C++ is very limited and easy to avoid, perhaps it is the best option to do that […]”
(source discussed here)
got me thinking: does our own RcppDynProg package actually use C++ in a significant way? Could/should I port it to C? Am I informed enough to use something as complicated as C++ correctly?
Continue reading Why RcppDynProg is Written in C++
While developing the
R package I took a little extra time to port the core algorithm from
C++ to both
This means I can time the exact same algorithm implemented nearly identically in each of these three languages. So I can extract some comparative “apples to apples” timings. Please read on for a summary of the results.
Continue reading Timing the Same Algorithm in R, Python, and C++
RcppDynProg is a new
R package that implements simple, but powerful, table-based dynamic programming. This package can be used to optimally solve the minimum cost partition into intervals problem (described below) and is useful in building piecewise estimates of functions (shown in this note).
Continue reading Introducing RcppDynProg