search for: specialsxp

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

...) > gc() used (Mb) gc trigger (Mb) Ncells 701188 18.8 2683553 71.7 Vcells 1447712 11.1 8201413 62.6 > memory.profile() NILSXP SYMSXP LISTSXP CLOSXP ENVSXP PROMSXP LANGSXP 1 7228 244243 3949 495 773 113819 SPECIALSXP BUILTINSXP CHARSXP LGLSXP INTSXP 207 1177 283663 4661 0 0 49 REALSXP CPLXSXP STRSXP DOTSXP ANYSXP VECSXP EXPRSXP 13383 9 24870 0 0 2598 2...

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:

...2002 month 10 day 01 language R ----------------- At the beginning ------------- --- gc() returns: used (Mb) gc trigger (Mb) Ncells 254150 6.8 467875 12.5 Vcells 408499 3.2 886807 6.8 --- memory.profile() returns: NilSXP SymSXP ListSXP CloSXP EnvSXP PromSXP LangSXP SpecialSXP 1 4919 128880 1440 13 18 63607 59 BUILTINSXP CHARSXP LGLSXP - - INTSXP REALSXP CPLXSXP STRSXP 513 37178 1712 0 0 237 9047 8 10201 DOTSXP ANYSXP VECSXP EXPRSXP - EXTPTRSXP WEAKREFSXP 1 0 341 2 0 0 0 ---...

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

...he R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-unknown-linux-gnu (64-bit) I now have an example, i.e. a seed, that produces the error: Error in crq.fit.por(xb, yb, cb, weights = w, ctype = ctype, ...) : GC encountered a node (0xb488bc0) with an unknown SEXP type: SPECIALSXP at memory.c:927 I've tried capturing the data for this call and running it from the terminal window, but annoyingly it fails to complain when I do that. I thought someone might have a better idea. My experience with gdb is very limited, I tried running R -d gdb which reproduces the error,...

...Vcells 76716794 585.4 305954055 2334.3 ... > mem.limits() nsize vsize NA NA > object.size(Data) [1] 608355664 > memory.profile() NILSXP SYMSXP LISTSXP CLOSXP ENVSXP PROMSXP LANGSXP 1 30484 372383 4845 420 180 127274 SPECIALSXP BUILTINSXP CHARSXP LGLSXP INTSXP 203 1168 111430 5296 0 0 44650 REALSXP CPLXSXP STRSXP DOTSXP ANYSXP VECSXP EXPRSXP 13382 9 60170 0 0 26003 0...

...ncourage bad practice. :: is different and there are good arguments > for using it in code, but I'm not yet seeing good arguments for use in > ways that would be performance-critical, but I'm happy to be convinced > otherwise. If there is a need for a faster :: then going to a > SPECIALSXP is fine; it would also be good to make the byte code > compiler aware of it, and possibly to work on ways to improve the > performance further e.g. through cacheing. > > Best, > > luke > > > On Thu, 22 Jan 2015, Peter Haverty wrote: > > >> Hi all, >> &gt...

...gt; 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 a regular function with a >> very limited impact on the stack. And if implemented as a SPECIALSXP, >> it would be completely invisible. We've been planning to rewrite %>% >> to fix the performance and the stack print, it's just low priority. > > I don't know what Gabe had in mind, but the downside to pipes that I see is that they are single statements. I'd...

...ncourage bad practice. :: is different and there are good arguments > for using it in code, but I'm not yet seeing good arguments for use in > ways that would be performance-critical, but I'm happy to be convinced > otherwise. If there is a need for a faster :: then going to a > SPECIALSXP is fine; it would also be good to make the byte code > compiler aware of it, and possibly to work on ways to improve the > performance further e.g. through cacheing. > > Best, > > luke > > > On Thu, 22 Jan 2015, Peter Haverty wrote: > > >> Hi all, >> &gt...

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

...(Mb) Ncells 797983 21.4 1710298 45.7 Vcells 76716811 585.4 305954068 2334.3 > object.size(Data) [1] 608355664 > memory.profile() NILSXP SYMSXP LISTSXP CLOSXP ENVSXP PROMSXP LANGSXP 1 30484 372373 4845 420 180 127274 SPECIALSXP BUILTINSXP CHARSXP LGLSXP INTSXP 203 1168 111434 5296 0 0 44649 REALSXP CPLXSXP STRSXP DOTSXP ANYSXP VECSXP EXPRSXP 13382 9 60173 0 0 26002 0...

...ferent and there are good arguments >>> for using it in code, but I'm not yet seeing good arguments for use in >>> ways that would be performance-critical, but I'm happy to be convinced >>> otherwise. If there is a need for a faster :: then going to a >>> SPECIALSXP is fine; it would also be good to make the byte code >>> compiler aware of it, and possibly to work on ways to improve the >>> performance further e.g. through cacheing. >>> >>> Best, >>> >>> luke >>> >>> >>> On Thu, 2...

...it faster may just encourage bad practice. :: is different and there are good arguments for using it in code, but I'm not yet seeing good arguments for use in ways that would be performance-critical, but I'm happy to be convinced otherwise. If there is a need for a faster :: then going to a SPECIALSXP is fine; it would also be good to make the byte code compiler aware of it, and possibly to work on ways to improve the performance further e.g. through cacheing. Best, luke On Thu, 22 Jan 2015, Peter Haverty wrote: > Hi all, > > When S4 methods are defined on base function (say, &quot...

...e 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 a regular function with a very limited impact on the stack. And if implemented as a SPECIALSXP, it would be completely invisible. We've been planning to rewrite %>% to fix the performance and the stack print, it's just low priority. About the semantics of local evaluation that were proposed in this thread, I think that wouldn't be right. A native pipe should be consistent wit...

...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 a regular function with a >>> very limited impact on the stack. And if implemented as a SPECIALSXP, >>> it would be completely invisible. We've been planning to rewrite %>% >>> to fix the performance and the stack print, it's just low priority. >> >> I don't know what Gabe had in mind, but the downside to pipes that I >> see is that they are si...

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

...ctice. :: is different and there are good arguments >> for using it in code, but I'm not yet seeing good arguments for use in >> ways that would be performance-critical, but I'm happy to be convinced >> otherwise. If there is a need for a faster :: then going to a >> SPECIALSXP is fine; it would also be good to make the byte code >> compiler aware of it, and possibly to work on ways to improve the >> performance further e.g. through cacheing. >> >> Best, >> >> luke >> >> >> On Thu, 22 Jan 2015, Peter Haverty wrote: &gt...

...ctice. :: is different and there are good arguments >> for using it in code, but I'm not yet seeing good arguments for use in >> ways that would be performance-critical, but I'm happy to be convinced >> otherwise. If there is a need for a faster :: then going to a >> SPECIALSXP is fine; it would also be good to make the byte code >> compiler aware of it, and possibly to work on ways to improve the >> performance further e.g. through cacheing. >> >> Best, >> >> luke >> >> >> On Thu, 22 Jan 2015, Peter Haverty wrote: &gt...