[Rcpp-devel] Rcpp::traits::is_inifinite - PosInf vs. NegInf

[Kevin Ushey]

FWIW, the implementation of of is_finite lives here:

https://github.com/RcppCore/Rcpp/blob/b1254701a899cb187f9a6917cb8d18c7f93290c7/inst/include/Rcpp/traits/is_infinite.h#L34-L37

I would recommend checking equality directly against the R constants
`R_PosInf` and `R_NegInf`.

As for whether this would be useful to have directly in Rcpp, it wouldn't
hurt, but I also don't see a great need since the existing R API suffices
here (IMO).

Best,
Kevin

On Sun, May 24, 2020 at 1:26 PM Avraham Adler <avraham.adler at gmail.com>
wrote:

> As I was updating one of my packages (lamW), CRAN's reverse dependency
> tests caught an error of my own making. For consistency, I was trying
> to remove calls to std::numeric_limits and replace them with R magic
> words (like R_NaN instead of
> std::numeric_limits<double>::quiet_NaN()).
>
> One of the changes I made was in a test for PosInf FROM:
>
> if (x == std::numeric_limits<double>::infinity()) {
>   result = std::numeric_limits<double>::infinity();
> }
>
> TO
>
> if (Rcpp::traits::is_infinite<REALSXP>(x)) {
>  result = R_PosInf;
> }
>
> The error, of course, is that NegInf is infinite too. My most
> immediate question is which is preferable (speed, efficiency,
> consistency, etc.). To revert back to checking equality using
> std::numeric_limits or to use a compound if
> (Rcpp::traits::is_infinite<REALSXP>(x) && x > 0.0)?
>
> More generally, would it be of values to have sugar functions for
> checking for PosInf vs. NegInf, or would that end up being a call to
> std::numeric_limits anyway?
>
> As always, thanks to Dirk, Romain, JJ, Kevin, and everyone!
>
> Thank you,
>
> Avi
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20200525/770e13b9/attachment.html>