search for: rawsxps

Hi all I had written a gdb macro to dump the string representation of an SEXPREC type when I realised everything I needed was in inspect.c already in the typename() function. However, the typename function doesnt handle the RAWSXP type, so if possible, could the following patch be applied (I've just put in inline as it is a trivial 1-liner)? Index: src/main/inspect.c

Full_Name: Hin-Tak Leung Version: R 2.2.1 OS: x86_64-redhat-linux-gnu Submission from: (NULL) (131.111.186.92) rbind/cbind is unimplemented for raw (RAWSXP) types. I have a working patch implementing the functionality, to follow. --please do not edit the information below-- Version: platform = x86_64-redhat-linux-gnu arch = x86_64 os = linux-gnu system = x86_64, linux-gnu status = major

Full_Name: Prokaj Vilmos Version: R 2-4-0 OS: Windows Submission from: (NULL) (193.224.79.8) PackBits(rbinom(32,1,0.5)==1,"integer") does not work. z<-packBits(rbinom(32,1,.5)==1,"integer") Error in packBits(x, type) : argument 'x' must be raw, integer or logical Taking a closer look at the C code main/character.c do_packBits rutin one can find the following

Hello, Suppose in the following code, PROTECT(sr = R_tryEval( .... )) sr is a RAWSXP vector. I wish to return another RAWSXP starting at position 13 onwards (base=0). I could create another RAWSXP of the correct length and then memcpy the required bytes and length to this new one. However is there a more efficient method? Regards Saptarshi Guha

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

A package that I develop (xcms) sometimes needs to read and process vectors several hundreds of megabytes in size. (They only represent parts of a large data sets which can approach nearly 100GB.) Unfortunately, R sometimes hits the 2GB memory limit of Win32. To help cut the memory footprint in half, I'm implementing a "float" class as a subclass of "raw". Because

I have a use case where I would like to create an SEXP around an existing buffer that is managed by R, thus avoiding a copy operation. If I have something like: void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n))); ... additional maniupulation ... SEXP x = somefunc(SXPTYPE, n, p); // ???? Is there a "placement" constructor available? (I have arranged for the corresponding

Hi, I've been doing some tests using serialize() to a raw vector: df <- data.frame(runif(50e6,1,10)) ser <- serialize(df,NULL) In this example the data frame and the serialized raw vector occupy ~400MB each, for a total of ~800M. However the memory peak during serialize() is ~1.2GB: $ cat /proc/15155/status |grep Vm ... VmHWM: 1207792 kB VmRSS: 817272 kB We work with very

Thank you for the patch. To clarify: this is not a bug. ?.C says The mapping of the types of R arguments to C or Fortran arguments in '.C' or '.Fortran' is R C Fortran integer int * integer numeric double * double precision - or - float * real complex Rcomplex * double complex

Hello, I get an error when binary structures from a pipe 'Error: cons memory exhausted (limit reached?)' (but R does not crash) This is probably due to some bug in my code, but occurs after reading about 85K pairs of RAWSXP objects (each < 20 bytes). I do not have any explicit calls to malloc/calloc I'm going through my code and have inserted the (brute force) printf statements

I found a bug in one of the fourteen speed patches I posted, namely in patch-vec-subset. I've fixed this (I now see one does need to duplicate index vectors sometimes, though one can avoid it most of the time). I also split this patch in two, since it really has two different and independent parts. The patch-vec-subset patch now has only some straightforward (locally-checkable) speedups for

Presumably one could stream over the data twice, the first to get the size, without storing the data. Slower but more memory efficient, unless I'm missing something. Michael On Tue, Mar 17, 2015 at 2:03 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote: > Jorge, > > what you propose is not possible because the size of the output is > unknown, that's why a

I've looked at how to speed up the transpose function in R (ie, t(X)). The existing code does the work with loops like the following: for (i = 0; i < len; i++) REAL(r)[i] = REAL(a)[(i / ncol) + (i % ncol) * nrow]; It seems a bit optimistic to expect a compiler to produce good code from this. I've re-written these loops as follows: for (i = 0, j = 0; i<len; i +=

In R 2.6.1, a couple of places (discovered using valgrind) where the requested size of string buffers fails to account correctly for the trailing null byte: 1. In src/appl/strsignif.c, 'f0' and 'form' at l. 108-9 each need at least 1 extra byte. 2. In src/main/util.c, 'out' at l. 1081 needs at least one extra byte. (Remember that the return value of strlen does not

Dear Developers, I've been struggling through writing R extension in C. I've been using an external pointer to store my data (please see sample below). I encountered a very weird erroneous behaviour: when I tried to use my external pointer to a structure holding several types of data, including SEXPs, I discovered that SEXPs change their types between returning from initialization

Hello, I call a function via .Call passing to it a raw vector(D) and an integer(I) The vector is a series K1,KData1, V1,VData1, K2, KData2, ... where the integer K1 is the length of Data1 and similarly for Ki (wrt Datai)(similarly for V*) There 2*I such pairs( (Ki,KDatai), (Vi,VDatai)) The numbers Ki(and Vi) are written in network order. I am returning a list of I elements each element a

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

http://www.keittlab.org/ On Wed, Mar 29, 2017 at 1:04 PM, Herv? Pag?s <hpages at fredhutch.org> wrote: > Hi Tim, > > On 03/29/2017 08:24 AM, Tim Keitt wrote: > >> I have a use case where I would like to create an SEXP around an existing >> buffer that is managed by R, thus avoiding a copy operation. >> > > What to you mean exactly by "an existing

Jorge, what you propose is not possible because the size of the output is unknown, that's why a dynamically growing PStream buffer is used - it cannot be pre-allocated. Cheers, Simon > On Mar 17, 2015, at 1:37 PM, Martinez de Salinas, Jorge <jorge.martinez-de-salinas at hp.com> wrote: > > Hi, > > I've been doing some tests using serialize() to a raw vector: >

Hi, I've been doing some tests using serialize() to a raw vector: df <- data.frame(runif(50e6,1,10)) ser <- serialize(df,NULL) In this example the data frame and the serialized raw vector occupy ~400MB each, for a total of ~800M. However the memory peak during serialize() is ~1.2GB: $ cat /proc/15155/status |grep Vm ... VmHWM: 1207792 kB VmRSS: 817272 kB We work with very