similar to: grep() and factors

Hello, I think I've found a bug in the C function do_grep located in src/main/grep.c. It seems to affect both the latest revisions of R-2-13-branch and trunk when compiling R without optimizations and with it's own version of pcre located in src/extra, at least on ubuntu 10.04. According to the pcre_exec API (I presume the later versions), the ovecsize argument must be a multiple of 3 ,

The old factor() wars...... {{maybe don't just report that factor()s are broken by design..}} If ff is a factor, e.g., ff <- as.factor(rep(1:2,3)) f2 <- ff; levels(f2) <- c("Lo","Hi") 1) we don't allow {in R as in S-plus 3.x} arithmetic on factors, i.e. 1 + ff gives an error, and I think most of us believe this is as desired. {{if one

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

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

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

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

[Forwarding to r-devel.] Dear People, Here is something I do not understand. Consider ************************************************* foo.cc ************************************************* #include <iostream> #include <R.h> #include <Rinternals.h> using std::cout; using std::endl; extern "C" { SEXP printlst(SEXP lst); } SEXP printlst(SEXP lst) { for(int

Hi all, Came across an error in ?strsplit in the details section: Details: Arguments 'x' and 'split' will be coerced to character, so you will see uses with 'split = NULL' to mean 'split = character(0)', including in the examples below. I caught myself trying to use strsplit() on a factor and the coercion on 'x' is not done. According

Hello folks, I found a strangeness while experimenting with POSIXct vectors and lists. It seems that coerced NA's aren't "real" NAs, at least as considered by is.na()? > date_vec = c(as.POSIXct(now()), as.POSIXct(now()+1),NA,"b") > date_vec [1] "2012-08-22 15:00:46 COT" "2012-08-22 15:00:47 COT" NA [4] NA Warning message: In

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

Hal Finkel <hfinkel at anl.gov> wrote on 16.03.2015 17:56:20: > If you want to do it at a clang level, the right thing to do is to > fixup the ABI lowerings for pointers to keep them pointers in this case. > So this is an artifact of the way that we pass structures, and > constructing a general solution at the ABI level might be tricky. > I've cc'd Uli, who did most

>>>>> Tomas Kalibera >>>>> on Tue, 25 Aug 2020 09:29:05 +0200 writes: > On 8/23/20 5:02 PM, Rory Winston wrote: >> Hi >> >> I noticed a small inconsistency when using sum() vs cumsum() >> >> I have a char-based series >> >> > tryjpy$long >> >> [1]

Hi I noticed a small inconsistency when using sum() vs cumsum() I have a char-based series > tryjpy$long [1] "0.0022" "-0.0002" "-0.0149" "-0.0023" "-0.0342" "-0.0245" "-0.0022" [8] "0.0003" "-0.0001" "-0.0004" "-0.0036" "-0.001" "-0.0011"

Dear R list people I loaded a file of numbers into R and got a dataframe of factors. So I tried to convert it to numeric as per the FAQ using as.numeric(). But I'm getting errors (please see example), so what am I getting wrong? Thanks for your time. John Example... #my data object > f GSM187153 GSM187154 GSM187155 GSM187156 GSM187157 GSM187158 GSM187159 13 7.199346 7.394519

Hi, In R 3.4.0, the "Pattern Matching and Replacement" documentation that describes regexec(), gregexpr(), etc. states that the "text" argument to regexec is a character vector, "or an object which can be coerced by as.character to a character vector": regexec(pattern, text, ignore.case = FALSE, perl = FALSE, fixed = FALSE, useBytes = FALSE)

Hello, I am trying to make a correlation matrix in R using cor() and also to get the p-value for each correlation using cor.test(). I can't get these commands to work. I'm getting errors like the following: cor(Pollution, Wet.days) Error in inherits(x, "data.frame") : Object "Wet.days" not found cor("Pollution", "Wet.days") Error in

I understand that the two following loops should produce the exact same output. However, they do not. It appears that looping directly through the sequence of Date objects somehow makes them be coerced to numeric: > date1 = "20130301" > date2 = "20130302" > > d1 = as.Date(date1, format="%Y%m%d", tz="GMT") > d2 = as.Date(date2,

I just meant that the minimal contract for as.list() appears to be that it returns a VECSXP. To the user, we might say that is.list() will always return TRUE. I'm not sure we can expect consistency across methods beyond that, nor is it feasible at this point to match the semantics of the methods package. It deals in "class space" while as.list() deals in "typeof() space".

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