similar to: a strange logical bug (PR#162)

R-2.9.0/include/R_ext/Arith.h has: int R_IsNA(double); /* True for R's NA only */ int R_IsNaN(double); /* True for special NaN, *not* for NA */ int R_finite(double); /* True if none of NA, NaN, +/-Inf */ #define ISNA(x) R_IsNA(x) /* True for *both* NA and NaN. The first and last lines are contradictory - if R_IsNA is true only for NA, not NaN, then ISNA should be the same.

Hi the list, I need to write some efficient distances function, so I read the code for the Euclidean distance. I do not understand the purpose of the line 11 : if x[i] and y[i] are not NA (line 9), can dev be NA ? Christophe #define both_FINITE(a,b) (R_FINITE(a) && R_FINITE(b)) #define both_non_NA(a,b) (!ISNAN(a) && !ISNAN(b)) 1. static double R_euclidean2(double *x, double

Hello R-devel, Best wishes in the new year. I am writing to kindly request new R function so NA_real_ can be more easily detected. Currently if one wants to test for NA_real_ (but not NaN) then extra work has to be done: `is.na(x) & !is.nan(x)` Required functionality is already at C level so to address my request there is not that much to do. Kevin Ushey made a nice summary of current R C api

I've noticed that the max.col function with the default "random" option often gives unexpected results. For instance, in this test, it seems clear what the answer should be: > # second col should always be max > x1 = cbind(1:10, 2:11, -Inf) > > # this works fine > max.col(x1, "first") [1] 2 2 2 2 2 2 2 2 2 2 > > # this gives random answers >

Hi! I noticed that cumsum behaves different than the other cumulative functions wrt. NaN values: > values <- c(1,2,NaN,1) > for ( f in c(cumsum, cumprod, cummin, cummax)) print(f(values)) [1] 1 3 NA NA [1] 1 2 NaN NaN [1] 1 1 NaN NaN [1] 1 2 NaN NaN The reason is that cumsum (in cum.c:33) contains an explicit check for ISNAN. Is that intentional? IMHO, ISNA would be better

"nana" is meant to express "NA, really NA". Your suggestion sounds good. On Thu 2 Jan, 2020, 3:38 AM Pages, Herve, <hpages at fredhutch.org> wrote: > Happy New Year everybody! > > The name (is.nana) doesn't make much sense to me. Can you explain it? > > One alternative would be to add an extra argument (e.g. 'strict') to > is.na(). FALSE by

I wish to pass a vector ``y'', some of whose entries are NAs to a fortran subroutine which I am dynamically loading and calling by means of .Fortran(). The subroutine runs through the vector entry by entry; obviously I want to have it do one thing if y[i] is present and a different thing if it is missing. The way I am thinking of proceeding is along the xlines of: ymiss <- is.na(y)

In the hope of some meaningful response and ignoring the risk of further abuse, let me try to clarify the issue here. I have re-read the 'Writing R Extensions' manual. It seems to me that it clearly says R API functions can be called from from C++ programs, and the API includes the special values ISNAN() and R_FINITE() and the missing test ISNA(). R_FINITE is no problem. It is

Hi, If I do the following I can have a NULL in a list > x <- list( 1, list(3,NULL,4), 5 ) > x [[1]] [1] 1 [[2]] [[2]][[1]] [1] 3 [[2]][[2]] NULL [[2]][[3]] [1] 4 [[3]] [1] 5 This is a good thing for me as it can be passed through into C++ where I can know the value is missing. (Can't seem to detect a NA from C++ for some reason. There is RF_isNull in the API but no RF_isNA

Hi. I am currently converting a lot of R code to C in order to make it more efficient. A lot of the data involves NAs. As the data is mainly integers > 0, I am just setting all NAs to 0 then sending it to the C code then resetting them to NAs again after the C program is done, to be compatible with the rest of the R code. Is there a more efficient way to deal with NAs in C? I have used

Can anybody of the architects of R enlighten me about the reasoning behind the selection of the IEEE 754 mode for the building of R, please? Special points of interest are: 1. The selection seems to be based on the availability of isnan() and finite(). Is this a common way to test for IEEE 754? 2. The C9x draft introduces isfinite() instead of finite() (and as I see, some systems, e.g. the

Full_Name: Albrecht Gebhardt Version: 0.65.0 OS: Digital Unix 4.0E Submission from: (NULL) (212.17.104.62) Plottimg on the Alpha stopped working with 0.65.0. The tickmarks have a length of -Inf and go across the whole plot. A first solution is the following patch: --- src/main/plot.c.alpha-patch Mon Sep 13 01:37:11 1999 +++ src/main/plot.c Mon Sep 13 01:58:16 1999 @@ -832,7 +832,7 @@

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

Yes, that looks like a bug and an easily fixable one too. However, I spy another issue: Why do we check the !R_FINITE(x) && mu == x before checking for sd < 0 ? The difference is whether we return ML_NAN; or ML_ERR_return_NAN; but surely negative sd should always be an error? I'd be inclined to do if (sigma < 0) ML_ERR_return_NAN; if(!R_FINITE(sigma)) return R_D__0;

Hi, Apropos of a recent Inf question, I've previously wondered if dnorm "does the right thing" with dnorm(0, 0, -Inf) which gives zero. Should that be zero or NaN (or NA)? The help says "'sd < 0' is an error and returns 'NaN'" and since -Inf < 0 is TRUE, then... is this a bug? Thank you, Stephen Rochester, MN USA

On 21 May 2015, at 12:49 , Martin Maechler <maechler at lynne.stat.math.ethz.ch> wrote: >>>>>> peter dalgaard <pdalgd at gmail.com> >>>>>> on Thu, 21 May 2015 11:03:05 +0200 writes: > >> On 21 May 2015, at 10:35 , Martin Maechler <maechler at lynne.stat.math.ethz.ch> wrote: > >>>> >>>> I noticed that

Dear Sir, In the functions orderVector1, orderVector1l (R-3.5.2/src/main/sort.c) there are two loops concerning nalast (lines 1096, 1105). I am not sure about the possibility of redefining them, so this function should be a little faster. The first one (line 1096) can be included in the previous 'switch' block (line 1079) (see below). And if you rewrite/duplicate this 'switch'

I have been receiving complaints that my libraries no longer give reasonable graphics with R0.90. I have been replying that I have not changed anything. Among my travels (presently in Umea), I have finally had a chance to take a look. The best way to describe the current default graphics is HORRIBLY UGLY. The R core member who made those changes should buy glasses to see the screen better instead

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or