similar to: Why does duplicate() make deep copies?

There seems to be a latent flaw in the definition of struct SEXPREC in Rinternals.h, which likely doesn't cause problems now, but could if the relative sizes of data types changes. The SEXPREC structure contains a union that includes a primsxp, symsxp, etc, but not a vecsxp. However, in allocVector in memory.c, zero-length vectors are allocated using allocSExpNonCons, which appears to

I'm trying to track down a bug in some experimental code, where an object's attribute is getting messed up. This means I'd like to examine R objects while within gdb. One of the things I'd like to do is to examine the names of all the attributes. This is exactly what an example in the R Extensions manual section 4.11.2 "Inspecting R objects when debugging" does,

Full_Name: Ed Borasky Version: 1.8.1 OS: Windows XP Professional Submission from: (NULL) (208.252.96.195) R 1.8.1 seems to be running into a memory allocation problem in the "aggregate" function. I have a rather large dataset (14 columns by 223,000 rows -- almost 40 megabytes) and a script that performs some processing on it. The system is a 768 MB Pentium 4. Here's the console

[some de-capitalization of *SXP done manually by mailing list maintainer ; the originally was caught as potential spam. MM] I have a little R program that crashes with the message xmalloc: out of virtual memory The code has a repeat{} loop that watches the sizes of some files. When there's an increase it updates things by reading the last 65 lines of each file, doing some

Hi, A common idiom in the R sources is to convert objects between LANGSXP and LISTSXP by using SET_TYPEOF. However, this is soon going to be disallowed in packages. From what I can see, there isn't currently a direct way to convert between these two object types using the available API. At the R level, one can convert calls to pairlists with: >

On Thu, Feb 1, 2018 at 12:14 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>>> on Tue, 30 Jan 2018 15:57:42 -0800 writes: > > > I just meant that the minimal contract for as.list() appears to be that it > > returns a VECSXP. To the user, we might say

My understanding is that R will not make copies of lists if there is only one reference to the object. However, I've encountered a case where R does make copies, even though (I think) there should be only one reference to the object. I hope that someone could shed some light on why this is happening. I'll start with a simple example. Below, x is a list with one element, and changing that

Inside of the anyNA() function, it will use the legacy any(is.na()) code if x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster ITERATE_BY_REGION, which is typically 5x faster in my testing. Is the OBJECT() condition really necessary, or could it be moved after the switch() for the individual TYPEOF(x)

Hi, I expected NAMED to be 1 in all these three cases. It is for one of them, but not the other two? > R --vanilla R version 2.14.0 (2011-10-31) Platform: i386-pc-mingw32/i386 (32-bit) > x = 1L > .Internal(inspect(x)) # why NAM(2)? expected NAM(1) @2514aa0 13 INTSXP g0c1 [NAM(2)] (len=1, tl=0) 1 > y = 1:10 > .Internal(inspect(y)) # NAM(1) as expected but why different to x?

On Fri, 5 Aug 2016, Winston Chang wrote: > My understanding is that R will not make copies of lists if there is > only one reference to the object. However, I've encountered a case > where R does make copies, even though (I think) there should be only > one reference to the object. I hope that someone could shed some light > on why this is happening. > > I'll start

Happy new year to all; A few days ago, I posted similar problem. At that time, I found out that our R program had been 32-bit compiled, not 64-bit compiled. So the R program has been re-installed in 64-bit and run the same job, reading in 150 Affymetrix U133A v2 CEL files and perform dChip processing. However, the memory problem happened again. Since the amount of physical memory is 64GB, I think

Maybe behavior of 'as.list' in R is not inherited from S? - From https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=78 , in "the prototype" (S), 'as.list' on a data frame gave a list, not a data frame as given by the default 'as.list' in R. That led to introduction of 'as.list.data.frame'. - From

Hi Everyone, At the moment it is not possible to replicate complex lists, but only simple ones: > rep(list(fred = 1:10), 10) # works fine > rep(list(fred = 1:10, happy = "squash"), 10) Error in rep(list(fred = 1:10, happy = "squash"), 10) : Unimplemented feature in rep There is nothing in ?rep that suggests that the latter should not work, and I think it would

Hello, As this little program illustrates, duplicating a STRSXP does not seem deep enough. require( inline ) fx <- cfunction( signature( x = "character"), ' SEXP y = PROTECT( duplicate( x ) ); int n = LENGTH(x); int nc = 0 ; char* p = 0 ; for( int i=0; i<n; i++){ p = (char*)( CHAR( STRING_ELT( y , i ) ) ); nc = strlen( p ) ; for( int j=0; j<nc; j++){ p[j] =

Dear all, I have written a little R program to convert images. See below. Within the loop over j (the filenames) memory consumption grows constantly. rm( ... ) inside the loop did not help. Memory does not grow if I remove the writeBin statements between the two #-------- marks. But obviously this is not solution I want... Thanks for any advice. Manfred Baumstark P.S. As I'm new to R:

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

Hi, all; I know there has been a lot of discussions on memory usage in R. However, I have some odd situation here. Basically, I have a rare opportunity to run R in a system with 64GB memory without any limit on memory usage for any person or process. However, I encountered the memory problem error message like this: Error: cannot allocate vector of size 594075 Kb I got this error message while

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

Specifically, the srcfile attribute of the srcref attribute of the two instances of the functions contain different environments, AFAICT. Environments are compared only by exact pointer, so this forces return FALSE. Snippets from .Internal(inspect(x)) and .Internal(inspect(y)): @cca008 03 CLOSXP g0c0 [MARK,NAM(2),ATT] FORMALS: @604b58 00 NILSXP g0c0 [MARK,NAM(2)] BODY: @cc9650 06 LANGSXP

Hello, I think there is an inconsistency in the handling of the compact form of the row.names attributes. When n is the number of rows of a data.frame, the compact form is c(NA_integer_,-n), as in: > d <- data.frame(x=1:10) > .Internal(inspect(d)) @104f174a8 19 VECSXP g0c1 [OBJ,NAM(2),ATT] (len=1, tl=0) @103a7dc60 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,... ATTRIB: @104959380