Pierre Donat-Bouillud

R4R: Reproducibility for R

Wed, 30 Jul 2025 22:04:18 -0700

Ensuring reproducibility is a fundamental challenge in computational research. Reproducing results often requires reconstructing complex software environments involving data files, external tools, system libraries, and language-specific packages. While various tools aim to simplify this process, they often rely on user-provided metadata, overlook system dependencies, or produce unnecessarily large environments.

R Markdown notebooks are a popular format for data analysis. In this project, we focus on the reproducibility of computational notebooks in R. We aim to automate the creation of minimal, user-inspectable, self-contained execution, distributable environments through dynamic program analysis techniques.

We created a tool, r4r, that captures all runtime dependencies of a data analysis pipeline and produces a Docker image capable of reproducing the original execution. Although designed with first-class support for the R programming language, r4r also includes a generic fallback mechanism applicable to other languages.

This project is financed by the ERC PoC grant 101081989 and spans from January 2024 to June 2025.

Data Bugs

Thu, 04 May 2023 17:47:54 +0200

The goal of this project is to develop new programming language technologies to assist data scientists, using the R language for empirical validation of our novel ideas.

The project is financed by the operational program Jan Amos Comenius and spans from March, 2023, to March, 2025.

Fuzzing R

Mon, 17 Apr 2023 16:38:11 +0200

R is a vector-oriented, dynamic language, mostly used in data-science. It is difficult to statically analyze, and so we mainly use dynamic techniques to gather insights about R programs. One instance of them is fuzzing.

We do not use fuzzing in R only to find bugs¹ but also to dynamically infer type signatures, or other interesting properties of R programs.

Although we also have found plenty of them! ↩︎

Finding NA in serialized R values

Tue, 04 Apr 2023 15:30:43 +0200

In a previous post, I explained how to test a C++ function, find_na, used in a database for R values. find_na checks if NA is present or not in a previously serialized R value. By not unserializing the value, it avoids unnecessary allocations.

Serialization of R values

Native R serialization functions are defined in serialize.c in the R codebase. Three versions of the serialization are available; I use the latest one. The serialization starts with a header indicating how atomic values are serialized, including the character encoding, and then recursively traverses the R value.

R_InitOutPStream first creates a stream in which to write the serialized value and then R_serialize performs the actual serialization:

 WriteBuffer write_buffer(buf);
R_outpstream_st out;
R_InitOutPStream(&out,
reinterpret_cast<R_pstream_data_t>(&write_buffer),
R_pstream_binary_format,
3, //version of the serialization
append_byte, append_buf,
refhook_write, R_NilValue);
R_Serialize(val, &out);

R_pstream_data_t is an alias for void*. It is passed as an argument to callbacks append_byte and append_buf;
R_pstream_binary_format indicates that atomic values should be serialized as binary. Among other formats are XDR, with R_pstream_xdr_formatR_pstream_xdr_format or ASCII, with R_pstream_ascii_format;
refhook_write provides a way to customize the serialization of some values. In sxpdb, we use it to disable serialization for environments.

SEXP Serializer::refhook_write(SEXP val, SEXP data) {
if(TYPEOF(val) != ENVSXP) {
return R_NilValue;//it means that R will serialize the value as usual
}
// We just do not serialize the environment and return a blank string
return R_BlankScalarString;
}

The R_NilValue passed last to R_InitOutPStream is the second argument of refhook_write.

Partially unserializing

The database stores the serialized values, stripped of the header with the version of the serialization and the encoding.

Function unserialize_view takes a serialized value — a buffer of bytes — from the database and returns a sexp_view_t, which holds pre-computed metadata on the serialized view.

const sexp_view_t Serializer::unserialize_view(
const std::vector<std::byte>& buf);
struct sexp_view_t {
SEXPTYPE type = ANYSXP;
const void* data = nullptr;
size_t length = 0;
size_t element_size = 0;
};

For vector types, the serialized value then comprises flags, the length of the vector, and the actual data in the vector:

The flags include the type and the presence of attributes of the value:

int flags = 0;
std::memcpy(&flags, data, sizeof(int));
sexp_view.type = flags & 255;
bool has_attr = flags & (1 << 9);

The function then stores the actual value data in the data field.

For vector values (character, logical, integer, real, complex), length in sexp_view_t stores the number of elements in the vector. element_size represents the number of bytes of an element in the vector. For character vectors, that one does not make sense: in R, character vectors of type STRSXP are actually vectors of atomic strings, of type CHARSXP, which have variable length.

Looking for `NA`

For logical and integer vectors, we can simply look for the magic NA value in the data field, after casting it to an integer, as v:

std::find(v, v + length, NA_LOGICAL) != v + length;

For real vectors, NA is a more complicated beast. There is an existing protocol for missing values defined by the floating point standard (IEEE 754): representing them with NaN. In R, NA is NaN with a special bit pattern: the lowest word is 1954, the year Ross Ihaka, one of the creator of the R Language, was born.

static double R_ValueOfNA(void)
{
/* The gcc shipping with Fedora 9 gets this wrong without
* the volatile declaration. Thanks to Marc Schwartz. */
volatile ieee_double x;
x.word[hw] = 0x7ff00000;
x.word[lw] = 1954;
return x.value;
}

The C R API provides R_IsNA to simplify the check:

std::find_if(v, v + length, [](double d) -> bool {
return R_IsNA(d) ;}) != v + length;

Complex vectors are NA if the real or the imaginary part is NA:

std::find_if(v, v + length, [](const Rcomplex& c) -> bool {
return ISNAN(c.r) || ISNAN(c.i);}) != v + length;

Character vectors are again more complex. Each CHARSXP element of the vector is again a valid R value and so is serialized with the flags and then the length of the element. NA is the element with length -1:

SEXPTYPE type = ANYSXP;
int size = 0;
for(size_t i = 0; i < length; i++) {
std::memcpy(&type, data, sizeof(int));
type &= 255;// this would also store the encoding...
assert(type == CHARSXP);
data += sizeof(int);
std::memcpy(&size, data, sizeof(int));
data += sizeof(int);
if(size == -1) {// this is NA_STRING
return true;
}
assert(size >= 0);
//else we jump to the next CHARSXP
data += size;
}
return false;

With that, the search of NA is $O(1)$ in memory. Note that I do not deal with non-vector types, such as environments (not stored in the database) or lists.

Testing C++ Code in R Packages

Tue, 21 Mar 2023 16:02:00 +0100

When you write a package in R, you probably write tests. A popular package for unit tests with R is testthat,¹ with the final invocation:

devtools::test()

If your package also includes native code, let’s say, C++, you can test it by testing the R API that exercises the native functions. But what if native functions do not map exactly to the R API, R functions use a combination of the native functions, or you want to check the results of native functions that do not map easily to R types or would require to write tedious converters?

In sxpdb, a database to efficiently store R values when instrumenting the R interpreter with R-dyntrace, I have a find_na function that tests for the presence of NA in a serialized R value in an efficient way. It does no try to deserialize the value, so does not allocate new memory, but traverses the serialized value in search of NA.

I suspected this function to be defective after problems in search indexes that use this function. It does not make sense to create a specific R function to call it as it only processes serialized R values that are not - and should not - be exposes to the R API. Thus I chose to test it directly on the C++ side. I could use another C++ testing library, such as GoogleTest but then I will have two separate test suites to run. How inconvenient, no more just running devtools::test()!

Fortunately, testthat can integrate with catch2, another popular C++ unit test library. Using catch2 with testthat is easy with use_catch, which sets up all the infrastructure. Let’s see how it looks like in practice with sxpdb.

catch2 within testthat

I used use_catch to build the scaffolding. For instance, it created a file tests/testthat/test-cpp.R for testthat to know about the C++ tests, and a file src/test-example.cpp where to write the actual C++ tests. I renamed it to tests.cpp.

I do not use dynamic registration in sxpdb for performance reason, and to hide the symbols I do not want to be part of the public API. The documentation of use_catch is less clear about what to do in that case. If you do nothing, the compilation will fail as the linker cannot find the entry point of the tests, function run_testthat_tests.

If you do not use dynamic symbol lookup in your package, in your init.c file, you have:

void R_init_sxpdb(DllInfo* dll) {
R_registerRoutines(dll, NULL, callMethods, NULL, NULL);
R_useDynamicSymbols(dll, FALSE);// FALSE here
}

Disabling dynamic registration hides symbols not explicitly registered in callMethods in init.c

More information in the official documentation

testthat expects to see symbol run_testthat_tests in your package. You have to add it to callMethods explicitly and make it visible in the init.c file:

extern SEXP run_testthat_tests(SEXP use_xml_sxp);
static const R_CallMethodDef callMethods[] = {
{"run_testthat_tests", (DL_FUNC) &run_testthat_tests, 1},
{NULL, NULL, 0} // Must have at the end
};

Writing your tests

Adding a test is as easy as creating a context and using the same-looking function as in testthat:

context("Index tests") {
test_that("find_na on sexp_view") {
Serializer ser(64);
// Scalar NA real
SEXP scalar_na = PROTECT(Rf_ScalarReal(NA_REAL));
sexp_view_t sexp_view = Serializer::unserialize_view(ser.serialize(scalar_na));
UNPROTECT(1);
expect_true(find_na(sexp_view));
...

The C++ tests now appear as any other contexts:

> devtools::test()
ℹ Loading sxpdb
ℹ Testing sxpdb
✔ | F W S OK | Context
✔ | 4 | Index tests
✔ | 25 | db [0.5s]
✔ | 7 | merge [0.2s]
✔ | 24 | query [0.6s]
══ Results ══════════════════════════════
Duration: 1.7 s
[ FAIL 0 | WARN 0 | SKIP 0 | PASS 60 ]
>

And actually, that find_na worked perfectly and the bug originated from elsewhere, but it was fun to play with catch2!

Other R unit testing packages are unitizeR, tinytest from the tinyverse, RUnit ↩︎

Eval in R

Mon, 30 Aug 2021 11:54:26 +0200

R has an omnipotent function, the eval function. In addition to evaluate any arbitrary R expression, it can also specify the environment in which the expression will be evaluated. The environment corresponds to the local scope, to a parent scope, of a caller function, or to a custom-built environment.

As eval unleashes its power, how do people use eval? Is it dangerous? Is it somehow analyzable? Can it be replaced automatically by more specialized functions?

Rhythm Quantization

Sun, 12 Apr 2020 17:08:30 +0200

We represent rhythms as trees. Rhythm trees can be changed into other rhythm trees using rewriting rules. It makes it possible to define an equivalence relation between rythms. Some of the rewriting rules simplify the rhythms and are used to quantify them.

Examples of rythms with slurs and dots and their tree representation.

Rewrite sequence starting from the tree (d) of previous figure.