In a recent post we introduced CRAN checks of packages, and the efforts we make to ensure all CRAN check flavours have a R-hub equivalent platform for you to reproduce errors on and for you to ensure you have fixed the problems. In this post, we’ll explain the context behind CRAN’s “noLD”, “no long doubles” setting of the “x86_64 Linux with R-devel” flavor; present the R-hub noLD platform; and mention possible fixes for noLD errors.

Why noLD?

In “Writing R extensions” – the official CRAN bible, at the very end of the Writing portable packages section, after discussion of compilers etc., it states “Only test the accuracy of results if you have done a formal error analysis. Things such as checking that probabilities numerically sum to one are silly: numerical tests should always have a tolerance. That the tests on your platform achieve a particular tolerance says little about other platforms. R is configured by default to make use of long doubles where available, but they may not be available or be too slow for routine use. (…)". To ensure package developers follow this recommendation, CRAN maintainers make extra checks with long doubles disabled, on the “x86_64 Linux with R-devel” check flavor, so related issues might be detected. 🕵️‍♂️ If your package was found guilty, what can you do? Note that getting a noLD error does not mean you are silly.

noLD platform for the R-hub package builder

We were reminded of the noLD setting of by two emails to R-package-devel: a first one and then another one with a similar question: “I am getting an “noLD” error - so there is some issue with a long double. I am a at a bit of a loss on how to go about fixing this (would rounding help), but more importantly, how can I check this to make sure I have fixed it - since I do not get an error on my local system (and it passes all other checks.)" Good question! As explained in “Writing R extensions”, one could “configure and build R with --disable-long-double” but there’s now a handier solution: a new platform of R-hub package builder! You can have a look at the corresponding Dockerfile, in particular the line disabling long doubles.

As all R-hub’s Linux platforms it’s available on Docker hub but more importantly accessible via R.

You can use its online version,

rhub::check(<pkg-path>, platform = "debian-gcc-devel-nold") 

Or run a local check if your OS is not Windows,

rhub::local_check_linux(<pkg-path>, image = "rhub/debian-gcc-devel-nold")

Read more about rhub, R client for R-hub package builder.

How to fix a noLD error?

So now that you know why CRAN has a noLD ingredient in one of its check flavor, and how to reproduce its errors… how do you fix them? Let’s find inspiration in existing packages. The summary is, do not rely on a given tolerance being valid on all machines. Here are two workarounds.

• The HACSim package that was mentioned in one of the R-package-devel thread has been updated on CRAN. Thanks to R-hub’s CRAN source code mirror we can assess what was changed. The error fix seems to be the change from

if (sum(probs) != 1) {

to

if (!isTRUE(all.equal(1, sum(probs), tolerance = .Machine$double.eps^0.25))) {

in the package code.

• The recipes package also includes a fix for a noLD error that was detected last year. Of particular interest in the related commit are these lines in the testthat-powered tests,

eps <- if (capabilities("long.double"))
  sqrt(.Machine$double.eps) else
  0.1

followed by

expect_equal(

    as.data.frame(tidy_exp_tr),
    as.data.frame(tidy(trained, number = 1)),
    tolerance = eps
  )

later, since testthat::expect_equal() has a tolerance argument.

If you find other fixes interesting, please share them via Twitter or gitter!

Conclusion

In this post we presented the rationale between the noLD setting of CRAN’s “x86_64 Linux with R-devel” check flavor, explained how to reproduce noLD errors with R-hub package builder, and gave some examples of fixes. Now go forth and get rid of your noLD errors, good luck!