search for: r_finite

...acomp failed for rbinom.c Following patch may solve this problem. *** R-2.0.1.orig/src/nmath/rbinom.c Mon Nov 15 21:33:01 2004 --- R-2.0.1/src/nmath/rbinom.c Sun Apr 3 00:19:52 2005 *************** *** 57,63 **** n = floor(nin + 0.5); if (n != nin) ML_ERR_return_NAN; ! if (!R_FINITE(n) || !R_FINITE(pp) || /* n=0, p=0, p=1 are not errors <TSL>*/ n < 0 || pp < 0. || pp > 1.) ML_ERR_return_NAN; --- 57,63 ---- n = floor(nin + 0.5); if (n != nin) ML_ERR_return_NAN; ! if (!R_FINITE((double)n) || !R_FINITE(pp) || /* n=0, p=0...

...ss 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 @@ } dd->gp.col = fg; GLine(REAL(at)[0], y, REAL(at)[n - 1], y, USER, dd); - if (R_FINITE(dd->gp.tck)) { + if (R_FINITE(dd->gp.tck) && !(ISNAN(dd->gp.tck))) { /* The S way of doing ticks */ double y0, y1; if (dd->gp.tck > 0.5) { @@ -922,7 +922,7 @@ } dd->gp.col = fg; GLine(x, REAL(at)[0], x, REAL...

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; if(!R_FINITE(...

...as a test of hessian[0][0] (not) being NaN. > > > > I'm using the .C interface for calling C code. > > > > Any thoughts on how to best handle the situation? Is this a bug in dpoco? Is there a simple way to test for any NaNs in a vector? > You should/could use macro R_FINITE to test each entry of the hessian. > In package nleqslv I test for a "correct" jacobian like this in file nleqslv.c in function fcnjac: > for (j = 0; j < *n; j++) > for (i = 0; i < *n; i++) { > if( !R_FINITE(REAL(sexp_fjac)[(*n)*j + i]) ) >...

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

...umber of >> columns used. If all pairs are excluded when calculating a >> particular distance, the value is `NA'. but the C code in ....../src/library/mva/src/distance.c, has, e.g. for the Euclidean distance : count= 0; dist = 0; for(j = 0 ; j < nc ; j++) { if(R_FINITE(x[i1]) && R_FINITE(x[i2])) { dev = (x[i1] - x[i2]); dist += dev * dev; count++; } i1 += nr; i2 += nr; } if(count == 0) return NA_REAL; if(count != nc) dist /= ((double)count/nc); return sqrt(dist); where it is clear that "R_FINITE(*)" should in p...

Full_Name: D Kreil Version: 2.1.1 OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license Submission from: (NULL) (62.178.15.60) During compiliation, I get: ld: Unsatisfied symbol "finite" in file colors.o Fix: replace "finite" with R_FINITE in colors.c line 269. I have, this time, searched through the R-admin.html, but not found a mention. This is all a bit hard for me as I'm installing R as non-admin on a bare-bones ia64 hpux system with no web browser, and a weird mix of libraries. Nevertheless, the above seems to me like an in...

...gt;>>> >>>> I'm using the .C interface for calling C code. >>>> >>>> Any thoughts on how to best handle the situation? Is this a bug in dpoco? Is there a simple way to test for any NaNs in a vector? >> >>> You should/could use macro R_FINITE to test each entry of the hessian. >>> In package nleqslv I test for a "correct" jacobian like this in file nleqslv.c in function fcnjac: >> >>> for (j = 0; j < *n; j++) >>> for (i = 0; i < *n; i++) { >>> if( !R_FINITE(...

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 *y, int taille) 2. { 3. double dev, dist; 4. int count, i; 5. 6. count= 0; 7. dist = 0; 8. for(i = 0 ; i < taille ; i++) { 9. if(both_non_NA(x[i...

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

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 because on MacOS X in /usr/include/architecture/ppc/math.h isnan() is itself a macro thus: #define isnan( x ) ( ( sizeof ( x ) == s...

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 because on MacOS X in /usr/include/architecture/ppc/math.h isnan() is itself a macro thus: #define isnan( x ) ( ( sizeof ( x ) == s...

>>>>> peter dalgaard >>>>> on Sun, 8 Dec 2019 12:11:50 +0100 writes: > Yes, that looks like a bug and an easily fixable one too. agreed. > 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_FI...

...ATCH IS A BUG TRACE, NOT A BUG FIX!!! --PATCH BEGINS -- 1518a1519 > fprintf(stderr,"test 1\n"); 1519a1521 > fprintf(stderr,"test 2\n"); 1520a1523 > fprintf(stderr,"test 3\n"); 1522,1524c1525,1542 < for (i = 1; i < nx; i++) < if (!R_FINITE(x[i]) || x[i] <= x[i - 1]) goto badxy; < for (j = 1; j < ny; j++) --- > fprintf(stderr,"test 4\n"); > for (i = 1; i < nx; i++) { > for (i = 1; i < nx; i++) { > fprintf(stderr,"test 4 - %d\n",i); > if (!R_FINITE(x[i]) ||...

...uot; > deparse(0 + 0i, control = "digits17") [1] "0 + 0i" As far as I can tell, the logic for this comes from this piece of /src/main/deparse.c: if (TYPEOF(vector) == CPLXSXP && (d->opts & DIGITS16)) { Rcomplex z = COMPLEX(vector)[i]; if (R_FINITE(z.r) && R_FINITE(z.i)) { snprintf(hex, 64, "%.17g + %17gi", z.r, z.i); strp = hex; } else strp = EncodeElement(vector, i, quote, '.'); } I think this is a small bug, and that "%17gi" in the snprintf call ought to be "%.17gi". Also...

...an[0][0] (not) being NaN. >>> >>> I'm using the .C interface for calling C code. >>> >>> Any thoughts on how to best handle the situation? Is this a bug in dpoco? Is there a simple way to test for any NaNs in a vector? > >> You should/could use macro R_FINITE to test each entry of the hessian. >> In package nleqslv I test for a "correct" jacobian like this in file nleqslv.c in function fcnjac: > >> for (j = 0; j < *n; j++) >> for (i = 0; i < *n; i++) { >> if( !R_FINITE(REAL(sexp_fjac)[(*...

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. Venables & Ripley S Programming p 137 indicates that "ISNA d...

.../appl/distance.c Sun Oct 15 18:13:25 2000 +++ R-work/src/appl/distance.c Mon Mar 5 10:16:53 2001 @@ -93,5 +93,5 @@ double R_canberra(double *x, int nr, int nc, int i1, int i2) { - double dist; + double dist, sum; int count, j; @@ -100,5 +100,7 @@ for(j=0 ; j<nc ; j++) { if(R_FINITE(x[i1]) && R_FINITE(x[i2])) { - dist += fabs(x[i1] - x[i2])/fabs(x[i1] + x[i2]); + sum = fabs(x[i1] + x[i2]); + if (sum > 0.0) + dist += fabs(x[i1] - x[i2])/sum; count++; } Best wishes, Jari Oksanen -- Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland P...

.../appl/distance.c Sun Oct 15 18:13:25 2000 +++ R-work/src/appl/distance.c Mon Mar 5 10:16:53 2001 @@ -93,5 +93,5 @@ double R_canberra(double *x, int nr, int nc, int i1, int i2) { - double dist; + double dist, sum; int count, j; @@ -100,5 +100,7 @@ for(j=0 ; j<nc ; j++) { if(R_FINITE(x[i1]) && R_FINITE(x[i2])) { - dist += fabs(x[i1] - x[i2])/fabs(x[i1] + x[i2]); + sum = fabs(x[i1] + x[i2]); + if (sum > 0.0) + dist += fabs(x[i1] - x[i2])/sum; count++; } Best wishes, Jari Oksanen -- Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland P...

...ingful 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 defined as R_finite, which is declared in Rmath.h and included in libRmath. ISNAN() however is broken. In R 1.9 it was defined as R_IsNaNorNA unless IEEE_754 was defined which was not done in the standalone libRmath/Rmath.h. R_IsNa...