search for: symsxps

Can someone offer some advice on how to properly evaluate a SYMSXP from a .Call ? I have the following in R: variable xn, with an attribute "mu" which references the variable mu in the global environment. I know "references" is a loose term; mu was defined in this fashion as a way to implement deferred binding: foo <- function(x,mu) { attr(x,"mu") <-

Hi, Again, sorry for the length of this post. Once I get my new office I will get a website set up on my work machine and will simply post a link to the log since I doubt many people are truly interested in these logs. To further analyze what is happening, I added my own routine in main.c called DEBUG_SET_NAMED and then redefined the SET_NAMED macro to use it and then rebuilt R. I

Hello, I?m experimenting with ALTREP and was wondering if there is a preferred way to create an ALTREP wrapper vector without using .Internal(wrap_meta(?)), which R CMD check doesn?t like since it uses an .Internal() function. I was trying to create a factor that used an ALTREP integer, but attempting to set the class and levels attributes always ended up duplicating and materializing the

Hello All, I tried the sample code from the help. Although '{' is assigned to 'do', the call syntaxes for 'do' and '{' are not the same ('do' has ','s, but '{' has line breaks). I guess there is a difference in parsing the code block of 'do' and the code block of '{'. Could you please let me know some internal details so that

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

Hi Kylie, For your question, I don't think a wrapper can completely solve your problem. The duplication occurs since your variable y has more than 1 reference number( Please see highlighted), so even you have a wrapper, any changes on the value of the wrapper still can trigger the duplication. > .Internal(inspect(y)) > @7fb0ce78c0f0 13 INTSXP g0c0 *[NAM(7)]* matter vector (mode=3,

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?

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've created this class: setClass("example", representation ( size = "numeric", id = "character" ) ) Suppose I create a new instance of this class: > x <- new("example", 4, "id_value") This creates an S4 object with two slots. Am I correct in thinking that slots are "filled" by SEXPs?

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

Hi Jiefei and Kylie, Great to see people engaging with the ALTREP framework and identifying places we may need more tooling. Comments inline. On Thu, Jul 18, 2019 at 12:22 PM King Jiefei <szwjf08 at gmail.com> wrote: > > If that is the case and you are 100% sure the reference number should be 1 > for your variable *y*, my solution is to call *SET_NAMED *in C++ to reset > the

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

...vide something else. >> >> >>> But another idea (and one pretty similar to John's) is to follow the >>> SYMSXP >>> design at the C level, where there is a structure that points to the name >>> and a value. We already have SYMSXPs at the R level of course (name >>> objects) but they do not provide access to the value, which is typically >>> R_UnboundValue. But this does not even need to be implemented with SYMSXP. >>> The design would allow something like: >>> >>...

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

Hi I'm trying to implement something similar to the following R snippet using C. I seem to have hit the wall on accessing class slots using C. library(fPortfolio) lppData <- 100 * LPP2005.RET[, 1:6] ewSpec <- portfolioSpec() nAssets <- ncol(lppData) setWeights(ewSpec) <- rep(1/nAssets, times = nAssets) ewPortfolio <- feasiblePortfolio( data = lppData, spec = ewSpec,

Hello, I would like for my C function to be able to manipulate some values stored in an R data frame. To achieve this, a need the (real) memory address where the R data frame stores its data (hopefully in a contiguous way). Then, from R, I call the C function and passing this memory address as a parameter. The question: how can we get the memory address of the R data frame? Thank you! L.

Hi Lille, Is it possible you're looking for tracemem() or inspect() ? > x <- data.frame(z = 1:10)> tracemem(x)[1] "<0x55aa743e0bc0>" > x[1] <- 2Ltracemem[0x55aa743e0bc0 -> 0x55aa778f6ad0]: tracemem[0x55aa778f6ad0 -> 0x55aa778f6868]: [<-.data.frame [<- tracemem[0x55aa778f6868 -> 0x55aa778f5b48]: [<-.data.frame [<- >

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,

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:

...#39;t right for a > particular case you can provide something else. > > >> But another idea (and one pretty similar to John's) is to follow the >> SYMSXP >> design at the C level, where there is a structure that points to the name >> and a value. We already have SYMSXPs at the R level of course (name >> objects) but they do not provide access to the value, which is typically >> R_UnboundValue. But this does not even need to be implemented with SYMSXP. >> The design would allow something like: >> >> binding <- getBinding("x&quo...