similar to: Large vector support in data.frames

The second point is not really an issue - R already uses numerics for larger-than-32-bit indexing at R level and it works just fine for objects up to ca. 72 petabytes. However, the first one is a bit more relevant than one would think. At one point I have experimented with allowing data frames with more than 2^31 rows, but it breaks in many places - some quite unexpected. Beside dim() there is

Ivan, Simon, Thanks for the replies. I can work around the limitation. I currently either divide the data into shards or use a list with (long) vectors depending on what I am trying to do. But I have to transform between the two representations which takes time and memory and often need more code than I would have if I could have used data.frames. Being able to create large (> 2^31-1

Dirk Eddelbuettel <edd at debian.org> schreef: > On 13 May 2015 at 17:27, Jan van der Laan wrote: > | > | I have some cpp-files from another library (boost) in a subdirectory > | in my src directory (src/boost_src). I include these using the > | following two lines in my Makevars: > | > | SOURCES = $(wildcard *.cpp boost_src/*.cpp) > | OBJECTS = $(SOURCES:.cpp=.o)

Dear R helpers I have following input f = c(257, 520, 110). I need to generate a decreasing sequence (decreasing by 100) which will give me an input (in a tabular form) like 257, 157, 57 520, 420, 320, 220, 120, 20 110, 10 I tried the following R code f = c(257, 520, 110) yy = matrix(data = NA, nrow = 3, ncol = 6) for (i in 1:3)      {      value = NULL      for (j in 1 : 6)           {

Hi All, Can you please help me, why this code in not generating line chart? library(ggplot2) par(mfrow=c(1,3)) #qplot(TIME1, BASCHGA, data=Orange1, geom= c("point", "line"), colour= ACTTRT) unique(Orange1$REFID) -> refid for (i in refid) { Orange2 <- Orange1[i == Orange1$REFID, ] pdf('PGA.pdf') qplot(TIME1, BASCHGA, data=Orange2, geom= c("line"),

One other solution that's only a little crazy: you could have a R function within your package that generates the appropriate (portable) Makevars, and within the package `configure` script call that function. For example" R --vanilla --slave -e "source('R/makevars.R'); makevars()" And that 'makevars()' function could generate portable

I use the following code to create two data.frames d1 and d2 from a list: types <- c("integer", "character", "double") nlines <- 10 d1 <- as.data.frame(lapply(types, do.call, list(nlines)), stringsAsFactor=FALSE) l2 <- lapply(types, do.call, list(nlines)) d2 <- as.data.frame(l2, stringsAsFactors=FALSE) I would expect d1 and d2 to be the

On May 13, 2015, at 2:28 PM, Henrik Bengtsson <henrik.bengtsson at ucsf.edu> wrote: > While at it: 'Makevars' is an R invention (i.e. documentation of it > is only available through the R docs), correct? /Henrik > Well, it's just a Makefile fragment that gets included along with the rest of the Makefiles, so for all practical purposes it's just a Makefile which

The following code crashes R (I know I shouldn't try to estimate such a model; this was a bug in some code of mine). I also tried with R-devel; same result. tab <- structure(list(dob_day = c(FALSE, FALSE, FALSE, FALSE, TRUE, TRUE, TRUE, TRUE), dob_mon = c(FALSE, FALSE, TRUE, TRUE, FALSE, FALSE, TRUE, TRUE), dob_year = c(FALSE, TRUE, FALSE, TRUE, FALSE, TRUE, FALSE, TRUE), n =

>>>>> Jan van der Laan <rhelp at eoos.dds.nl> >>>>> on Fri, 6 Oct 2017 12:13:39 +0200 writes: > It is actually model.matrix that crashes, not glm. Same > crash occurs with e.g. lm. > model.matrix(dob_mon ~ dob_day*dob_mon, data = tab) > also crashes R. Yes, segmentation fault. It only happens when these are *logical*

What is the correct way to combine multiple calls to odfCat, odfItemize, odfTable etc. inside a function? As an example lets say I have a function that needs to write two paragraphs of text and a list to the resulting odf-document (the real function has much more complex logic, but I don't think thats relevant). My first guess would be: exampleOutput <- function() {

That's amazing! Thank you!!! One follow up question, if that's OK? If, instead of using hard-coded CSV, I read the CSV into a variable first, then it fails again with a parse error. Code below. So, if I read the CSV into a variable, do I need an additional wrapper method? Seems like it should still work. Thanks in advance for your reply. -M String inputIris =

Dear list, I get some strange results with daply from the plyr package. In the example below, the average age per municipality for employed en unemployed is calculated. If I do this using tapply (see code below) I get the following result: no yes A NA 36.94931 B 51.22505 34.24887 C 48.05759 51.00198 If I do this using daply: municipality no yes

Hello! I am optimizing my code in R and for this I need to know a bit more about the internals. It would help tremendously if someone could link me to a page with O()-complexities of all the operations. In this particular case, I need something like a linked list with O(1) insertLast/First ability. I can't preallocate a vector since I do not know the final size of the list ahead of time. The

Hi! I have to import some TXT files into R, but the separation between the columns are made with different blank spaces, but each file use the same separation. Example: 31 104 5 0 11RUA SAO SEBASTIAO 25 BAIRRO FILETO 01

It seems like many of the multi-threaded BLASes have some sort of fundamental problem preventing use in the way Juan suggests: - Dirk's vignette states that ATLAS "fixes the number of cores used at compile-time and cannot vary this setting at run-time", so any user-friendly implementation for R would have to compile ATLAS for 1-16 threads to allow the user to switch at run-time.

I didn't do the compile; is there a way to check whether that was used? If not, I'll inquire with our sysadmin and report back. In any case, my suggestion was motivated by the fact that some parts of R use OpenMP while others do not, in the hope that the former could have their OpenBLAS omelet without breaking the OpenMP eggs, so to speak. On 01/09/2018 06:41 PM, Keith O'Hara

Jeroen: Thank you for pointing me to ndjson, which I had not heard of and is exactly my case. My experience: jsonlite::stream_in - segfaults ndjson::stream_in - my fault, I am running Ubuntu 14.04 and it is too old so it won't compile the package corpus::read_ndjson - works!!! Of course it does a different simplification than jsonlite::fromJSON, so I have to change some code, but

Please pardon my ignorance, but doesn't OpenBLAS still not always play nicely with multi-threaded OpenMP? (for example, don't race conditions sometimes crop up)? If so, it might be nice to have the ability to temporarily disable multi-threaded OpenMP (effectively: omp_set_num_threads(1)) for the duration of operations using OpenBLAS. Regards Ben > Julia using OpenBLAS is *very*

Julia Programming Language uses also OpenBlas, and it is actively maintained with bugs being fixed as I have checked it out: http://www.openblas.net/Changelog.txt So I still see it ok to be included as an options(...) feature (by default off, just for safety), over other Blas libraries. R could not use Intel MKL for legal reasons (I think), because as long that R ships with GPL libraries,