similar to: scan(..., skip=1e11): infinite loop; cannot interrupt

On Fri, 10 Feb 2023 23:38:55 -0600 Spencer Graves <spencer.graves at prodsyse.com> wrote: > I have a 4.54 GB file that I'm trying to read in chunks using > "scan(..., skip=__)". It works as expected for small values of > "skip" but goes into an infinite loop for "skip=1e11" and similar > large values of skip: I cannot even interrupt it; I

With ?if?(!j--)?{ ?????R_CheckUserInterrupt(); ?????j?=?10000; ?} as?in?current?R?devel?(r83976),?j goes negative (-1) and interrupt is checked every 10001 instead of 10000. I?prefer ?if?(!--j)?{ ?????R_CheckUserInterrupt(); ?????j?=?10000; ?} . In?current?R?devel?(r83976),?if?EOF?is?reached,?the?outer?loop?keeps?going,?i?keeps?incrementing?until?nskip.

Full_Name: Naoki Takebayashi Version: 0.65.1 OS: Linux/Alpha Submission from: (NULL) (129.79.224.171) When I was reading a file with read.table("junk.data"), it seg-faulted. I found out that it seg-faulted when the last line of data file didn't have the newline char. For example, file like this: 23 3 31 2 24 1<EOF> Here is a fix. --- R-0.65.1/src/main/scan.c.orig

When reading a file with scan(), the following crashes R under Solaris and WinNT 4.0 (versions below): > ads <- scan("Bltiadu.dat", what=list(,,)) Would an error message be more logical? Note that the followings work (the data file has 201 lines and 3 columns): > ads <- scan("Bltiadu.dat", what=list(0,,)) Read 603 lines > ads <-

Hello, I realize that using: x[x > 3 & x < 5] I can fetch all elements between 3 and 5. However I read in from a CSV file, and I would like to fetch all columns from within a range ( 842-2411). In teh past, I have done this to fetch just select few columns: data <- read.csv(filein, header=TRUE, nrows=320, skip=nskip) data_filter <- data[c(2,12,17)]

I believe IO in R is slow because of the way it is implemented, not because it has to do some extra work for the user. I compared scan() with 'what' argument set (which is, AFAIK, is the fastest way to read a CSV file) to an equivalent C code. It turned out to be 20 - 50 times slower. I can see at least two main reasons why R's IO is so slow (I didn't profile this though): A) it

Is there a missing value constant defined for R_xlen_t, cf. NA_INTEGER (== R_NaInt == INT_MIN) for int(eger)? If not, is it correct to assume that missing values should be taken care/tested for before coercing from int or double? Thank you, Henrik

With a recent SVN build (R Under development (unstable) (2013-07-10 r63264) -- "Unsuffered Consequences"), I'm having trouble installing the robustbase package. The bottom line is that I *think* it's a 32-bit-system problem, but I could easily be mistaken. robustbase is passing its package checks: http://cran.r-project.org/web/checks/check_results_robustbase.html ... but from

It happens in the token function in gram.c:     c = SkipSpace();     if (c == '#') c = SkipComment(); and then SkipComment goes like that: static int SkipComment(void) {     int c;     while ((c = xxgetc()) != '\n' && c != R_EOF) ;     if (c == R_EOF) EndOfFile = 2;     return c; } which effectively drops comments. Would it be possible to keep the information

Hello, I do not have an account on R Bugzilla, so I will post my bug report here. I want to report a very old bug in base R *source()* function. It relates to sourcing some R scripts in UTF-8 encoding on Windows machines. For some reason if the UTF-8 script is containing cyrillic letter *"?"*, the script execution is interrupted directly on this letter (btw the same scripts are sourcing

Hi all, I found an unexpected behavior when I was trying to use the macro defined in "R_ext/Itermacros.h" to loop over an atomic vector. Here is a minimum example: C++ code ``` #include "R_ext/Itermacros.h" #define GET_REGION_BUFSIZE 2 //Redefine the macro since C++ is not happy with the implicit type conversion #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype,

I'm observing that base::sum(x, na.rm=FALSE) for typeof(x) == "double" is much more time consuming when there are missing values versus when there are not. I'm observing this on both Window and Linux, but it's quite surprising to me. Currently, my main suspect is settings in on how R was built. The second suspect is my brain. I hope that someone can clarify the below

On 10/25/19 11:01 AM, Tomas Kalibera wrote: > On 10/23/19 6:45 AM, Wang Jiefei wrote: >> Hi all, >> >> I found an unexpected behavior when I was trying to use the macro >> defined >> in "R_ext/Itermacros.h"? to loop over an atomic vector. Here is a >> minimum >> example: >> >> C++ code >> ``` >> #include

Dear all, According to CHANGES IN R 3.0.0: o diag() as used to generate a diagonal matrix has been re-written in C for speed and less memory usage. It now forces the result to be numeric in the case diag(x) since it is said to have 'zero off-diagonal entries'. diag(x) does not work for character vector in R 3.0.0 any more. For example, v <- c("a",

Le 19/04/2018 ? 09:30, Tomas Kalibera a ?crit?: > On 04/19/2018 02:06 AM, Duncan Murdoch wrote: >> On 18/04/2018 5:08 PM, Tousey, Colton wrote: >>> Hello, >>> >>> I want to report a bug in R that is limiting my capabilities to >>> export a matrix with write.csv or write.table with over >>> 2,147,483,648 elements (C's int limit). I found

Sorry for post a lot of things, for the first part of code, I copied my C++ iter macro by mistake(and you can see an explicit type casting). Here is the macro definition from R_exts/Itermacros.h #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \ strt, nfull, expr) do { \ * const** etype *px = DATAPTR_OR_NULL(sx); *

Hi, The function cummax() seems to have a bug. > x <- c(NA, 0) > storage.mode(x) <- "integer" > cummax(x) [1] NA 0 The correct result of this case should be NA NA. The mistake in [ https://github.com/wch/r-source/blob/trunk/src/main/cum.c#L130-L136] may be the reason. Best Regards, Dongcan -- Dongcan Jiang Team of Search Engine & Web Mining School of Electronic

> Do you have R code (including set.seed(.) if relevant) to show on how to generate > the large square matrices you've mentioned in the beginning? So we get to some > reproducible benchmarks? Hi Martin, Here is the program I used. I only generate 2 random numbers and reuse them to make the benchmark run faster. Let me know if there is something I can do to help--alternate

On 18/04/2018 5:08 PM, Tousey, Colton wrote: > Hello, > > I want to report a bug in R that is limiting my capabilities to export a matrix with write.csv or write.table with over 2,147,483,648 elements (C's int limit). I found this bug already reported about before: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17182. However, there appears to be no solution or fixes in upcoming

Hi devel team, I'm working on C/C++ level ALTREP compatibility for a package. The package previously used pointers to access the data of a SEXP, so it would not work for some ALTREP objects which do not have a pointer. I plan to rewrite the code and use functions like get_elt, get_region, and get_subset to access the values of a vector, so I have a few questions for ALTREP: 1. Since an