[Rd] Identify \Sexpr call?
More or less in the same vein as Henrik's post, is it possible to detect that a function is being called in an \Sexpr when generating an Rd file? Thank you -- Renaud Gaujoux Computational Biology - University of Cape Town South Africa __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identify \Sexpr call?
On 11-11-05 4:36 AM, Renaud Gaujoux wrote: More or less in the same vein as Henrik's post, is it possible to detect that a function is being called in an \Sexpr when generating an Rd file? Thank you Sure: have it check for a variable (or option or environment setting, or whatever) that was created in an earlier \Sexpr. Or take your life in your hands, and look back up the call stack. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Efficiency of factor objects
Perhaps 'data.table' would be a package on CRAN that would be acceptable. On 05/11/2011 16:45, Jeffrey Ryan wrote: Or better still, extend R via the mechanisms in place. Something akin to a fast factor package. Any change to R causes downstream issues in (hundreds of?) millions of lines of deployed code. It almost seems hard to fathom that a package for this doesn't already exist. Have you searched CRAN? Jeff On Sat, Nov 5, 2011 at 11:30 AM, Milan Bouchet-Valatnalimi...@club.fr wrote: Le vendredi 04 novembre 2011 à 19:19 -0400, Stavros Macrakis a écrit : R factors are the natural way to represent factors -- and should be efficient since they use small integers. But in fact, for many (but not all) operations, R factors are considerably slower than integers, or even character strings. This appears to be because whenever a factor vector is subsetted, the entire levels vector is copied. Is it so common for a factor to have so many levels? One can probably argue that, in that case, using a numeric or character vector is preferred - factors are no longer the natural way of representing this kind of data. Adding code to fix a completely theoretical problem is generally not a good idea. I think you'd have to come up with a real use case to hope convincing the developers a change is needed. There are probably many more interesting areas where speedups can be gained than that. Regards __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Patrick Burns pbu...@pburns.seanet.com twitter: @portfolioprobe http://www.portfolioprobe.com/blog http://www.burns-stat.com (home of 'Some hints for the R beginner' and 'The R Inferno') __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to infer default width and height for a device?
Hi. GENERAL: Is there a general method for inferring default device settings, particularly 'width' and 'height', that works for all devices? AFAIK, the answer is no, but there might be functions out there that I don't know of. POSTSCRIPT SPECIFIC: If not, I'm considering implementing such a method myself. Is it possible for R to infer the default 'width' and 'height' for the *postscript* device, or is this defined outside of R? I've noticed that they are not defined by the arguments to postcript(): args(grDevices::postscript) function (file = ifelse(onefile, Rplots.ps, Rplot%03d.ps), onefile, family, title, fonts, encoding, bg, fg, width, height, horizontal, pointsize, paper, pagecentre, print.it, command, colormodel, useKerning, fillOddEven) and in the list of predefined device options they are zero: ps.options()[c(width, height)] $width [1] 0 $height [1] 0 and debugging postcript() they are indeed passed as zeros to .External(PostScript, ...). sessionInfo() R version 2.14.0 Patched (2011-11-03 r57560) Platform: x86_64-pc-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] R.utils_1.9.0 R.oo_1.8.3R.methodsS3_1.2.1 loaded via a namespace (and not attached): [1] tools_2.14.0 Thanks Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
