similar to: Possible page inefficiency in do_matrix in array.c

On 08/05/2018 2:58 PM, Duncan Murdoch wrote: > On 08/05/2018 1:48 PM, Steven Nydick wrote: >> Reproducible example: >> >> x <- list(list(list(), list())) >> unlist(x) >> >> *> Error in as.character.factor(x) : malformed factor* > > The error comes from the line > > structure(res, levels = lv, names = nm, class = "factor") >

On Thu, 30 Jan 2025 13:07:31 -0800 Michael Chirico <michaelchirico4 at gmail.com> wrote: > There are at least dozens of other cases on CRAN [2],[3]. Some of these involve casting an int to Rboolean. Best case, the int is compared against NA_LOGICAL beforehand, avoiding any mistake (there's at least one like that). Worst case, NA_LOGICAL is not considered before the cast, so NA will

On 08/05/2018 4:50 PM, Steven Nydick wrote: > It also does the same thing if the factor is not on the first level of > the list, which seems to be due to the fact that the islistfactor is > recursive, but if a list is a list-factor, the first level lists are > coerced into character strings. > > > x <- list(list(factor(LETTERS[1]))) > > unlist(x) > Error in

Chain?of?calls?of?C?functions?in?coerce.c?for?as.character(<logical>)?in?R: do_asatomic ascommon coerceVector coerceToString StringFromLogical?(for?each?element) The?definition?of?'StringFromLogical'?in?coerce.c?: attribute_hidden?SEXP?StringFromLogical(int?x,?int?*warn) { ????int?w; ????formatLogical(&x,?1,?&w); ????if?(x?==?NA_LOGICAL)?return?NA_STRING;

Reproducible example: x <- list(list(list(), list())) unlist(x) *> Error in as.character.factor(x) : malformed factor* What should happen: unlist(x) > NULL R.version platform x86_64-apple-darwin15.6.0 arch x86_64 os darwin15.6.0 system x86_64, darwin15.6.0 status major 3 minor 5.0 year 2018 month 04 day

A colleague sent me the following: If you specify probabilities in the 'sample' function and forget to type 'prob=...', then you get nonsense. E.g. sample(1:10,1,c(0,0,0,0,1,0,0,0,0,0)) does not filter '5', while sample(1:10,1,prob=c(0,0,0,0,1,0,0,0,0,0)) does it correctly. I wish this would return an error because the

R community, As you may know, R's iconv doesn't work well converting to and from encodings that allow embedded nulls. For example > iconv("foo", to="UTF-16") Error in iconv("foo", to = "UTF-16") : embedded nul in string: '\xff\xfef\0o\0o\0' However, I don't believe embedded nulls are at issue here, but rather that R's iconv

I'd like to propose that the whenever the length of condition passed to an if or a while statement differs from one, an error is produced rather than just a warning as today: > x <- 1:2 > if (x == 1) message("x == 1") x == 1 Warning message: In if (x == 1) message("x == 1") : the condition has length > 1 and only the first element will be used There are

Full_Name: Paul Louisell Version: 1.6.2 OS: Windows NT Submission from: (NULL) (192.249.47.9) There is a slight bug in the function 'any'. Given a logical vector (possibly including values of 'NA'), the default action of any should be as follows: (i) at least one value = T should return T (ii) NO values = T (a) at least one value = 'NA' should return 'NA'

Tomas, I am thinking of writing something for R-devel, and hope to have your input first. I get moderated on R-devel as I am now subscribed as brian.ripley at R-project.org which of course I cannot send from. So I am even more discouraged from posting there. (R-core is bad enough with Luke discouraging all innovation except by him and Simon completely misunderstanding the C23 status.)

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

It also does the same thing if the factor is not on the first level of the list, which seems to be due to the fact that the islistfactor is recursive, but if a list is a list-factor, the first level lists are coerced into character strings. > x <- list(list(factor(LETTERS[1]))) > unlist(x) Error in as.character.factor(x) : malformed factor However, if one of the factors is at the top

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

I do not have access to the bug reporting system. If somebody can get me access, I can create a formal bug report. The latter issues seem like duplicates of: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=12572 (with slightly different output), but as that bug was reported nearly 10 years ago, it might be worth creating an update under R version 3. I could not find the first issue when

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

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

Hi, I know the topic of drop=TRUE/FALSE has been discussed quite a bit, but I was wondering whether it might be possible to set "drop=FALSE" as a global setting (e.g. as an option in options()) so that one does not have to remember to write it every time you do an operation which might return a 1 column or 1 row matrix. I searched in R-help and did not see any previous proposals along

Hi, I know the topic of drop=TRUE/FALSE has been discussed quite a bit, but I was wondering whether it might be possible to set "drop=FALSE" as a global setting (e.g. as an option in options()) so that one does not have to remember to write it every time you do an operation which might return a 1 column or 1 row matrix. I searched in R-help and did not see any previous proposals along

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:

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