search for: na_real

...switch (type) { case REALSXP: rx = REAL(x) + n*j; #ifdef IEEE_754 if (keepNA) ! for (sum = 0., i = 0; i < n; i++) sum += *rx++; else { ! for (cnt = 0, sum = 0., i = 0; i < n; i++, rx++) ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} else if (keepNA) {sum = NA_REAL; break;} } #else ! for (cnt = 0, sum = 0., i = 0; i < n; i++, rx++) ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} else if (keepNA) {sum = NA_REAL; break;} #endif break; --- 1046,1082 ---- switch (type) { case REALSXP: rx = REAL(x) + n*j; + sum = 0.; #i...

Full_Name: David Larsen Version: 1.5.1 OS: Redhat 7.2, w98, w2000 Submission from: (NULL) (128.206.66.65) I have c code that produces vector sequences for plotting. I use NA_REAL to create an NA that will pass back to R to break the line. This code worked fine upto R-1.5.0 It continues to work on Redhat7.2 Linux but on both windows98 and windows2000 the NA_REAL returns -6.623485e-229 on both windows systems. I use cygwin and gcc to compile the code which I updated in July...

In the maps library, NA's are inserted between polygons so lines() can be used to draw all polygons at once. The code to do it is like this: *x++ = NA_REAL; *y++ = NA_REAL; where x and y are declared as double *x, *y, *range; and are the arguments passed in through a .C call. However, the values show up in R as -6.62314033633867e-229 instead of NA, so the drawing gets messed up. Any suggestions as to what might be going wrong? This...

...& ii < nx && ii != NA_INTEGER) - INTEGER(result)[i] = INTEGER(x)[ii]; - else - INTEGER(result)[i] = NA_INTEGER; - break; - case REALSXP: - if (0 <= ii && ii < nx && ii != NA_INTEGER) - REAL(result)[i] = REAL(x)[ii]; - else - REAL(result)[i] = NA_REAL; - break; - case CPLXSXP: - if (0 <= ii && ii < nx && ii != NA_INTEGER) { - COMPLEX(result)[i] = COMPLEX(x)[ii]; - } - else { - COMPLEX(result)[i].r = NA_REAL; - COMPLEX(result)[i].i = NA_REAL; - } - break; - case STRSXP: - if (0 <= ii &&a...

...to 1954; if they are, x is NA, if they're not, x is NaN (as defined for R_IsNaN). My question is -- I can see a substantial increase in speed (on my computer, in certain cases) if I replace this check with int R_IsNA(double x) { return memcmp( (char*)(&x), (char*)(&NA_REAL), sizeof(double) ) == 0; } IIUC, there is only one bit pattern used to encode R NA values, so this should be safe. But I would like to be sure: Is there any guarantee that the different functions in R would return NA as identical to the bit pattern defined for NA_REAL, for a given arc...

I am trying to parallelize part of a C function that is called from R (via .C) using OpenMP's "parallel for" pragma. I get mixed results: some runs finish with no problem, but some lead to R crashing after issuing a long error message involving memory violations. I found this post, which describes how a .Call() function can be made to avoid crashing R by raising the stack limit:

...int count, i; 5. 6. count= 0; 7. dist = 0; 8. for(i = 0 ; i < taille ; i++) { 9. if(both_non_NA(x[i], y[i])) { 10. dev = (x[i] - y[i]); 11. if(!ISNAN(dev)) { 12. dist += dev * dev; 13. count++; 14. } 15. } 16. } 17. if(count == 0)return NA_REAL; 18. if(count != taille) dist /= ((double)count/taille); 19. return sqrt(dist); 20.}

...far as I can see, the code that is causing this is do_asPOSIXct in datetime.c: 695 if(!R_FINITE(secs) || tm.tm_min == NA_INTEGER || 696 tm.tm_hour == NA_INTEGER || tm.tm_mday == NA_INTEGER || 697 tm.tm_mon == NA_INTEGER || tm.tm_year == NA_INTEGER) 698 REAL(ans)[i] = NA_REAL; 699 else { 700 errno = 0; 701 tmp = mktime0(&tm, 1 - isgmt); 702 #ifdef MKTIME_SETS_ERRNO 703 REAL(ans)[i] = errno ? NA_REAL : tmp + (secs - fsecs); 704 #else 705 REAL(ans)[i] = (tmp == (double)(-1)) ? 706 NA_REAL : tmp + (secs - fsecs); 707...

...rtod (const char* str, char ** end) >> >> Implementations of the C99/POSIX functions atof and strtod which >> guarantee platform-dependent behaviour, including always using the >> period as the decimal point aka ?radix character? and converting >> "NA" to R?s NA_REAL_ . Besides the easily fixable return type (void -> double), shouldn't the documentation mention the fact that, unlike the standard C library functions, R's parser returns NA_REAL instead of 0 when no conversion is performed (including for the "NA" string, *end == str)? Index...

...do_systime(SEXP call, SEXP op, SEXP args, SEXP env) { time_t res = time(NULL); + SEXP ans = allocVector(REALSXP, 1); #ifdef USING_LEAPSECONDS res -= 22; #endif - SEXP ans = allocVector(REALSXP, 1); if(res != (time_t)(-1)) REAL(ans)[0] = (double) res; else REAL(ans)[0] = NA_REAL; return ans; -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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-...

Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a ?crit : > On 12/7/19 10:32 PM, Laurent Gautier wrote: > > Thanks for the quick response Tomas. > > The same error is indeed happening when trying to have a zero-length > variable name in an environment. The surprising bit is then "why is this > happening during parsing" (that is why

...j[i] = cj[v[i]-1]; Missing separate debuginfos, ................. (gdb) list 247 for (int j = 0; j < ncc; j++) { 248 xj = &x[j * (R_xlen_t)nrx]; 249 cj = &c[j * (R_xlen_t)nrc]; 250 for (int i = 0; i < nrx; i++) 251 if(v[i] == NA_INTEGER) xj[i] = NA_REAL; 252 else xj[i] = cj[v[i]-1]; 253 } 254 } 255 and indeed in the debugger, i=7 and v[i] is "outside", v[] being of length 7, hence indexed 0:6. > Jan > On 06-10-17 12:08, Jan van der Laan wrote: >> >> The following code...

...ary/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 principle be replaced by "!ISNAN(*)". Note however that "Inf - Inf -> NaN" and e.g the canberra metric has more ways to get "NaN". Th...

What do you mean by "should not"? NULL means "missing object" in R. The result of the sum function is always expected to be numeric... so NA_real or NA_integer could make sense as possible return values. But you cannot compute on NULL so no, that doesn't work. See the note under the "Value" section of ?sum as to why zero is returned when all inputs are removed. -- Sent from my phone. Please excuse my brevity. On March 21, 2...

Hmm, it is not actually at odds with help(c), it is just that the autocoercion works different that it used to, so that as.complex(NA) == as.complex(NA_real) == NA_real_+0i) which now differs from NA_complex although both print as NA. I haven't been quite alert when this change was discussed, but it does look a bit unfortunate that usage patterns like c(NA, 0+1i) does not give complex NA for the 1st component, effectively changing the interpre...

Hi everyone, Has anyone written a parser in Java for either the ASCII or binary format produced by save()? I need to parse a single large 2D array that is structured like this: list( "32609_1" = c(-9549.39231289146, -9574.07159324482, ... ), "32610_2" = c(-6369.12526971635, -6403.99620977124, ... ), "32618_2" = c(-2138.29095689061, -2057.9229403233, ... ),

...> >> On Mar 21, 2018, at 12:58 PM, Jeff Newmiller <jdnewmil at dcn.davis.ca.us> wrote: >> >> What do you mean by "should not"? >> >> NULL means "missing object" in R. The result of the sum function is always expected to be numeric... so NA_real or NA_integer could make sense as possible return values. But you cannot compute on NULL so no, that doesn't work. >> >> See the note under the "Value" section of ?sum as to why zero is returned when all inputs are removed. >> -- >> Sent from my phone. Pleas...

..., no? Cheers, Boris > On Mar 21, 2018, at 12:58 PM, Jeff Newmiller <jdnewmil at dcn.davis.ca.us> wrote: > > What do you mean by "should not"? > > NULL means "missing object" in R. The result of the sum function is always expected to be numeric... so NA_real or NA_integer could make sense as possible return values. But you cannot compute on NULL so no, that doesn't work. > > See the note under the "Value" section of ?sum as to why zero is returned when all inputs are removed. > -- > Sent from my phone. Please excuse my brev...

....2.0, on Windows (using the official CRAN builds), on Linux (local built), and on OS X (official AT&T builds), I get: > x <- rep(0, 1e8) > stopifnot(typeof(x) == "double") > system.time(sum(x, na.rm=FALSE)) user system elapsed 0.19 0.01 0.20 > y <- rep(NA_real_, 1e8) > stopifnot(typeof(y) == "double") > system.time(sum(y, na.rm=FALSE)) user system elapsed 9.54 0.00 9.55 > z <- x; z[length(z)/2] <- NA_real_ > stopifnot(typeof(z) == "double") > system.time(sum(z, na.rm=FALSE)) user system elapsed...

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