similar to: Putting a NULL in a list (as cannot pass NA to C++)

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.

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 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

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)

Vince Carey found this (thank you!). Since the fix to the problem is not entirely obvious, I post this to R-devel as RFC: help(dist) says: >> Missing values are allowed, and are excluded from all computations >> involving the rows within which they occur. If some columns are >> excluded in calculating a Euclidean, Manhattan or Canberra >> distance, the sum is

Hi the list, I am writing a R function that call a C function. The C function needs integers but I do not manage to give a NA integer as argument : --- C code --- void essai(int *t){ Rprintf("\nT0=%i T1=%i T2=%i T3=%i",t[0],t[1],t[2],t[3]); } --- R --- boub <- c(1,2,3,4) .C("pour",as.integer(boub),NAOK=TRUE) # T0=1 T1=2 T2=3 T3=4[[1]] # [1] 1 2 3 4 boub <-

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

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 know that there must be a cool way of doing this, but I can't think of it. Let's say I have an dataframe with NA's. > x <- data.frame(a = c(0,1,2,NA), b = c(0,NA,1,2), c = c(NA, 0, 1, 2)) > x a b c 1 0 0 NA 2 1 NA 0 3 2 1 1 4 NA 2 2 > I know it is easy to replace all the NA's with zeroes. > x[is.na(x)] <- 0 > x a b c 1 0 0 0 2 1 0 0 3 2 1

Full_Name: Teru KAMOGASHRIA Version: 2.0.1 OS: SunOS sun 5.10 Generic i86pc i386 i86pc Submission from: (NULL) (219.5.176.24) rbinom.c cannot be compiled because of the casting problem. /opt/SUNWspro/bin/cc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -g -c rbinom.c -o rbinom.o "rbinom.c", line 60: operand must have real

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 @@

In my package 'glmmML' I'm using old C code and linpack in the optimizing procedure. Specifically, one part of the code looks like this: F77_CALL(dpoco)(*hessian, &bdim, &bdim, &rcond, work, info); if (*info == 0){ F77_CALL(dpodi)(*hessian, &bdim, &bdim, det, &job); ........ This usually works OK, but with an ill-conditioned data

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;

"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

> > On 9 Feb 2017, at 16:00, G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > > > In my package 'glmmML' I'm using old C code and linpack in the optimizing procedure. Specifically, one part of the code looks like this: > > > > F77_CALL(dpoco)(*hessian, &bdim, &bdim, &rcond, work, info); > > if (*info == 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

In R0.64.0, try as.numeric(is.na(c(NA,NA,1))) as.numeric(c(T,T,F)) Jim -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch

On Fri, Mar 31, 2017 at 10:14 PM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote: > From ?NA > > Numerical computations using ?NA? will normally result in ?NA?: a > possible exception is where ?NaN? is also involved, in which case > either might result. > > and ?NaN > > Computations involving ?NaN? will return ?NaN? or perhaps ?NA?: >

> On 10 Feb 2017, at 14:53, G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > Thanks to all who answered my third question. I learned something, but: > > On 2017-02-09 17:44, Martin Maechler wrote: >> >>>> On 9 Feb 2017, at 16:00, G?ran Brostr?m <goran.brostrom at umu.se> wrote: >>>> >>>> In my package 'glmmML'

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