similar to: Should 0L * NA_integer_ be 0L?

>>>>> Michael Chirico >>>>> on Sat, 23 May 2020 18:08:22 +0800 writes: > I don't see this specific case documented anywhere (I also tried to search > the r-devel archives, as well as I could); the only close reference > mentions NA & FALSE = FALSE, NA | TRUE = TRUE. And there's also this > snippet from R-lang: > In

Consider #as.numeric for emphasis sprintf('%d', as.numeric(1)) # [1] "1" vs. sprintf('%d', NA_real_) > Error in sprintf("%d", NA_real_) : invalid format '%d'; use format %f, %e, %g or %a for numeric object > I understand the error is correct, but if it works for other numeric input, why doesn't R just coerce NA_real_ to NA_integer_?

I am trying to set up a data set for a survival analysis with time-varying covariates. The data is already in a long format, but does not have a variable to signify the stopping point for the interval. The variable DaysEnrolled is the variable I would like to use to form this interval. This is what I have now: ID Age DaysEnrolled HAZ WAZ WHZ Food onARV

Hi all, Surprisingly (at least to me), `as.complex(NA_real_)` results in `complex(real = NA_real_, imaginary = 0)` rather than `NA_complex_`. It seems to me that this goes against the docs of `as.complex()`, which say this in the Details section: "Up to R versions 3.2.x, all forms of NA and NaN were coerced to a complex NA, i.e., the NA_complex_ constant, for which both the real and

So, to summarize, the open questions are: (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) instead of NA_complex_? (2) Should the first argument in c(NA, x) and c(NA_integer_, x), where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0) instead of NA_complex_? My opinions: (1) No. The imaginary part of the

>>>>> Mikael Jagan >>>>> on Wed, 8 Nov 2023 11:13:18 -0500 writes: > So, to summarize, the open questions are: > (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) > instead of NA_complex_? > (2) Should the first argument in c(NA, x) and c(NA_integer_, x), > where typeof(x) == "complex", be promoted

I initially thought this is "documented behaviour". ?sprintf says: Numeric variables with __exactly integer__ values will be coerced to integer. (emphasis mine). Turns out this only works when the first value is numeric and not NA, as shown by the following example: > sprintf("%d", as.numeric(c(NA,1))) Error in sprintf("%d", as.numeric(c(NA, 1))) : invalid

https://github.com/Rdatatable/data.table/issues/2171 The fix was easy, it's just surprising to see the behavior change almost on a whim. Just wanted to point it out in case this is unknown behavior, but Evan seems to have found this as well. On Tue, May 23, 2017 at 12:00 PM, Michael Chirico <michaelchirico4 at gmail.com > wrote: > Astute observation. And of course we should be

Thanks Martin. My hang-up was not on what the outcome of as.complex(NA) should be, but rather, how I should read code like c(x, y) generally. Till now, I have thought of it like 'c(x, y)' is c(as(x, typeof(y)), y)` when "type(y) > type(x)". Basically in my mind, "coercion" in R <-> as.<newtype>(.) (or coerceVector() in C). So I tracked down the source

>>>>> Michael Chirico >>>>> on Sun, 5 Nov 2023 09:41:42 -0800 writes: > This is another follow-up to the thread from September > "Recent changes to as.complex(NA_real_)". > A test in data.table was broken by the changes for NA > coercion to complex; the breakage essentially comes from > c(NA, 0+1i) > # vs

This is another follow-up to the thread from September "Recent changes to as.complex(NA_real_)". A test in data.table was broken by the changes for NA coercion to complex; the breakage essentially comes from c(NA, 0+1i) # vs c(as.complex(NA), 0+1i) The former is the output we tested against; the latter is essentially (via coerceVector() in C) what's generated by our

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

Identified as root cause of a bug in data.table: https://github.com/Rdatatable/data.table/issues/3267 On my machine, strtoi("", base = 2L) produces NA_integer_ (which seems consistent with ?strtoi: "Values which cannot be interpreted as integers or would overflow are returned as NA_integer_"). But on all the other machines I've seen, 0L is returned. This seems to be

>>>>> Martin Maechler >>>>> on Fri, 11 Jan 2019 09:44:14 +0100 writes: >>>>> Michael Chirico >>>>> on Fri, 11 Jan 2019 14:36:17 +0800 writes: >> Identified as root cause of a bug in data.table: >> https://github.com/Rdatatable/data.table/issues/3267 >> On my machine, strtoi("", base =

According to http://cran.r-project.org/doc/manuals/r-release/R-lang.html#Reserved-words if else repeat while function for in next break TRUE FALSE NULL Inf NaN NA NA_integer_ NA_real_ NA_complex_ NA_character_ ... ..1 ..2 etc. are all reserved keywords. However, in R 3.0.2 you can do things like: `if` <- function(cond, val1, val2) val2 after which if(TRUE) 1 else 2 returns 2.

On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in particular) with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when adding NA and NaN: > NA_real_ + NaN [1] NaN > NaN + NA_real_ [1] NA If I compile src/main/arithmetic.c without optimization (just -g) then both of those return NA. On Windows, using a precompiled R 2.8.1 from CRAN I get NA for

Hi, Tested with the latest r-devel snapshot build for Windows (2009-05-28 r48663): > png("test.png") Error in png("test.png") : invalid value of 'fillOddEven' The png() function is defined like this: > png function (filename = "Rplot%03d.png", width = 480, height = 480, units = "px", pointsize = 12, bg = "white", res = NA,

Dear R Team The following line returns 0 (zero) as answer: sum(c(NA_real_, NA_real_, NA_real_, NA_real_), na.rm = TRUE) One would, however, have expected it to return 'NaN', as is the case with function 'mean': > mean(c(NA_real_, NA_real_, NA_real_, NA_real_), na.rm = TRUE) [1] NaN The problem in other words: I have a vector filled with missing numbers. I run the

Hi, I have discovered that sample() fails with an uninformative error message when the x argument is a single NA of type double or integer. I can reproduce the problem with the following code: base::sample(NA) # NA is of logical type above base::sample(NA_character_) base::sample(NA_complex_) base::sample(NA_real_) base::sample(NA_integer_) The last two lines throw the following error: Error

Hello, Two lapply questions (system info and sample data below): 1) Why does the first form of command1 add the name of y _after_ the str() output rather than before as does the second (preferred) form? # command1 version1 invisible(lapply(ls(pattern='bn'), function(y) cat(y, "\n", str(get(y)), "\n") )) # command1 version2 (preferred output)