search for: specialsxps

Is it possible to define an external special function (SPECIALSXP)? I'm trying to do some language-level work, and don't want my arguments evaluated before they hit C. It looks like the only way to define a SPECIALSXP is by using XX0 in the `eval' field of R_FunTab; is there any way to make this applicable to externally defined functions?

Hello, For the BUILTINSXP and SPECIALSXP types, the R Internals page documents "An integer giving the offset into the table of primitives/.Internals. " What macro gives me the value of this integer? I guess something like this would work had R_USEINTERNALS been defined v->u.primsxp.offset (where v is a SEXP of either of the above types). What is the portable version? Thank you

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

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:

[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 all, When S4 methods are defined on base function (say, "match"), the function becomes a method with the body "base::match(x,y)". A call to such a function often spends more time doing "::" than in the function itself. I always assumed that "::" was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What

Dear All, I'm trying to track down a very erratic bug in some fortran; I have an example that quite consistently segfaults on windoz, and more sporadically on mac, all in the course of doing some bootstrap calculations, varying the set.seed call, but I'm now trying to see what is going on on our redhat system: R version 2.15.1 (2012-06-22) -- "Roasted Marshmallows"

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

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > > For default methods there ought to be a way to create those so the > default method is computed at creation or load time and stored in an > environment. We had considered that, but we thought the definition of the function would be easier to interpret if it explicitly specified the namespace, instead of

> > On 7 Oct 2019, at 13:47, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > On 07/10/2019 4:22 a.m., Lionel Henry wrote: >> Hi Gabe, >>> There is another way the pipe could go into base R that could not be >>> done in package space and has the potential to mitigate some pretty >>> serious downsides to the pipes relating to debugging

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > I'm not convinced that how to make :: faster is the right question. If > you are finding foo::bar being called often enough to matter to your > overall performance then to me the question is: why are you calling > foo::bar more than once? Making :: a bit faster by making it a > primitive will remove

Thank you for your reply Jiefei. I think in theory your solution should work. I'll have to give them a try. On Mon, 4 Nov 2019 23:41 Wang Jiefei, <szwjf08 at gmail.com> wrote: > Hi Morgan, > > My solutions might not be the best one(I believe it's not), but it should > work for your question. > > 1. Have you considered Rf_duplicate function? If you want to change

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

Hi, On 01/23/2015 07:01 AM, luke-tierney at uiowa.edu wrote: > On Thu, 22 Jan 2015, Michael Lawrence wrote: > >> On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: >>> >>> For default methods there ought to be a way to create those so the >>> default method is computed at creation or load time and stored in an >>>

I'm not convinced that how to make :: faster is the right question. If you are finding foo::bar being called often enough to matter to your overall performance then to me the question is: why are you calling foo::bar more than once? Making :: a bit faster by making it a primitive will remove some overhead, but your are still left with a lot of work that shouldn't need to happen more than

Hi Gabe, > There is another way the pipe could go into base R that could not be > done in package space and has the potential to mitigate some pretty > serious downsides to the pipes relating to debugging I assume you're thinking about the large stack trace of the magrittr pipe? You don't need a parser transformation to solve this problem though, the pipe could be implemented as

On 07/10/2019 8:38 a.m., Lionel Henry wrote: >> >> On 7 Oct 2019, at 13:47, Duncan Murdoch <murdoch.duncan at gmail.com >> <mailto:murdoch.duncan at gmail.com>> wrote: >> >> On 07/10/2019 4:22 a.m., Lionel Henry wrote: >>> Hi Gabe, >>>> There is another way the pipe could go into base R that could not be >>>> done in

Hi, In Rcpp, we now have a "Function" class to encapsulate functions (they cover all three kinds, but this may change). To call the function, what we do is generate a call with the function as the first node and then evaluate the call. SEXP stats = PROTECT( R_FindNamespace( mkString( "stats") ) ); SEXP rnorm = PROTECT( findVarInFrame( stats, install( "rnorm") ) )

On Thu, 22 Jan 2015, Michael Lawrence wrote: > On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: >> >> For default methods there ought to be a way to create those so the >> default method is computed at creation or load time and stored in an >> environment. > > We had considered that, but we thought the definition of the function >

Hi all, I use Luke's "::" hoisting trick often. I think it would be fantastic if the JIT just did that for you. The main trouble, for me, is in code I don't own. When common Bioconductor packages are loaded many, many base functions are saddled with this substantial dispatch and "::" overhead. While we have the hood up, the parser could help out a bit here too. It