Switch DOUBLE_EPS to DBL_EPSILON to support STRICT_R_HEADERS

[eddelbuettel]

Hi Ben,

The Rcpp team is trying to move towards defining STRICT_R_HEADERS by default. Please the issue ticket at RcppCore/Rcpp#1158 for motivation and history.

Your package uses (in one file, once) DOUBLE_EPS but when STRICT_R_HEADERS is in use the equivalent DBL_EPSILON is preferred. You can set STRICT_R_HEADERS as a #define in a header or source file, via -DSTRICT_R_HEADERS as a compiler flag, or as a #define in the Rcpp sources as we currently do. We plan to enable STRICT_R_HEADERS by the Jan 2022 release of Rcpp, and will likely offer you a define to suppress it. So if you really do not want the change you can prevent it -- see these lines in Rcpp for details:
https://github.com/RcppCore/Rcpp/blob/e79c70e76bc2a776d2d57287f7192dbdbcb292aa/inst/include/Rcpp/r/headers.h#L28-L38

Of course, you can probably also switch to std::numeric_limits<double>::epsilon()) as you already do.

This very simple PR changes one DOUBLE_EPS to DBL_EPSILON. Your code will then work with and without STRICT_R_HEADERS as we now include cfloat. To be really safe against older Rcpp release you may want to include it to (or the equivalent float.h). In your case, might be easiest in one common header that defines the tolerance constant.

As discussed in RcppCore/Rcpp#1158, this is not urgent, but we of course welcome relatively prompt resolution at CRAN so when we continue to test for this (at a likely montly pace) so we do not get false positives as we will continue to use the CRAN set of packages (as opposed to hand-curated set of upstream dev versions).

Many thanks for your help, and I hope you continue to find Rcpp helpful. Please don't hesitate to ask if you have any questions.

[boennecd]

I switched to std::numeric_limits<double>::epsilon()). The packages just needs to be checked now and submitted to CRAN.

I am sorry that I have not solved this before! Thank you for the work you are doing.

[eddelbuettel]

Nice. I like std::numeric_limits<double>::epsilon()) better too. I'll keep an eye on when your package hits CRAN and mark it as solved then.

[boennecd]

Thanks, it is on CRAN now.