[Rd] R Lapack – why a subset?
Hi, Why doesn't R include a full Lapack but only a subset? My cda package (now archived) relying on RcppArmadillo has broken multiple times on CRAN over the past few years following updates in the underlying Armadillo library, Every time it follows the same pattern: Armadillo adds a function to solve a specialised linear system more efficiently, and the corresponding Lapack routine is not included in the R Lapack subset used on CRAN, causing breakage. The workaround so far has been an unhappy compromise with Armadillo developers, adding a "crippled lapack" flag in the RcppArmadillo configure script, that triggers the use of alternative (suboptimal) routines and passes CRAN checks. Most RcppArmadillo-dependent packages don't see the problem; mine seems to be the only one using complex linear algebra. Two years ago a large number of Lapack routines were added* to R, and this nicely solved the issue for a while. Unfortunately the same problem resurfaced last year, with another missing Lapack routine, and my package is now archived (though it works fine with an external Lapack). More generally, this workaround is not satisfying for various reasons, and so I want to ask: why does R ship only a subset of Lapack in the first place? Best regards, baptiste * Relevant commit at https://github.com/wch/r-source/commit/98acd96f22eb795a933879c0d3f740e802855473 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_
On 13 February 2018 at 22:07, Ralf Stubner <ralf.stub...@r-institute.com> wrote: > On 13.02.2018 05:49, Baptiste Auguie wrote: > > On 13 February 2018 at 01:05, Dirk Eddelbuettel <e...@debian.org > > <mailto:e...@debian.org>> wrote: > > Maybe we are setting a more global "no advanced lapack" for Windows > that > > assures success when we assume that the other system will always > > have it. > > > > > > it sounds plausible, but it would be nice to know for sure. > > It is the case, c.f. > https://github.com/RcppCore/RcppArmadillo/blob/master/inst/i > nclude/RcppArmadilloConfig.h#L96-L106 > > > In > > particular, it doesn't explain why the external Lapack on linux appears > > to be missing these symbols (they're not very recent, as far as I can > > tell). I don't really know how to figure this out, but it seems to be > key. > > My understanding: > > * On Windows internal LAPACK is used but it is not affected due to the > defines quoted above. > * At least Debian & Co but probably also other Linux distributions > compile R with external LAPACK and are not affected. > * CRAN (and probably r-hub) use R compiled with internal LAPACK and is > therefore affected. > Thanks Ralf, now it makes more sense to me. I had misunderstood the situation on CRAN and r-hub and thought they used an external Lapack on linux. > * I do not understand why Mac OS is not affected. The FAQ [1] implies > that by default the internal BLAS/LAPACK is used. But then I do not see > the mentioned alternative libRblas.vecLib.dylib on a test system. > > [1] > https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which > -BLAS-is-used-and-how-can-it-be-changed_003f > > > > Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere. > See > > lines 67 to 95 of RcppArmadillo's configure.ac <http://configure.ac > >: > > https://github.com/RcppCore/RcppArmadillo/blob/master/confi > gure.ac#L67-L95 > > > > while this might solve the CRAN problem, it doesn't feel right to > > enforce the use of suboptimal routines throughout and on all platforms, > > including those that do in fact provide a full-fledged external Lapack. > > You could use this as a first step to get the package back into CRAN. > Later on you can try to only set the flag when an internal LAPACK is > detected, similar to the way RcppArmadillo does it. If my understanding > above is correct, the number of users with ARMA_CRIPPLED_LAPACK in your > package but not in RcppArmadillo will be quite small. > It would make sense to test for internal vs external Lapack and decide based on that (regardless of the OS); as you say, the results should be essentially identical to what happens when the same user installs RcppArmadillo on their machine. Unfortunately I don't know how to proceed. I copied RcppArmadillo's configure.ac script and tried to extract just the Lapack testing bits, but these macro and configure concepts are totally foreign to me. I believe it would be helpful to have a minimal example of this type of configuration for the dummy isolve package ( https://github.com/baptiste/isolve), if someone with such expertise and a linux machine is willing to help. Thanks, baptiste > > Greetings > Ralf > > -- > Ralf Stubner > Senior Software Engineer / Trainer > > R Institute GmbH > Dortustraße 48 > 14467 Potsdam > > T: +49 331 23 70 81 66 > F: +49 331 23 70 81 67 > M: +49 162 20 91 196 > > Mail: ralf.stub...@r-institute.com > > Sitz: Potsdam > Register: AG Potsdam HRB 27966 P > Ust.-IdNr.: DE300072622 > Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze > > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_
On 13 February 2018 at 01:05, Dirk Eddelbuettel <e...@debian.org> wrote: > > On 12 February 2018 at 22:16, Baptiste Auguie wrote: > | As far as I can tell Armadillo added specialised methods for banded > | matrices; the routines used to solve non-banded matrices probably haven't > | changed. > | > | Coming back to the error itself, what puzzles me is that it seems to be > | precisely the OSes relying on external Lapack that have a problem. It > | compiles fine on Windows, > | https://builder.r-hub.io/status/isolve_1.0.tar.gz-e3da3c1b83 > | 26e62e4e14a913e5bbb5a4 > | > | So it seems the problem is distinct from the previous issues with missing > | Lapack routines. > > Maybe we are setting a more global "no advanced lapack" for Windows that > assures success when we assume that the other system will always have it. > it sounds plausible, but it would be nice to know for sure. In particular, it doesn't explain why the external Lapack on linux appears to be missing these symbols (they're not very recent, as far as I can tell). I don't really know how to figure this out, but it seems to be key. > One thing you could try is to write a configure test in your package so > that > at build time a compile+link for the particular symbol is made. > I have no idea how to do this, and if did... > If the test succeeeds, export a new HAVE_XYZ_BANDED_ROUTINE define and then > convince Conrad to respect that flag. Otherwise have the code fall back to > alternatives just like the Windows build. > ... IIRC Conrad made it clear in the past that he would not consider further special cases for crippled Lapacks. > Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere. See > lines 67 to 95 of RcppArmadillo's configure.ac: > https://github.com/RcppCore/RcppArmadillo/blob/master/configure.ac#L67-L95 > while this might solve the CRAN problem, it doesn't feel right to enforce the use of suboptimal routines throughout and on all platforms, including those that do in fact provide a full-fledged external Lapack. > I could generalize the use in inst/include/RcppArmadilloConf > igGenerated.h.in > by respecting prior definitions, ie wrapping #ifndef around them. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > b. [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_
On 12 February 2018 at 04:52, Dirk Eddelbuettel <e...@debian.org> wrote: > > On 11 February 2018 at 19:13, Baptiste Auguie wrote: > | Hi, > | > | Sorry I never found the time to put this issue to rest. My cda package > has > | now been removed from CRAN because Armadillo's update on 'banded > | matrices' broke > | it on various platforms, and I've had users enquire about the situation. > As > | far as I can tell RcppArmadillo no longer enables the solution of complex > | linear systems on all platforms (see below). I'm happy to contribute a > new > > I don't think that is a fair statement. > > Armadillo, and RcppArmadillo, offer you an elegant, easy-to-use and rather > performant interface to underlying LAPACK code. In the R universe, we rely > on the LAPACK "brought to us by R". That generally works but ... > > ... you are, and have been, pushing the edge further by requiring complex > data types---and now Conrad chose to rely on another LAPACK routine. Bang. > > As far as I can tell Armadillo added specialised methods for banded matrices; the routines used to solve non-banded matrices probably haven't changed. Coming back to the error itself, what puzzles me is that it seems to be precisely the OSes relying on external Lapack that have a problem. It compiles fine on Windows, https://builder.r-hub.io/status/isolve_1.0.tar.gz-e3da3c1b83 26e62e4e14a913e5bbb5a4 So it seems the problem is distinct from the previous issues with missing Lapack routines. > | test for this to help future-proof this recurring issue, but resolving > the > | underlying issue is beyond me. > > That's the problem. > > You may need to look at other package with, when needed, extend offered > libraries. I.e. I also stand behind BH and hence parts of Boost, but > sometimes packages (e.g. in the stan world) need extra functions and so > they > package them. Upstream MLPACK is another example, and it extends Armadillo > where needed. > > Dirk > > | For the sake of clarity and concreteness I've put a minimal example > package > | here: > | > | https://github.com/baptiste/isolve > | > | which builds on my local mac but fails the online r-hub build > | (interestingly, on a linux machine, which also puzzled me about cda's > logs) > | > | https://builder.r-hub.io/status/isolve_1.0.tar.gz-757573eaf5 > b0cb30d8154d7b8f7e2bc7 > | > | Thanks for any advice, > | > | baptiste > | > | > | > | > | > | > | On 20 December 2017 at 02:24, Dirk Eddelbuettel <e...@debian.org> wrote: > | > | > > | > On 19 December 2017 at 13:41, Ralf Stubner wrote: > | > | On 19.12.2017 09:38, Baptiste Auguie wrote: > | > | > Thanks for the pointer to `arma::solve_opts::no_band`, it sounds > like a > | > | > good solution (assuming the compiler will then skip all the parts > | > | > related to banded inversion routines). I've been unable to test it > so > | > | > far; I haven't managed to reproduce the error reported on CRAN on a > | > mac. > | > | > | > | Reproducing this error is not easy. I was able to do so using docker > | > > | > Just work on Windows, or on any R built so that its internal BLAS are > | > used. You can force that via configure at build time. > | > > | > | with > | > | https://github.com/rocker-org/rocker-versioned/blob/master/ > | > r-ver/3.4.3/Dockerfile > | > | as starting point. If you remove lines 30 and 97 (openblas-dev and > | > | --with-blas), you can build a docker image with R included that uses > the > | > | BLAS and LAPACK supplied by R. > | > | > | > | I have given this a try and installing 'cda' in such a image does > indeed > | > | reproduce the error. Unfortunately adding > 'arma::solve_opts::no_band' to > | > | the two places where arma::solve is used did not help in my tests :-( > | > > | > :-( > | > > | > Maybe Arma needs another patch. > | > > | > | > The 'crippled Lapack' macro was useful as a workaround in the past > but > | > | > I'm not sure of its exact mode of operation so I'm reluctant to set > | > | > something to "cripple" the code (does it target only those routines > | > that > | > | > are found missing, or is it more of a blanket switch with no > | > fine-tuning?). > | > | > | > | I think it is a blanket switch that will affect also those methods > that > | > | where already added in the past. So this would be only a temporary > | > | solution, but I think that's what you need right now. > | > | > | > | BTW, setting ARMA_CRIPPLED_LAPACK is more difficult than I thought > since > | > | it is #undefed
Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_
Hi, Sorry I never found the time to put this issue to rest. My cda package has now been removed from CRAN because Armadillo's update on 'banded matrices' broke it on various platforms, and I've had users enquire about the situation. As far as I can tell RcppArmadillo no longer enables the solution of complex linear systems on all platforms (see below). I'm happy to contribute a new test for this to help future-proof this recurring issue, but resolving the underlying issue is beyond me. For the sake of clarity and concreteness I've put a minimal example package here: https://github.com/baptiste/isolve which builds on my local mac but fails the online r-hub build (interestingly, on a linux machine, which also puzzled me about cda's logs) https://builder.r-hub.io/status/isolve_1.0.tar.gz-757573eaf5b0cb30d8154d7b8f7e2bc7 Thanks for any advice, baptiste On 20 December 2017 at 02:24, Dirk Eddelbuettel <e...@debian.org> wrote: > > On 19 December 2017 at 13:41, Ralf Stubner wrote: > | On 19.12.2017 09:38, Baptiste Auguie wrote: > | > Thanks for the pointer to `arma::solve_opts::no_band`, it sounds like a > | > good solution (assuming the compiler will then skip all the parts > | > related to banded inversion routines). I've been unable to test it so > | > far; I haven't managed to reproduce the error reported on CRAN on a > mac. > | > | Reproducing this error is not easy. I was able to do so using docker > > Just work on Windows, or on any R built so that its internal BLAS are > used. You can force that via configure at build time. > > | with > | https://github.com/rocker-org/rocker-versioned/blob/master/ > r-ver/3.4.3/Dockerfile > | as starting point. If you remove lines 30 and 97 (openblas-dev and > | --with-blas), you can build a docker image with R included that uses the > | BLAS and LAPACK supplied by R. > | > | I have given this a try and installing 'cda' in such a image does indeed > | reproduce the error. Unfortunately adding 'arma::solve_opts::no_band' to > | the two places where arma::solve is used did not help in my tests :-( > > :-( > > Maybe Arma needs another patch. > > | > The 'crippled Lapack' macro was useful as a workaround in the past but > | > I'm not sure of its exact mode of operation so I'm reluctant to set > | > something to "cripple" the code (does it target only those routines > that > | > are found missing, or is it more of a blanket switch with no > fine-tuning?). > | > | I think it is a blanket switch that will affect also those methods that > | where already added in the past. So this would be only a temporary > | solution, but I think that's what you need right now. > | > | BTW, setting ARMA_CRIPPLED_LAPACK is more difficult than I thought since > | it is #undefed in the RcppArmadillo-Config. Short of editing that file, > | you can add this to src/Makevars > | > | PKG_CXXFLAGS=-DARMA_CRIPPLED_LAPACK > | -DRcppArmadillo__RcppArmadilloConfigGenerated__h > | > | I hope there is a better way ... > > Set the #define after the #include ? > > RcppArmadillo is just the man in the middle. This is between Baptiste > relying on something that is now always available, and Conrad assuming it > is. > > I think Baptiste will need to decompose all these pieces and rearrange > then. > Or just build his own solve() method based on older Armadillo code? > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] README.Rmd and associated figure files
Hi, Thanks all, that was helpful. I believe it would be worth an extra footnote in Writing R Extensions, as such files are getting more and more widespread in practice. Thanks, Baptiste On 11/09/2017 19:24, "Uwe Ligges" <lig...@statistik.tu-dortmund.de> wrote: > Hi, > > If the images are also used for vignettes or Rd files, you can put them > in the 'vignettes' or 'man/figures' directories. Otherwise, please put > them in the top-level 'tools' directory, or a subdirectory of it. > > Best, > Uwe Ligges > > > On 10.09.2017 00:15, Baptiste Auguie wrote: > >> Hi, >> >> I'm not sure what to do with README.Rmd; I followed Hadley's instructions* >> at http://r-pkgs.had.co.nz/release.html but I'm getting a Warning from >> CRAN >> (missing figure files). Writing R Extensions does not seem to mention this >> particular way of generating a README.md file (and in fact, mildly >> discourages README.md, see https://cran.r-project.org/ >> doc/manuals/r-release/R-exts.html#FOOT2). Here's what I've done: >> >> - top level README.Rmd file with knitr option fig.path = "README-" >> - ^README\.Rmd$ and ^README-.*\.png$ added in .Rbuildignore >> >> as a result, R CMD build creates README.md, and removes the associated >> figures and Rmd source file. However CRAN issues a Warning that the png >> files are missing. >> >> So my next step has been to remove ^README-.*\.png$ from .Rbuildignore, >> but >> that yields a NOTE: "Non-standard files/directories found at top level: >> ..." >> >> I thought perhaps this should go in .Rinstignore, but that yields the same >> NOTE. >> >> What is the proper way to deal with these image files? (pointing fig.path >> to inst/ doesn't seem like an option either, as it will break the paths). >> >> Has there been a recent change in how README.Rmd files are processed? (I >> did not find this step documented in WRE). I looked at a few packages and >> they seem to follow the model recommended in Hadley's r-pkgs resource, so >> presumably it used to work without warnings. >> >> Thanks, >> >> baptiste >> >> >> *: I realise this is not an official documentation; however, from a >> pragmatic point of view, it would seem mutually beneficial if >> recommendations could somehow be kept in sync between this document and >> official CRAN policies. >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> >> [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] README.Rmd and associated figure files
Hi, I'm not sure what to do with README.Rmd; I followed Hadley's instructions* at http://r-pkgs.had.co.nz/release.html but I'm getting a Warning from CRAN (missing figure files). Writing R Extensions does not seem to mention this particular way of generating a README.md file (and in fact, mildly discourages README.md, see https://cran.r-project.org/ doc/manuals/r-release/R-exts.html#FOOT2). Here's what I've done: - top level README.Rmd file with knitr option fig.path = "README-" - ^README\.Rmd$ and ^README-.*\.png$ added in .Rbuildignore as a result, R CMD build creates README.md, and removes the associated figures and Rmd source file. However CRAN issues a Warning that the png files are missing. So my next step has been to remove ^README-.*\.png$ from .Rbuildignore, but that yields a NOTE: "Non-standard files/directories found at top level: ..." I thought perhaps this should go in .Rinstignore, but that yields the same NOTE. What is the proper way to deal with these image files? (pointing fig.path to inst/ doesn't seem like an option either, as it will break the paths). Has there been a recent change in how README.Rmd files are processed? (I did not find this step documented in WRE). I looked at a few packages and they seem to follow the model recommended in Hadley's r-pkgs resource, so presumably it used to work without warnings. Thanks, baptiste *: I realise this is not an official documentation; however, from a pragmatic point of view, it would seem mutually beneficial if recommendations could somehow be kept in sync between this document and official CRAN policies. [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] documentation / warning when passing a vector as lower/upper bound in stats::integrate()
Dear R-dev list, I wonder if stats::integrate shouldn't warn the user when a numeric vector of length > 1 is passed as lower or upper bounds. If a vector is passed, only the first value is used and the others are silently ignored: integrate(sin, lower=0, upper=pi) integrate(sin, lower=0:10, upper=pi) ?integrate doesn't appear to mention explicitly that the function is not vectorised over those arguments. It's probably not a common mistake, but it can have unfortunate consequences in the iterative calculation of multiple integrals. Someone was puzzled by this today (http://stackoverflow.com/q/36275909/471093) and it wasn't immediately obvious what had led to incorrect results (and worse, it could have gone unnoticed). Best regards, baptiste [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NEWS.md support on CRAN
John MacFarlane, the author of Pandoc, has been working on a project ( http://commonmark.org/) to define a standard reference for Markdown*. There are already two reference implementations, one in javascript, the other in C: https://github.com/jgm/cmark Regards, baptiste * There was some initial controversy with the original author of markdown, but in the long term it's probably one of the more reliable sources to follow. On 24 May 2015 at 12:00, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 23/05/2015 9:25 AM, Gábor Csárdi wrote: On Sat, May 23, 2015 at 8:14 AM, Duncan Murdoch murdoch.dun...@gmail.com mailto:murdoch.dun...@gmail.com wrote: [...] I think the harder problem is display. CRAN can run pandoc, but can users who install the package from source? I would expect some obscure platforms (like Windows ;-) would not have it available. [...] I don't think pandoc is the best way to go with NEWS.md (and README.md, actually). I would be surprised if many package maintainer built their NEWS/README files with pandoc. They just look at them at GitHub (or another similar service). GitHub has API for building HTML from MarkDown: https://developer.github.com/v3/markdown/ It can build GitHub-flavored MarkDown, in which case you get links to GitHub issues, etc. or just plain MarkDown, like a GitHub README. If you don't want to rely on their service, then there are a multitude of lightweight MarkDown parsers available, e.g. https://github.com/markdown-it/markdown-it is a good one IMO. I wouldn't want R builds to depend on GitHub, so this sounds more interesting. I took a look at that website, and it looks problematic to me: the parser appears to be written in Javascript, and the install instructions (using npm and bower, whatever those are) depend on some unstated prerequisites. In principle there's no reason not to allow R builds to depend on these things, but adding a dependency like that implies so much testing that I can't imagine anyone who could do it would want to. It's likely that a suitable parser could be written in some combination of C and R -- Markdown is not a complicated language. Pandoc is great for vignettes, but you don't need its full power for READMEs and especially not for NEWS files. In fact most NEWS.md files look good as text. But we do need something, and it needs to be essentially universally available, or small enough to include in the R sources. I think R should eventually support Markdown as an acceptable language for documentation (including NEWS.md, and also help files for functions), but I think the effort required to do it now is too much. Duncan Murdoch Gabor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NEWS.md support on CRAN
On 24 May 2015 at 14:01, Duncan Murdoch murdoch.dun...@gmail.com wrote: It sounds as though there are at least two possibilities for parsers that could be included in R: Sundown and commonmark. Sundown is in fact deprecated, https://github.com/vmg/sundown/commit/37728fb2d7137ff7c37d0a474cb827a8d6d846d8 in favor of commonmark which will likely become the standard tool for StackExchange, github, Reddit, among others. The markdown package has been somewhat superseded by rmarkdown, based on Pandoc. However commonmark would be easier to include (no dependency on Haskell), much faster, and more memory efficient. The good folks at Rstudio will probably have considered this option, and may even have started working on R bindings. Commonmark seems to use an intermediate Abstract Syntax Tree, which could be also useful for custom processing. Regards, baptiste [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r wiki
One small technical issue currently limiting the deployment of true reproducible wikis based on knitr + github-markdown is the lack of reverse synchronisation between the rendered output (markdown), edited online, and the original Rmd source. It think the combination of wiki features + reproducible source code has great potential for community-driven documentation (even for individual packages), but this relatively new use-case for reproducible documents may highlight a limitation in knitr's current framework [1]. On a more general note, and considering the positive sentiment toward github in the R community, it might be a good time to register a semi-official R-project organisation to regroup such initiatives, https://help.github.com/articles/creating-a-new-organization-account In the long-run, it would be nice to centralise some valuable resources that have appeared independently over the years, such as the R wiki, the R graph gallery [?], the unofficial CRAN mirror [2], the unofficial r-source mirror [3], and probably many others I forget or don't know about. Regards, baptiste [1] related discussion here: https://github.com/yihui/knitr/issues/536 [?] http://addictedtor.free.fr/graphiques/ [2] https://github.com/cran, https://github.com/metacran/ [3] https://github.com/wch/r-source On 9 September 2014 10:48, Martin Maechler maech...@stat.math.ethz.ch wrote: Philippe Grosjean phgrosj...@sciviews.org on Tue, 9 Sep 2014 08:45:14 +0200 writes: Yihui and Gábor, I agree with you, and I also think that using Travis CI would be very nice. However, there are hundreds of page on the R wiki to migrate… and syntax is a little bit different than Markdown. Of course, a solution would be to start again from scratch, but I think that those who have contributed to the R Wiki deserve more respect. Any suggestion, or idea about this? (and we have seen more on this thread ..) As one contributor to the former wiki and maintainer of the good olde mailing lists, I completely agree (with Yihui and Gábor and you) that it's best to move it over to an infrastructure which takes care of authentication of legitimate users and protection from thieves burglers, spammers, and the like. Markdown is definitely much better for R users (given knittr and Rmd ..), and github is currently the place to host -- and once it ceases to be that, markdown will be easier to migrate from. Martin Best, Philippe On 08 Sep 2014, at 23:12, Gábor Csárdi csardi.ga...@gmail.com wrote: I second this suggestion. One possible complication I see is that if you would like to run the R code (to display its output for example), then AFAIK you cannot simply use Jekyll on Github's side, but would need some additional infrastructure. It might be possible to use Travis (or some other) CI for it, and avoid installing additional software and/or servers, but anyway, this requires some care and effort. If you don't want to run the code, then it is very easy, apart from the (one-time) migration cost. Best, Gabor On Mon, Sep 8, 2014 at 4:15 PM, Yihui Xie x...@yihui.name wrote: I want to make a humble suggestion: migrate the wiki to Github, and build the pages using Jekyll+Markdown. That way, I think it will attract more volunteers. Simply look how many pull requests that Hadley has got for his up-coming book hosted on Github (http://adv-r.had.co.nz): https://github.com/hadley/adv-r/pulls I have had the experience of maintaining web servers and different wiki/CMS systems (including Dokuwiki -- I have even written a PHP plugin for it), and eventually I found I could not afford the time on the job of a system admin. Now I never do that again, and I just focus on maintaining the content. Let the professionals do the hosting and compilation service, and my life has become so much better (no more worries about security holes and attacks). Regards, Yihui -- Yihui Xie xieyi...@gmail.com Web: http://yihui.name On Mon, Sep 8, 2014 at 12:10 PM, Philippe GROSJEAN philippe.grosj...@umons.ac.be wrote: Uwe and all, I have problems with the R wiki engine. It seems that there is a systematic attack of the R wiki site that produces an overconsumption of the server's CPU, and consequently, my provider did shutdown the whole SciViews.org web site. Now, it is a bad time for me to work on this (very busy with exams + Master and PhD theses). I am currently looking for an expert in CMS to look at the problem. I don't know when I will be able to solve this and reopen the R Wiki. Best, Philippe
Re: [Rd] Where to put package vignettes
Hi, You should take the following steps: 1) upgrade R, 2) specify VignetteBuilder: knitr in your DESCRIPTION file, 3) check how other CRAN packages using knitr do it (e.g. knitr itself). No makefile is needed, that was a temporary workaround, now irrelevant. HTH, baptiste On 20 February 2014 11:45, Søren Højsgaard sor...@math.aau.dk wrote: Guillermino, Sorry but I've never made it beyond Sweave in connection with R packages; we will have to wait for more insight from others. Søren -Original Message- From: guillermo.vi...@uv.es [mailto:guillermo.vi...@uv.es] Sent: 20. februar 2014 15:43 To: Søren Højsgaard Cc: r-devel@r-project.org Subject: RE: [Rd] Where to put package vignettes Dear Søren, Thank you very much for your answer, it solved my problem and now my package can be installed both on Linux and Windows and the vignette is available in both systems. I put the vignette in /vignettes. However, unfortunately my problems have not ended here. As mentioned, my vignette is built with knitr and with the following commands: 1) R CMD check foo 2) R CMD build foo 3) R CMD INSTALL foo_xxx.tar.gz the vignette is built with Sweave! I have read in http://yihui.name/knitr/demo/vignette/ that in that case, a Makefile should be incorporated. I have incorporated in /inst/doc the makefile from https://github.com/yihui/knitr/blob/7eb34104/inst/doc/Makefile however, my vignette is still built with Sweave. I use R 2.15.2. How can I fix this performance?. Thank you very much again. Best regards, Guillermo My understanding is this: 1) Put vignettes files (.Rnw files) in the /vignettes subdirectory. 2) Build the package foo with R CMD build foo. 3) Install the package with R CMD INSTALL foo_xxx.tar.gz Then the vignettes will be available. However you can also install the package with R CMD INSTALL foo, but then the vignettes will *not* be available (because it is in the build process that the vignettes go from /vignettes to /inst/doc) Regards Søren -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of guillermo.vi...@uv.es Sent: 20. februar 2014 12:19 To: r-devel@r-project.org Subject: [Rd] Where to put package vignettes Dear R-devel list, My name is Guillermo Vinué. I have created an R package that includes a vignette. Earlier on, to test my package, I tried to install it both in Linux and Windows and it worked. My vignette was in /inst/doc. Now, I have finished for good and before submitting my package to CRAN I've tried to install it again first in Linux and then in Windows (I removed that first installation some time ago). My package was succesfully installed in Linux (Fedora 18 and R 2.15.2) and the vignette was available. However, when trying to install it in Windows (R 3.0.2), unfortunately the vignette didn't appear. My vignette is build with knitr. In fact, if I first install the package on Windows, the vignette is accesible, but then in Linux, not. I have read that as from R 2.14.0 the preferred location for the Sweave sources is the subdirectory vignettes of the source packages, but for compatibility with earlier versions of R, vignette sources will be looked for in inst/doc if vignettes does not exist. Where do I have to put my vignette so that it could be available with any installation and which files (.Rnw or .pdf) should be included?. I hope you can clarify my doubts. I have seen the collection of prior postings to the list, but I have not found a specifical answer to my doubts . Thank you very much in advance. Best regards, Guillermo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package checking: verifying plots
Hi, Winston Chang designed the vtest package for a similar purpose, https://github.com/wch/ggplot2/wiki/Visual-test-system https://github.com/wch/vtest I don't know if / how well it works outside the ggplot2 framework, but it's pretty slick. HTH, baptiste On 22 January 2014 11:35, Therneau, Terry M., Ph.D. thern...@mayo.eduwrote: I pride myself on having an extensive and comprehensive test suite for the survival package. However, I don't have a good procedure for testing the plotting routines. (Forget good, I don't even have a third-rate procedure for this.) This was brought home with the latest release; within 24 hours I got a note about a problem. They y-axis range for a plot was calculated incorrectly, giving no warning or error, just a graph with 2/3 of the data outside the plot window. It was a side effect of a change for another reason, and of course I had checked out that consequence thoroughly. Any good ideas for this issue? Terry Therneau __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] formals() adds 0 to complex function arguments
Dear list,
I'm facing an issue with the automated documentation of a function using
roxygen2. The function has a complex-valued default argument, which is
picked up by roxygen2 using formals() to generate the corresponding Usage
section of the Rd file. Unfortunately, it appears that formals() reformats
complex numbers. Consider the example below,
test - function(a = 1+2i){}
args(test)
function (a = 1 + (0+2i))
NULL
formals(test)
$a
1 + (0+2i)
As a result, R CMD check issues a warning that my Rd file is inconsistent
between Code and Docs. Redefining the function with this syntax (a = 1 +
(0+2i)) doesn't help, as a new 0 gets added to become 1 + (0 + (0+2i)).
Is this reformatting necessary?
Regards,
baptiste
sessionInfo()
R Under development (unstable) (2013-11-25 r64299)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_NZ.UTF-8/en_NZ.UTF-8/en_NZ.UTF-8/C/en_NZ.UTF-8/en_NZ.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.1.0
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] formals() adds 0 to complex function arguments
Thank you Peter and Duncan, for the explanation and discussion. As for a
workaround, I think it is more readable to define,
test - function(a = complex(real=1, imaginary=2)){}
Best regards,
baptiste
On 19 January 2014 18:45, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 14-01-19 4:16 PM, peter dalgaard wrote:
It's not formals() that is doing you in. Rather, it is a conspiration
between two things:
(a) R always displays complex constants as x+yi, even if x is zero and
(b) there really is no way to specify complex constants with non-zero real
part, i.e. 1+2i is a sum of a real and and imaginary complex constant. You
can see the effect already at
quote(1+2i)
1 + (0+2i)
q - quote(1+2i)
q[[1]]
`+`
q[[2]]
[1] 1
q[[3]]
[1] 0+2i
str(q)
language 1 + (0+2i)
str(q[[3]])
cplx 0+2i
Someone might want to fix this by implementing a full syntax for complex
constants, but meanwhile, I think a passable workaround could be
That might be nice to do. Not sure if it's easy or hard...
formals(test)$a - 1+2i
args(test)
function (a = 1+2i)
NULL
test
function (a = 1+2i)
{
}
Or maybe, less sneaky
Cplx_1plus2i - 1+2i
test - function(a = Cplx_1plus2i){}
Less sneaky, but a tiny bit different due to scoping issues: if the
function happens to assign something to a local variable Cplx_1plus2i
before evaluating a, the local variable will be used rather than the global
one.
Duncan Murdoch
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Straight-quotes for usage and examples sections in PDF docs?
There's a trivial variation named Inconsolata-dz, http://nodnod.net/2009/feb/12/adding-straight-single-and-double-quotes-inconsola/ which I've used happily with XeTeX; maybe R can use it in place of the original if you rename it Inconsolata, but that would presumably be against the font licence. baptiste On 8 August 2012 04:13, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: On 06/08/12 23:01, Mike Lawrence wrote: Is there any way to ensure that quotation marks are left as straight quotes and not converted to curly quotes in the \usage and \examples sections when the pdf versions of the docs are created? They are not converted ... so there cannot be a way. In standard terminology 'quotation marks' are ASCII/Unicode , and that is what is in the PDF files (in so far as we can guess what you mean without an explicit example). I have no idea what 'straight quotes' and 'curly quotes' are in your lexicon, but how even ASCII characters are rendered depends on the fonts used. The R pdf manuals by default use inconsolata, where quotation marks are somewhat italic. We knew that when selecting inconsolata, but it was the best compromise of the feasible choices. Chose something else it you prefer a different compromise. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Please explain your workflow from R code - package - R code - package
+1 for roxygen2, lazycoolness oblige. An alternative that has not been mentioned is inlinedocs, http://inlinedocs.r-forge.r-project.org/ I don't use it myself, but it might appeal to your workflow. baptiste On 10 September 2011 06:41, Hadley Wickham had...@rice.edu wrote: | In other languages, I've seen to write the documentation inside the | code files and then post-process to make the documentation. Is there | a similar thing for R, to unify the R code development and | documentation/package-making process? You can also follow the cool kids who these days tie some of this together using roxygen. It's not the cool kids who are doing this, it's the lazy kids ;) Roxygen(2) does remove a considerable amount of replication between code and documentation (e.g. replicating function usage in two places), and the close proximity between code and documentation does make it easier to remember to update your documentation when the code changes. Roxygen2 adds a few other tools for reducing duplication like templates, the ability to inherit parameter documentation from other function, and the family tag to automatically add seealso references between all members of a related family of functions. These are things that are painful to do by hand and add a significance maintenance burden. I agree that there's no silver bullet, but good tools certainly can make life easier. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] one way to solve bad looking density plots in postscript
Hi,
I was going to suggest panel.last to redraw a box around the image,
but for some reason it does not seem to come after the image neither
(this is perhaps to be expected from the note in ?plot.default).
plot(1,1, panel.last={box(lwd=50, col=#FF)})
image(volcano, panel.last={box(lwd=50, col=#FF)})
sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_NZ.UTF-8/en_NZ.UTF-8/C/C/en_NZ.UTF-8/en_NZ.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets grid
methods base
other attached packages:
[1] ggplot2_0.8.9 proto_0.3-9.2 reshape_0.8.4 plyr_1.6
loaded via a namespace (and not attached):
[1] tools_2.13.1
Best,
baptiste
On 4 August 2011 00:23, Michael Lachmann lachm...@eva.mpg.de wrote:
Some more digging.
1.
The following code will fix density plots for me:
---
.ps.prolog=grDevices:::.ps.prolog
i=grep(/p2,.ps.prolog)
.ps.prolog[i] = /p2 { bg gsave fill grestore 0.001 setlinewidth stroke
newpath } def
---
2.
It seems that it doesn't matter where in image.default() the box is drawn,
before or after
.Internal(image(as.double(x), as.double(y), as.integer(zi),
col))
is called, the resulting eps has the box in front.
Michael
On 3 Aug 2011, at 9:25AM, Michael Lachmann wrote:
When R generates density plots and these are exported to postscript(
a=matrix(1:100,10,10);image(a,col=rainbow(100);dev.copy2eps(file=image.eps)
)
The result often looks bad when rendered on screen. The help page states
that this is because programs use anti-aliasing. That seems to be true -
turning off anti-aliasing for gs (-dGraphicsAlphaBits=1) of in OSX's preview
makes the plots look really smooth, but makes everything else look bad
(personal opinion..). The plots do look ok in acrobat reader. I think it
would be much better if R corrected this problem - even if it is not totally
R's fault.
It seems that using the option useRaster=T in image() solved this problem,
but creates other problems for OSX's Preview (it seems that OSX's preview
first anti-aliases the raster, and then scales it... creating a mess).
Density plots produced by gnuplot do not seem to have this problem:
---
set pm3d map
set pm3d at b
set ticslevel 0.8
set isosample 40,40
set output gtest.eps
set term postscript eps color
splot [-3:3] [-3:3] x*x*exp(-x*x)*y*y*exp(-y*y)
--
But I haven't figured out why that is. Maybe someone who understands more
about postscript can. Maybe it is something about the order that the
rectangles are rendered? I did notice that rectangles are plotted with
slightly different sizes - 50, 51, 50, 51 and so on. Is that it?
After a lot of experimentation, I found that a small change in the eps file
can correct the output.
If in the eps file produced above, you change the line
/p2 { gsave bg fill grestore newpath } def
with
/p2 { bg gsave fill grestore stroke newpath } def
and add
0.0001 setlinewidth
two lines before the next p2 - i.e. before we start plotting the rectangles
of the image:
change:
/bg { 1 0 0 setrgb } def
59.04 73.44 41.47 37.15 r p2
to:
0.0001 setlinewidth
/bg { 1 0 0 setrgb } def
59.04 73.44 41.47 37.15 r p2
What this does is plot the outline of each rectangle in addition to filling
it.
The page at:
http://pages.uoregon.edu/noeckel/MathematicaGraphics.html#ExportGraphics
Claims that Mathematica also has/had this problem, and how it can be solved
there (sadly, I don't know enough Mathematica to understand that solution)
The output of the image would look even better if the axes were drawn AFTER
the density rectangles, not before. That would cause the rectangles not to
overwrite part of the lines of the axes. But that is probably a change in
the image() routine, not in the postscript driver
Thanks for listening,
Michael Lachmann
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package encoding warning
Thank you -- since I don't understand the relevant discussion in Writing R Extensions, I have now removed Encoding: UTF-8 from the DESCRIPTION file; I also made sure that my surname and all text was in plain ASCII. Best regards, baptiste On 30 July 2011 17:29, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: On Sat, 30 Jul 2011, baptiste auguie wrote: Dear list, I'd like to get rid off a couple of warnings that have appeared in checking my package on CRAN (I did not find them on my local machine before submission). What puzzles me is that different platforms return different warnings, only one of which I recognise as my obvious mistake. The check results are at http://cran.r-project.org/web/checks/check_results_planar.html r-devel-linux-x86_64-gcc-fedora complains about unused variable in c++ code; this I understand as my mistake, I'll fix it. r-patched-windows-ix86+x86_64 is happy, no warning r-release-macosx-ix86 checking examples ... WARNING checking a package with encoding 'UTF-8' in an ASCII locale This one really puzzles me: I have a Encoding: UTF-8 directive in DESCRIPTION, precisely because I thought it would take care of encoding issues such as with my surname. Your 'thought' was unfounded: please re-read the relevant sections of the R manuals. What does this mean, and what should I do about it? It means that your package cannot be checked correctly in that locale. You can avoid it by following the recommendations to use only ASCII, as you did in this message (or at least, it was ASCII by the time it reached me). Similarly, r-oldrel-macosx-ix86 checking whether package 'planar' can be installed ... WARNING Found the following significant warnings: Warning: 'DESCRIPTION' file has 'Encoding' field and re-encoding is not possible has me perplexed. Same: non-ASCII UTF-8 strings cannot be represented in the C (aka ASCII) locale. Now, I think it is a mistake to be checking in the C locale on Mac OS X as no end user will deliberately be using it, but that is the default for batch use on many OSes. *But* the same encoding issues for European names will occur in, say, the Japanese Windows locale. Best regards, baptiste __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package encoding warning
Dear list, I'd like to get rid off a couple of warnings that have appeared in checking my package on CRAN (I did not find them on my local machine before submission). What puzzles me is that different platforms return different warnings, only one of which I recognise as my obvious mistake. The check results are at http://cran.r-project.org/web/checks/check_results_planar.html r-devel-linux-x86_64-gcc-fedora complains about unused variable in c++ code; this I understand as my mistake, I'll fix it. r-patched-windows-ix86+x86_64 is happy, no warning r-release-macosx-ix86 checking examples ... WARNING checking a package with encoding 'UTF-8' in an ASCII locale This one really puzzles me: I have a Encoding: UTF-8 directive in DESCRIPTION, precisely because I thought it would take care of encoding issues such as with my surname. What does this mean, and what should I do about it? Similarly, r-oldrel-macosx-ix86 checking whether package 'planar' can be installed ... WARNING Found the following significant warnings: Warning: 'DESCRIPTION' file has 'Encoding' field and re-encoding is not possible has me perplexed. Best regards, baptiste __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
Hi,
On 5 May 2011 02:56, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 04/05/2011 10:40 AM, Ravi Varadhan wrote:
I too would like this (being an Indian!).
Here is an example that came up just yesterday with regards to solving a
quadrature problem using the cubature package. The adaptIntegrate
function does not allow additional arguments via ...
Uwe suggested a work around, but `Curry' would solve it nicely (and it
also tastes better!):
Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}
require(cubature)
f- function(x, a) cos(2*pi*x*a) # a simple test function
# this works
a- 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
Two objections:
1. I don't see how that is preferable to
adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)
In this particular case I don't think it is. The reason I proposed it
yesterday for the cubature example was that in some cases it can make
the code more concise and clearer in my opinion. This is the case when
you override a considerable number of arguments in a function.
Consider this,
read.table2 = Curry(read.table, header = TRUE, na.strings = ,
colClasses = numeric, nrows = 23)
vs
read.table2 = function(..., header = TRUE, na.strings = ,
colClasses = numeric, nrows = 23)
{
read.table(header = header, na.strings = na.strings,
colClasses = colClasses, nrows = nrows, ...)
}
Whether or not this should be called curry, I have no idea. In any
case it seems like a useful function to have in a base package,
regardless of its implementation details.
baptiste
2. There seems to be confusion about what currying means. The Wikipedia
page http://en.wikipedia.org/wiki/Currying indicates that the function
Curry() defined above is really doing partial function application, not
currying. I'm in no position to judge whether Byron got it right or
Wikipedia did, but this suggests to me that the name Curry is
inappropriate, since at least some people who know what currying is would
not guess that it does what it does.
Duncan Murdoch
Best,
Ravi.
---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns
Hopkins University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er,
function.
I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?
Hadley
On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellisbyron.el...@gmail.com wrote:
Hi all (especially R-core) I suppose,
With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:
Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }
This comes in really handy when using say, heatmap():
heatmap(mydata,hclustfun=Curry(hclust,method=average))
or other functions where there are ... arguments, but it's not clear
where they should end up.
--
Byron Ellis (byron.el...@gmail.com)
Oook -- The Librarian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid stringHeight
Hi,
I see, thanks. I incorrectly thought it used to produce the same
output in the past.
As a workaround I will wrap all strings in expression() before
evaluating the grobHeight; otherwise the calculated layout can clip
portions of the text.
Thanks,
baptiste
On 2 May 2011 15:00, Paul Murrell p.murr...@auckland.ac.nz wrote:
Hi
This is a basic feature of both strheight() and stringHeight(). They both
ignore any descenders in the text. I cannot remember why it was done this
way originally. The future solution is probably to add an argument that
allows descenders to be included in text height.
Plotmath works on bounding boxes so its behaviour is different, but of
course that has its own problems because there is no sense of baseline for
expressions.
Paul
On 27/04/2011 11:06 a.m., baptiste auguie wrote:
Dear all,
I'm puzzled by the behavior of stringHeight in the grid package.
Consider the following test,
library(grid)
test- function(lab=dog, ...){
g1- textGrob(lab)
g2- rectGrob(height=grobHeight(g1), width=grobWidth(g1))
gg- gTree(children=gList(g1,g2), ...)
print(c(height:, convertUnit(stringHeight(lab), mm, y)))
grid.draw(gg)
}
grid.newpage()
test()
test(expression(dog), vp=viewport(x=0.6))
## notice how the dog's tail is being cut off, where
## expression yields a snug cage
grid.newpage()
test(aoc)
test(expression(aoc), vp=viewport(x=0.6))
It appears that stringHeight correctly calculates the height for an
expression, but not for a basic string. I think it used to produce the
same output for both.
Best regards,
baptiste
sessionInfo()
R version 2.13.0 alpha (2011-03-27 r55076)
Platform: i386-apple-darwin9.8.0 (32-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets grid methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid stringHeight
On 27 April 2011 11:06, baptiste auguie baptiste.aug...@googlemail.com wrote:
Dear all,
I'm puzzled by the behavior of stringHeight in the grid package.
Consider the following test,
library(grid)
test - function(lab=dog, ...){
g1 - textGrob(lab)
g2 - rectGrob(height=grobHeight(g1), width=grobWidth(g1))
gg - gTree(children=gList(g1,g2), ...)
print(c(height:, convertUnit(stringHeight(lab), mm, y)))
grid.draw(gg)
}
grid.newpage()
test()
test(expression(dog), vp=viewport(x=0.6))
## notice how the dog's tail is being cut off, where
## expression yields a snug cage
grid.newpage()
test(aoc)
test(expression(aoc), vp=viewport(x=0.6))
It appears that stringHeight correctly calculates the height for an
expression, but not for a basic string. I think it used to produce the
same output for both.
Best regards,
baptiste
sessionInfo()
R version 2.13.0 alpha (2011-03-27 r55076)
Platform: i386-apple-darwin9.8.0 (32-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets grid methods
[8] base
I have now filed a bug report for this issue, though I could only
confirm it on one operating system.
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14566
Best regards,
baptiste
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] grid stringHeight
Dear all,
I'm puzzled by the behavior of stringHeight in the grid package.
Consider the following test,
library(grid)
test - function(lab=dog, ...){
g1 - textGrob(lab)
g2 - rectGrob(height=grobHeight(g1), width=grobWidth(g1))
gg - gTree(children=gList(g1,g2), ...)
print(c(height:, convertUnit(stringHeight(lab), mm, y)))
grid.draw(gg)
}
grid.newpage()
test()
test(expression(dog), vp=viewport(x=0.6))
## notice how the dog's tail is being cut off, where
## expression yields a snug cage
grid.newpage()
test(aoc)
test(expression(aoc), vp=viewport(x=0.6))
It appears that stringHeight correctly calculates the height for an
expression, but not for a basic string. I think it used to produce the
same output for both.
Best regards,
baptiste
sessionInfo()
R version 2.13.0 alpha (2011-03-27 r55076)
Platform: i386-apple-darwin9.8.0 (32-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets grid methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] gList and gTree methods of grid::grobX
Dear all,
In an attempt to draw fill patterns in grid graphics, I have
encountered a behavior of grobX that I cannot understand from the
documentation. Consider this,
library(grid)
## gTree
g1 - gTree(children=gList(
rectGrob(0.5,0.5, width=unit(0.8,npc),
height=unit(2,cm)),
circleGrob(r=0.3)), vp=viewport(0.5,0.5))
## gList
g1 - gList(rectGrob(0.5,0.5, width=unit(0.8,npc),
height=unit(2,cm)),
circleGrob(r=0.3))
## loop over angles to map the boundary
gtheta - function(g, theta){
sapply(theta, function(.t){
gx - convertX(grobX(g, .t), npc)
gy - convertY(grobY(g, .t), npc)
c(gx,gy)
})
}
angles - seq(0,360,by=30)
p1 - gtheta(g1, angles)
grid.newpage()
grid.draw(g1)
grid.points(p1[1,],p1[2,], gp=gpar(cex=0.2),
default.units=npc)
If I'm not mistaken, neither gList nor gTree seem to produce the
documented behavior,
If the grob describes multiple shapes, the boundary value will either
correspond to the edge of a bounding box around all of the shapes
described by the grob (for multiple rectangles, circles, xsplines, or
text), or to a convex hull around all vertices of all shapes described
by the grob (for multiple polygons, points, lines, polylines, and
segments).
with gList, I observe that the boundary is only considered for the
first shape, whilst gTree ignores all children altogether.
It works fine for single shapes (e.g. g1 = circleGrob(r=0.3)).
The same behavior is observed with quartz(), pdf() and png().
Sincerely,
baptiste
sessionInfo()
R version 2.12.1 Patched (2010-12-30 r53895)
Platform: i386-apple-darwin9.8.0 (32-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] grid stats graphics grDevices utils datasets
methods base
loaded via a namespace (and not attached):
[1] tools_2.12.1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gList and gTree methods of grid::grobX
Hi,
Thanks for the clarification. Perhaps something along those lines
could be added to the help page.
Regards,
baptiste
On 15 February 2011 19:51, Paul Murrell p...@stat.auckland.ac.nz wrote:
Hi
baptiste auguie wrote:
Dear all,
In an attempt to draw fill patterns in grid graphics, I have
encountered a behavior of grobX that I cannot understand from the
documentation. Consider this,
library(grid)
## gTree
g1 - gTree(children=gList(
rectGrob(0.5,0.5, width=unit(0.8,npc),
height=unit(2,cm)),
circleGrob(r=0.3)), vp=viewport(0.5,0.5))
## gList
g1 - gList(rectGrob(0.5,0.5, width=unit(0.8,npc),
height=unit(2,cm)),
circleGrob(r=0.3))
## loop over angles to map the boundary
gtheta - function(g, theta){
sapply(theta, function(.t){
gx - convertX(grobX(g, .t), npc)
gy - convertY(grobY(g, .t), npc)
c(gx,gy)
})
}
angles - seq(0,360,by=30)
p1 - gtheta(g1, angles)
grid.newpage()
grid.draw(g1)
grid.points(p1[1,],p1[2,], gp=gpar(cex=0.2),
default.units=npc)
If I'm not mistaken, neither gList nor gTree seem to produce the
documented behavior,
If the grob describes multiple shapes, the boundary value will either
correspond to the edge of a bounding box around all of the shapes
described by the grob (for multiple rectangles, circles, xsplines, or
text), or to a convex hull around all vertices of all shapes described
by the grob (for multiple polygons, points, lines, polylines, and
segments).
That description is referring to a single *grob* object that draws multiple
shapes, something like ...
g1 - circleGrob(x=1:3/4, y=1:3/4, r=.1)
... in your example.
The behaviour of gTrees is pretty much undefined, but the user is free to
slap a class on the gTree and write their own xDetails() and yDetails()
methods to achieve the outcome that they want. I have wondered about
supplying a default that makes some sort of union of the boundaries of the
children of a gTree, but have not yet implemented that.
The gList case has been explicitly coded to produce the result from the last
object in the gList, but I cannot recall why I ever thought that might be a
good default. Again, making the gList the children of a gTree with a
specific class provides the opportunity to control what grobX() and grobY()
return for yourself.
Paul
with gList, I observe that the boundary is only considered for the
first shape, whilst gTree ignores all children altogether.
It works fine for single shapes (e.g. g1 = circleGrob(r=0.3)).
The same behavior is observed with quartz(), pdf() and png().
Sincerely,
baptiste
sessionInfo()
R version 2.12.1 Patched (2010-12-30 r53895)
Platform: i386-apple-darwin9.8.0 (32-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] grid stats graphics grDevices utils datasets
methods base
loaded via a namespace (and not attached):
[1] tools_2.12.1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
On 14 February 2011 18:26, Ben Bolker bbol...@gmail.com wrote: Paul Murrell p.murrell at auckland.ac.nz writes: Hi On 12/02/2011 7:22 p.m., Michael Sumner wrote: Hello, that appears to have fixed it. Thank you very much. I can now repeat the reported workflow and the image appears on the fifth (and subsequent) calls. Great. Thanks for checking. Paul That's great. Just a little bump: I would encourage Simon (in his copious spare time), or other interested members of R-core, to decide on a good name for the argument (as a reminder, I prefer 'method=c(raster,image)'). Furthermore, I would strongly encourage that raster be made the default behavior for the development release of R ... Seconded. Also, I haven't had any comment on my suggestion, so I was wondering if Grid graphics are meant to be left out of this question. Having each package that uses Grid graphics implement its own version of imageGrob() (e.g. lattice, ggplot2, RGraphics, gridExtra) with optional use of raster format is probably not a very desirable situation. Best regards, baptiste cheers Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Dear all, Back when grid.raster() was introduced, it was suggested that perhaps grid.rect() could use grid.raster() in case of even spacing. The response at the time was that it would be best to keep the two functions separate at a lower level, that is grid.rect() and grid.raster(), but perhaps a new function grid.image() could be proposed at a higher level with the two possible backends. If this is done in grid graphics, perhaps the same convention could be used for base graphics: image() would be high level with the backend option, and a new function (tiles(), perhaps?) would implement the current behavior of image(). In any case, it would be nice to have a unified scheme to switch between tiles and raster; currently lattice (panl.levelplot.raster) and a few other packages all do it separately. Best wishes, baptiste On 9 February 2011 23:29, Ben Bolker bbol...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-02-09 03:09 PM, Henrik Bengtsson wrote: On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek simon.urba...@r-project.org wrote: On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote: On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek simon.urba...@r-project.org wrote: Ben, I have committed something analogous to R-devel (your rotation code was not unlike mine, I replicated the color handling from R internals to be consistent, I fixed the drawing limits and added a check for x/y conformance). Note that useRaster can only be used when x, y form a regular grid. Although I tried a lot of corner cases (requiring quite a few fixes), I'm sure I did not test all of them, so volunteers please give it a go and compare it with non-raster output. The only thing I'm not quite happy about is the argument name: useRaster. Personally, I hate camel case in R (it has crept in more recently making it horribly inconsistent) so please feel free to suggest a better name ;). It.is.spelled.camelCase. Fortunately not in English ;) What about style=c(image, raster)? This allows for future extensions too. Hmm.. it's not really a style - the output doesn't change (ideally) - it's more of a back-end specification .. also we already have oldstyle argument in image() adding to the confusion ... flavor=c(image, raster) renderer=c(image, raster) backend=c(image, raster) ... Thanks Simon! (Any reports on the SDI Windows raster rendering issue, or do we need a warning/workaround there?) I like backend, or possibly method One minor consideration: if raster eventually becomes the default (as I hope it will), there would need to be some internal logic that drops back to image if the user specifies uneven spacing and doesn't explicitly specify the 'backend/method' parameter ... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m =/da6 -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0.5 != integrate(dnorm,0,20000) = 0
Hi, I was recently given some interesting tips on a similar issue, see R-help puzzle with integrate over infinite range http://www.r-help.com/list/85/713882.html Maybe fails can be a bit misleading here (fails to produce the actual result vs. returning an error message). As a result of this previous discussion, I don't think it would be possible to return an error: as far as the algorithm knows, the value it calculated is 0 because the integrand was 0 everywhere. To know better, the program would need to sample the integrand at more points (which can be achieved by changing the interval, or better, by setting the tolerance to a lower value). baptiste On 7 December 2010 00:32, Spencer Graves spencer.gra...@structuremonitoring.com wrote: Hello: The example integrate(dnorm,0,2) says it fails on many systems. I just got 0 from it, when I should have gotten either an error or something close to 0.5. I got this with R 2.12.0 under both Windows Vista_x64 and Linux (Fedora 13); see the results from Windows below. I thought you might want to know. Thanks for all your work in creating and maintaining R. Best Wishes, Spencer Graves ### integrate(dnorm,0,2) ## fails on many systems 0 with absolute error 0 sessionInfo() R version 2.12.0 (2010-10-15) Platform: i386-pc-mingw32/i386 (32-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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Roxygen: @example tag does not work for me
Hi,
I think you could achieve this using the brew package. Define a
function that reads your external example file, and have brew insert
the resulting string in your script, which can then be processed by
roxygen.
I'm curious to hear other suggestions, but I doubt it could work
out-of-the-box like you intended.
HTH,
baptiste
On 4 November 2010 01:50, Janko Thyson janko.thy...@ku-eichstaett.de wrote:
Dear list,
somehow I can't get the Roxygen tag @example to work for me.
My Roxygen-Header of a script containing, say, a function looks like this:
#' My header
#'
#' My description
#'
#' @param a Blabla.
#' @param b Blabla.
#' @return \code{TRUE}.
#' @callGraphPrimitives
#' @references
#' \url{http://www.something.org /}
#' @author Janko Thyson \email{my.email@@something.com}
#' @example tests/foo.R
#' @seealso \code{\link{some.other.function}}
Foo - function(a, b){cat(Doing nothing useful.)}
I thought that @example would take the R code in tests/foo.R (this file
also exists) and append it to the .Rd-file. However, there is no
\examples{...} section in my roxygen-processed .Rd-file after running
roxygenize(). It just seems as if @example is just neglected. Should I put
the file in another directory?
The basic thing I'm trying to do is to have the unit tests for my
functions organized in separate scripts and then plug in some of their
content as examples in the .Rd-files (this should be accomplished by using
in-source documentation à la Roxygen à thus something like @example
pointing to such a script file would be very neat). I'd definitely like to
get around to manually specifying examples via the other tag @examples
as they will most likely lead to out-of-sync situations regarding the unit
test files. Any ideas?
Thanks a lot!
Janko
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange interaction between rasterImage and Grid graphics
Hi, Thanks for the follow-up. On 2 October 2010 09:33, Deepayan Sarkar deepayan.sar...@gmail.com wrote: On Fri, Oct 1, 2010 at 12:17 AM, baptiste auguie baptiste.aug...@googlemail.com wrote: Dear all, This may be specific to Mac, I haven't had a chance to test another platform. Consider this, plot(1,1,t=n) rasterImage(matrix(1),1,1,1,1) library(grid) grid.rect(gp=gpar(fill=grey)) The grid.rect covers the full device window as expected. However, when I resize the window ever so slightly (interactive device) the rectGrob is suddenly clipped to the previous plot window. I cannot understand this behavior, and it doesn't happen if one removes the rasterImage() call, so I suspect something iffy is going on with the display list or something. I can reproduce the behaviour on GNU/Linux x11(type=cairo), but this is inappropriate mixing of base and grid graphics, so officially I don't think you are allowed to expect anything at all. I think the gridBase package does this kind of mixing of base and grid graphics; and also this behavior might be a side-effect of a more serious bug. Best regards, baptiste -Deepayan The only device I've tried is quartz(), x11() crashed with rasterImage, *** caught segfault *** address 0x28, cause 'memory not mapped' Traceback: 1: rasterImage(matrix(1), 1, 1, 1, 1) sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] strange interaction between rasterImage and Grid graphics
Dear all, This may be specific to Mac, I haven't had a chance to test another platform. Consider this, plot(1,1,t=n) rasterImage(matrix(1),1,1,1,1) library(grid) grid.rect(gp=gpar(fill=grey)) The grid.rect covers the full device window as expected. However, when I resize the window ever so slightly (interactive device) the rectGrob is suddenly clipped to the previous plot window. I cannot understand this behavior, and it doesn't happen if one removes the rasterImage() call, so I suspect something iffy is going on with the display list or something. The only device I've tried is quartz(), x11() crashed with rasterImage, *** caught segfault *** address 0x28, cause 'memory not mapped' Traceback: 1: rasterImage(matrix(1), 1, 1, 1, 1) sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Automatically retrieve correct collation
Hi, roxygen can create the collate field for you, if you specify the dependencies in the commented code. I've never tested it with S4 classes though. HTH, baptiste On 18 August 2010 22:28, Janko Thyson janko.thy...@ku-eichstaett.de wrote: Dear List, consider the following scenario: setClass(Class = A, representation = representation(B = B, C = C)) setClass(Class = B, representation = representation(C = C)) setClass(Class = C, representation = representation(something = character)) Obviously, the collation for sourcing these defs needs to be: C, B, A. Which doesn't correspond to the default collation of R (alphabetically). I've tried to pick up on how to ensure the right collation when building R Packages by reading some previous posts and as far as I understand I've basically got two options here: 1) Put all class defs in one script, e.g. allClasses.R. 2) Manually specify the collation via the Collate field in the DESCRIPTION file. I'm used to organizing my classes, generics, methods etc. on a one-per-script basis in various subdirectories (e.g. R/classes, R/methods etc.) and try automate manual steps wherever possible (not sure if that's the way most of you guys code, but it definitely helped me stay on top of things). But this doesn't really go well with my two options above, does it? ;-) So I thought about setting up a routine that - investigates the source code of all classes (via parsing and looking into the representation argument) - finds out the valid collation by itself based on all classes that it found in the representation argument of the respective class defs - and then writes all the class defs to one R script, e.g. allClasses.R, so I can bundle all my code in an R Package without worrying about the collation. This way I could stick to my old habits while automating the process of building a package a bit ;-) Now, I managed to get this done for simple class defs like the ones above but haven't looked into more complex class defs (e.g. including contains etc.) yet. Has anyone tried and succeeded in doing something similar or are all of you into the one-script-contains-all paradigm? If anyone is interested, I'd be glad to share code. Likewise I'd be interested in hearing about other best practices in this respect. Best regards, Janko __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr. Baptiste Auguié Departamento de Química Física, Universidade de Vigo, Campus Universitario, 36310, Vigo, Spain tel: +34 9868 18617 http://webs.uvigo.es/coloides __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gpar fill and transparency on devices
Hi,
Thanks for pointing this out. I do have the book, unfortunately I left
it abroad this year. I would think that such brief mention in ?gpar
could be useful (because that's where one first looks for gpar()
defaults --- which are not listed).
Best regards,
baptiste
On 6 August 2010 00:54, Paul Murrell p.murr...@auckland.ac.nz wrote:
Hi
The help page for Working with Viewports (e.g., pushViewport()) has a
brief mention when talking about the ROOT viewport ...
The viewport tree always has a single root viewport (created by the system)
which corresponds to the entire device (and default graphical parameter
settings).
... which is a reasonable place for it because this is a feature of the gpar
of the ROOT viewport, not of gpars in general. That mention might be a bit
hard to find, but a very similar statement is also made in the Section on
Viewports in the R Graphics book. That in turn might be hard to find if you
don't have the book, but that chapter is also available online
(http://www.stat.auckland.ac.nz/~paul/RGraphics/chapter5.pdf)
It might be worth adding something more explicit about this sort of gotcha
...
Some devices have different default graphics parameter settings, so it is
not safe to assume that the ROOT viewport will be identical on different
devices.
... ?
Paul
On 5/08/2010 8:14 a.m., baptiste auguie wrote:
Dear list,
I'm puzzled by the graphical output in the following example,
library(grid)
foo- function(){
grid.rect(gp=gpar(fill=black))
print(get.gpar()$fill)
grid.rect(width=0.2,height=0.2)
}
png(test.png, bg = transparent)
foo()
dev.off()
png(test1.png, bg = white)
foo()
dev.off()
It seems that the default value of gpar()$fill is set according to the
device background. I couldn't find this documented in ?gpar or in
?png, and it caused a rather puzzling bug in my code (the pdf() output
was OK, whilst the png output (default bg to white) was seemingly
empty because covered by a white rectangle.)
Best regards,
baptiste
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
--
Dr. Baptiste Auguié
Departamento de Química Física,
Universidade de Vigo,
Campus Universitario, 36310, Vigo, Spain
tel: +34 9868 18617
http://webs.uvigo.es/coloides
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] gpar fill and transparency on devices
Dear list,
I'm puzzled by the graphical output in the following example,
library(grid)
foo - function(){
grid.rect(gp=gpar(fill=black))
print(get.gpar()$fill)
grid.rect(width=0.2,height=0.2)
}
png(test.png, bg = transparent)
foo()
dev.off()
png(test1.png, bg = white)
foo()
dev.off()
It seems that the default value of gpar()$fill is set according to the
device background. I couldn't find this documented in ?gpar or in
?png, and it caused a rather puzzling bug in my code (the pdf() output
was OK, whilst the png output (default bg to white) was seemingly
empty because covered by a white rectangle.)
Best regards,
baptiste
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid.cap() requires more time?
Hi, I submitted a bug report today. On 17 April 2010 22:34, Simon Urbanek simon.urba...@r-project.org wrote: On Apr 17, 2010, at 2:43 PM, baptiste auguie wrote: Hi, On 17 April 2010 18:51, Simon Urbanek simon.urba...@r-project.org wrote: Baptiste, first, there is a mailing list specifically for Mac questions - R-SIG-Mac. I wasn't sure if it was Mac-specific (OK, quartz() is but I could not test x11()). Now to your post - grid.cap captures the screen of the device which has two implications here: a) Quartz is asynchronous -- i.e. is doesn't actually draw the content on screen until you're finished with drawing (for efficiency). Unfortunately R has no provision to tell the graphics device that it's done with drawing (you can always add another lines() etc.) so Quartz is simply guessing by measuring the time between draw commands. So when you run grid.cap while the output has not been drawn yet (i.e. immediately after the last drawing command) it will be empty as there is no content yet since Quartz is waiting for the end. OK, that makes sense. b) it will contain the resize mark because it is a screen shot so the mark is actually part of it (this is intentional). This design decision surprises me. Would it be possible to have an option not to capture this mark as well? I don't think so because the mark is part of the Quartz view - it is not something the device adds so it is not a design decision. Again I can only repeat that if you want a re-play of the draw commands you should use that instead - it's a different task. If what you really want is a bitmap from the device, it's better to use quartz.save instead (followed by readPNG if you want the bitmap as raster) -- that actually re-runs the plot in a separate quartz device that is not on-screen so neither of the above are an issue. I thought the aim of grid.cap was to make it easier to capture a bitmap copy (no need to create an external file). Is a screenshot more useful? I didn't write grid.cap() so I don't know what the intention was, but capturing a bitmap copy is exactly the above (that is why it is called capture I suppose). What you are requesting is something different - creating a new bitmap using the same device settings and quartz.save does that. It would be trivial to add a parameter to quartz.save to return the bitmap directly instead of a file, but R did not have direct bitmap support so it was not requested so far. This would be very useful, I think. In fact, it sounds like it might be possible to convert a set of graphical commands directly into a raster representation, without creating an intermediate file nor opening an interactive device window. That would be awesome. Thanks, baptiste Cheers, Simon That said, you can file a) as a bug against Mac version of R (at https://bugs.r-project.org/ ) since grid.cap should actually trigger the flush before it does the capture. I cannot promise that the fix will make it to 2.11.0, though, because it may be non-trivial to trigger the asynchronous flush and wait for it without blocking something (I'll have to look). Will do. Thanks, baptiste Thanks, Simon On Apr 17, 2010, at 6:34 AM, baptiste auguie wrote: Dear all, I am puzzled by the following behavior of the new grid.cap() function, which appears to run out of time when capturing the output of a graphic. It works fine if I introduce a Sys.sleep(1) before executing more code, library(grid) quartz() grid.circle(gp=gpar(fill=black)) gg - grid.cap() dev.new() grid.raster(gg) ## completely blank gg[gg!=white] ## indeed quartz() grid.circle(gp=gpar(fill=black)) Sys.sleep(1) gg - grid.cap() dev.new() grid.raster(gg) ## OK gg[gg!=white] I tried to see if the problem was limited to the quartz() device but for some reason the x11() device is not working for me in this R version, capabilities(what = NULL) jpeg png tiff tcltk X11 aqua http/ftp sockets libxml fifo cledit iconv NLS profmem cairo TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE Warning message: In doTryCatch(return(expr), name, parentenv, handler) : unable to load shared library '/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so': dlopen(/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so, 6): Library not loaded: /usr/X11/lib/libpng12.0.dylib Referenced from: /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so Reason: Incompatible library version: R_X11.so requires version 42.0.0 or later, but libpng12.0.dylib provides version 36.0.0 sessionInfo() R version 2.11.0 RC (2010-04-16 r51754) i386-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets
[Rd] grid.cap() requires more time?
Dear all, I am puzzled by the following behavior of the new grid.cap() function, which appears to run out of time when capturing the output of a graphic. It works fine if I introduce a Sys.sleep(1) before executing more code, library(grid) quartz() grid.circle(gp=gpar(fill=black)) gg - grid.cap() dev.new() grid.raster(gg) ## completely blank gg[gg!=white] ## indeed quartz() grid.circle(gp=gpar(fill=black)) Sys.sleep(1) gg - grid.cap() dev.new() grid.raster(gg) ## OK gg[gg!=white] I tried to see if the problem was limited to the quartz() device but for some reason the x11() device is not working for me in this R version, capabilities(what = NULL) jpeg png tifftcltk X11 aqua http/ftp sockets libxml fifo clediticonv NLS profmemcairo TRUE TRUE TRUE TRUEFALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE Warning message: In doTryCatch(return(expr), name, parentenv, handler) : unable to load shared library '/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so': dlopen(/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so, 6): Library not loaded: /usr/X11/lib/libpng12.0.dylib Referenced from: /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so Reason: Incompatible library version: R_X11.so requires version 42.0.0 or later, but libpng12.0.dylib provides version 36.0.0 sessionInfo() R version 2.11.0 RC (2010-04-16 r51754) i386-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.11.0 I would appreciate if someone could confirm this behavior. Pointers to a fix for the x11() device on my machine are also welcome! Best regards, baptiste __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid.cap() requires more time?
I just figured out what the strange noise consisted of in the captured output of my previous example, and this is another source of curiosity for me, quartz(width=0.1, height=0.1) gg - grid.cap() dev.new() grid.raster(gg) Should grid.cap() really capture the resizing handle of the quartz() window? Best regards, baptiste On 17 April 2010 12:34, baptiste auguie baptiste.aug...@googlemail.com wrote: Dear all, I am puzzled by the following behavior of the new grid.cap() function, which appears to run out of time when capturing the output of a graphic. It works fine if I introduce a Sys.sleep(1) before executing more code, library(grid) quartz() grid.circle(gp=gpar(fill=black)) gg - grid.cap() dev.new() grid.raster(gg) ## completely blank gg[gg!=white] ## indeed quartz() grid.circle(gp=gpar(fill=black)) Sys.sleep(1) gg - grid.cap() dev.new() grid.raster(gg) ## OK gg[gg!=white] I tried to see if the problem was limited to the quartz() device but for some reason the x11() device is not working for me in this R version, capabilities(what = NULL) jpeg png tiff tcltk X11 aqua http/ftp sockets libxml fifo cledit iconv NLS profmem cairo TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE Warning message: In doTryCatch(return(expr), name, parentenv, handler) : unable to load shared library '/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so': dlopen(/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so, 6): Library not loaded: /usr/X11/lib/libpng12.0.dylib Referenced from: /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so Reason: Incompatible library version: R_X11.so requires version 42.0.0 or later, but libpng12.0.dylib provides version 36.0.0 sessionInfo() R version 2.11.0 RC (2010-04-16 r51754) i386-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.11.0 I would appreciate if someone could confirm this behavior. Pointers to a fix for the x11() device on my machine are also welcome! Best regards, baptiste __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid.cap() requires more time?
Hi, On 17 April 2010 18:51, Simon Urbanek simon.urba...@r-project.org wrote: Baptiste, first, there is a mailing list specifically for Mac questions - R-SIG-Mac. I wasn't sure if it was Mac-specific (OK, quartz() is but I could not test x11()). Now to your post - grid.cap captures the screen of the device which has two implications here: a) Quartz is asynchronous -- i.e. is doesn't actually draw the content on screen until you're finished with drawing (for efficiency). Unfortunately R has no provision to tell the graphics device that it's done with drawing (you can always add another lines() etc.) so Quartz is simply guessing by measuring the time between draw commands. So when you run grid.cap while the output has not been drawn yet (i.e. immediately after the last drawing command) it will be empty as there is no content yet since Quartz is waiting for the end. OK, that makes sense. b) it will contain the resize mark because it is a screen shot so the mark is actually part of it (this is intentional). This design decision surprises me. Would it be possible to have an option not to capture this mark as well? If what you really want is a bitmap from the device, it's better to use quartz.save instead (followed by readPNG if you want the bitmap as raster) -- that actually re-runs the plot in a separate quartz device that is not on-screen so neither of the above are an issue. I thought the aim of grid.cap was to make it easier to capture a bitmap copy (no need to create an external file). Is a screenshot more useful? That said, you can file a) as a bug against Mac version of R (at https://bugs.r-project.org/ ) since grid.cap should actually trigger the flush before it does the capture. I cannot promise that the fix will make it to 2.11.0, though, because it may be non-trivial to trigger the asynchronous flush and wait for it without blocking something (I'll have to look). Will do. Thanks, baptiste Thanks, Simon On Apr 17, 2010, at 6:34 AM, baptiste auguie wrote: Dear all, I am puzzled by the following behavior of the new grid.cap() function, which appears to run out of time when capturing the output of a graphic. It works fine if I introduce a Sys.sleep(1) before executing more code, library(grid) quartz() grid.circle(gp=gpar(fill=black)) gg - grid.cap() dev.new() grid.raster(gg) ## completely blank gg[gg!=white] ## indeed quartz() grid.circle(gp=gpar(fill=black)) Sys.sleep(1) gg - grid.cap() dev.new() grid.raster(gg) ## OK gg[gg!=white] I tried to see if the problem was limited to the quartz() device but for some reason the x11() device is not working for me in this R version, capabilities(what = NULL) jpeg png tiff tcltk X11 aqua http/ftp sockets libxml fifo cledit iconv NLS profmem cairo TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE Warning message: In doTryCatch(return(expr), name, parentenv, handler) : unable to load shared library '/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so': dlopen(/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so, 6): Library not loaded: /usr/X11/lib/libpng12.0.dylib Referenced from: /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so Reason: Incompatible library version: R_X11.so requires version 42.0.0 or later, but libpng12.0.dylib provides version 36.0.0 sessionInfo() R version 2.11.0 RC (2010-04-16 r51754) i386-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.11.0 I would appreciate if someone could confirm this behavior. Pointers to a fix for the x11() device on my machine are also welcome! Best regards, baptiste __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R logo as SVG ?
You got the first two letters right, but it's actually *Barry*'s work! As a matter of personal taste, I like the 3D rendering of the current logo; my only wish would be for an open source to reproduce it. baptiste On 27 February 2010 19:55, Jens Elkner je...@cs.uni-magdeburg.de wrote: BTW: What do you think about Baptiste's work ( http://www.maths.lancs.ac.uk/~rowlings/Graphics/Logo/R/logos.svg )? IMHO looks cool, sharp, modern and simple enough to be used in any vector drawing program efficiently. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R logo as SVG ?
On 21 February 2010 14:48, Barry Rowlingson b.rowling...@lancaster.ac.uk wrote: A while ago I played around with creating a new R logo using vector graphics. I took the current logo as a starting point. Here's some samples on different coloured backgrounds: http://www.maths.lancs.ac.uk/~rowlings/Graphics/Logo/R/logos.svg I figured maybe for R 3.0 it would be cool to have an R made from a 1 and a 2 That's funny, when I saw your logo yesterday in google images I didn't see the 1 and 2 but rather thought it was showing a lambda for some reason. Personally, I've always been curious to unravel the elliptical construction hidden in that grey area surrounding R. That'd be a nice side-effect of having a 3D model in povray (*); we could rotate it and see the other side. Sadly I don't have the skill. I wonder if RGL or Blender could make this easier yet still reproducible. Best, baptiste (*) a neat example is at: http://www.imagico.de/pov/icons.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] incorrect linetype with pdf device (PR#14128)
Dear list,
A small follow up on this issue. The same behavior is observed for
postscript() and pdf(), so I suspect the erroneous code is in
grDevices/src/devPS.c. In particular, this macro,
static void
PostScriptSetLineTexture(FILE *fp, const char *dashlist, int nlty, double lwd)
{
/* use same macro for Postscript and PDF */
#define PP_SetLineTexture(_CMD_)
\
double dash;
\
int i;
\
fprintf(fp,[);
\
for (i = 0; i nlty; i++) {
\
dash = (lwd = 1 ? lwd: 1) *
\
((i % 2) ? dashlist[i] + 1
\
:((nlty == 1 dashlist[i] == 1.) ? 1. : dashlist[i] - 1));
\
if (dash 0) dash = 0;
\
fprintf(fp, %.2f, dash);
\
}
\
fprintf(fp,] 0 %s\n, _CMD_)
PP_SetLineTexture(setdash);
}
I think the dash pattern should be
dash = (lwd = 1 ? lwd: 1) *\
((i % 2) ? dashlist[i]
\
:((nlty == 1 dashlist[i] == 1.) ? 1. : dashlist[i] ));
instead (but I don't know C well enough to be sure).
Best regards,
baptiste
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi,
[my message below is a bit off-topic]
2009/12/14 Paul Murrell p.murr...@auckland.ac.nz:
I have thought a bit about drawing the same image multiple times (more in
the context of using a bitmap for a plotting symbol). I imagine something
like being able to add a raster image to a device and then simply refer
to that image (e.g., by name) is needed.
That would be nice.
I first thought that this new rasterGrob would be a good way to
implement some kind of filling pattern for grid graphics, but after
some more testing I was surprised to see that a similar approach with
vector patterns could result in more efficient, better output. Of
course raster filling patterns could still be nice to have for fancy
images or gradients.
One thing that worries me with the approach I've taken below is that
the grob is not vectorized. In particular, if one was to use it as a
building block for histograms (as in base graphics' density parameter)
each rectangle would have to be drawn in sequence. I can of course
Vectorize() this grob into a new one (gTree) but I haven't seen any
examples like this before. Does this sound reasonable? (argument
explosion might be another problem...)
Best regards,
baptiste
Below is the gist of my experiments (the first part is not related to
grid.raster and runs in current R).
library(grid)
## vector patterns
source(http://gridextra.googlecode.com/svn/trunk/R/vpattern.r;)
dev.new()
grid.newpage()
grid.vpattern(x=0.2, width=unit(3,cm), height=unit(0.5,npc),
motif=points, motif.params=list(pch=22,
gp=gpar(cex=0.8, lwd=5, col=grey90,
fill=grey95)), clip=T)
grid.vpattern(x=0.5, width=unit(0.3,npc), height=unit(0.5,npc),
motif=segments, motif.params=list(angle=45,
gp=gpar(lty=2, col=grey, lwd=2.4)))
grid.vpattern(x=0.5, y=0.9, width=unit(0.5,npc), height=unit(1,cm),
motif=points, motif.params=list(pch=+), clip=F,
pattern.offset=c(1, 0.5))
grid.vpattern(x=0.8, width=unit(0.2,npc), height=unit(0.2,npc),
motif=grid, motif.params=list(angle=45,
gp=gpar(lwd=10, col=grey90)), clip=T,
pattern.offset=c(-1, 0.5))
grid.vpattern(x=0.5, y=0.1, width=unit(0.9,npc), height=unit(0.1,npc),
motif=grid, motif.params=list(angle=30, gp=gpar(col=red)),
gp=gpar(alpha=0.1, fill=red))
## raster patterns
source(http://gridextra.googlecode.com/svn/trunk/R/rpattern.r;)
## a raster motif
plus - function(..., width=5, height=5){
x11(width=width/25.4, height=height/25.4)
grid.points(x=unit(0.5, npc), y=unit(0.5, npc),
pch=3, size=unit(2, mm), gp=gpar(), ...)
m - grid.cap()
dev.off()
invisible(m)
}
.plus - plus()
g1 - rpatternGrob(x=0.5, y=0.4, width=unit(3.7, cm),
height=unit(0.4, npc),
clip=TRUE, motif=.plus)
dev.new()
grid.draw(g1)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] incorrect linetype with pdf device (PR#14128)
Full_Name: baptiste auguié Version: 2.10.1 RC (2009-12-06 r50690) OS: Mac OSX 10.5 Submission from: (NULL) (90.25.215.172) The following code, run with a vanilla R session, produces different visual output for the two devices, library(grid) pdf(test-pdf.pdf) grid.newpage() grid.lines(gp=gpar(lty=13, lineend = butt)) dev.off() png(test-png.png) grid.newpage() grid.lines(gp=gpar(lty=13, lineend = butt)) dev.off() The pdf output, opened with Acrobat, shows only extremely thin marks (artifacts) at low zoom factor, and invisible line at higher zoom factor. The same file opened with Adobe Illustrator reveals that the line pattern lty=13 has in fact become 04 (0 solid length, 4 space). Similarly, lty=123456 would produce 032547, pdf(test-123456.pdf) grid.newpage() grid.lines(gp=gpar(lty=123456, lineend = butt)) dev.off() while the same command with quartz() gives the correct line pattern, quartz(type=pdf, file=test2-123456.pdf) grid.newpage() grid.lines(gp=gpar(lty=123456, lineend = butt)) dev.off() The same behavior is observed with R 2.11.0 (2009-12-09 r50690) sessionInfo() R version 2.10.1 RC (2009-12-06 r50690) i386-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods [8] base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] incorrect linetype with quartz device (PR#14129)
Full_Name: baptiste auguié
Version: 2.10.1 RC (2009-12-06 r50690)
OS: Mac OSX 10.5
Submission from: (NULL) (90.25.215.172)
The quartz() device, either in interactive use or with pdf file output, produces
an incorrect dashed line when the data is dense. Consider the following
comparison between quartz() and pdf(),
library(grid)
comparison - function(N=10){
x = seq(0, 10, length=N)
y = cos(x)
output.quartz - paste(quartz-, N,.pdf, sep=)
output.pdf - paste(pdf-, N,.pdf, sep=)
pdf(output.pdf, width=4, height=4)
pushViewport(viewport(xscale=c(0, 10), yscale=c(0, 6)))
for(ind in 1:5)
grid.lines(x, y+ind, gp=gpar(lty=ind),
default.units=native)
dev.off()
quartz(type=pdf, file=output.quartz,
width=4, height=4)
pushViewport(viewport(xscale=c(0, 10), yscale=c(0, 6)))
for(ind in 1:5)
grid.lines(x, y+ind, gp=gpar(lty=ind),
default.units=native)
dev.off()
}
comparison()
## the output is (almost, see PR#14128) identical
comparison(1e4)
## here the quartz output has non-homogeneous spacing
## depending on the slope of the data
## and the aspect ratio of the device
The same behavior is observed with R2.11.0 (2009-12-09 r50690)
sessionInfo()
R version 2.10.1 RC (2009-12-06 r50690)
i386-apple-darwin9.8.0
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] grid stats graphics grDevices utils datasets methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] lty parameter not respected by pdf device
Dear all, Several of us ggplot2 users noticed the disappearance of some dashed lines in the pdf output produced with the pdf device. They looked fine on screen or with quartz() output. When opening the file with Illustrator I noted that the missing line was in fact present, but with a dashed pattern that contained zero solid length. It appears that if you specify lty in the form lty=xy, pdf() produces a line with lty=(x-1)(y+1) and some lines may disappear. Here is a minimal example, pdf(test.pdf) grid.polyline(gp=gpar(lty=13))#, lineend = butt)) dev.off() The line is invisible, and has pattern (according to Illustrator) lty=04. Similarly, pdf(test.pdf) grid.polyline(gp=gpar(lty=))#, lineend = butt)) dev.off() produces a visible line with pattern lty=4646 Best regards, baptiste sessionInfo() R version 2.11.0 Under development (unstable) (2009-11-30 r50622) i386-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods [8] base other attached packages: [1] ggplot2_0.8.3 reshape_0.8.3 plyr_0.1.9proto_0.3-8 loaded via a namespace (and not attached): [1] tools_2.11.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi,
2009/12/6 Paul Murrell p.murr...@auckland.ac.nz:
Hi
baptiste auguie wrote:
Dear all,
It seems to me that grid.raster is a special case of grid.rect as far
as the intended visual output is concerned. The example below
illustrates how both can be used to produce an image of the volcano
data,
I disagree. A rect grob is a vector object and a raster grob is a
raster object and I think they should be kept distinct. You could possibly
create a higher-level image object that is agnostic with respect to how it
is implemented and have both rect-based and raster-based versions of
that, but rect and raster are graphical primitives and at that level I
think the distinction is useful.
Fair point. I raised this question when trying to convert some ggplot2
code from grid.rect to grid.raster (for large images) and I came to
the conclusions that a) it wasn't completely trivial (for me anyway);
b) such conversion would probably be done over and over in the next
few months by several different people.
Your suggestion of a higher-level grob is interesting, and probably
more elegant than a function that converts one grob to the other as I
first envisaged.
Thanks,
baptiste
Paul
d - volcano
cols - grey(t(d)/max(c(d)))
xy - expand.grid(x=seq(0, 1, length=ncol(d)), y=seq(0, 1,
length=nrow(d)))
pdf(comparison.pdf, width=10, height=10/2*ncol(d)/nrow(d))
pushViewport(viewport(layout=grid.layout(1, 2)))
pushViewport(viewport(layout.pos.r=1, layout.pos.c=1))
grid.rect(xy$y, rev(xy$x), 1/(nrow(d)), 1/(ncol(d)), gp=gpar(col=NA,
fill=cols))
grid.text(grid.rect)
upViewport()
pushViewport(viewport(layout.pos.r=1, layout.pos.c=2))
cols.mat - matrix(cols, ncol=ncol(d), byrow=T)
grid.raster(t(cols.mat))
grid.text(grid.raster)
dev.off()
Of course grid.raster provides a much better output in terms of file
size, speed, visualisation artifacts, and interpolation. My question
though: is it necessary to have a distinct grob for raster output?
Couldn't raster be an option in grid.rect when the width and height
are constant?
Alternatively, it might be useful to provide a function that converts
a rectGrob into a rasterGrob,
rect2raster - function(g){
with(g,
rasterGrob(matrix(gp$fill, ncol=length(unique(x))),
mean(x),mean(y)))
}
This way, much of the existing code relying on grid.rect (e.g in
lattice or ggplot2) could easily be adapted to work with grid.raster
in favorable cases.
Best regards,
baptiste
2009/12/1 Paul Murrell p.murr...@auckland.ac.nz:
Hi
This is for developers of extension packages that provide extra *graphics
devices* for R.
In the *development* version of R, support has been added to the graphics
engine for sending raster images (bitmaps) to a graphics device. This
consists mainly of two new device functions: dev_Raster() and dev_Cap().
The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6
as a
marker of this change.
This means that, at a minimum, all graphics devices should be updated to
provide dummy implementations of these new functions that just say the
feature is not yet implemented (see for example the PicTeX and XFig
devices
in the 'grDevices' package).
A full implementation of dev_Raster() should be able to draw a raster
image
(provided as an array of 32-bit R colors) at any size, possibly
(bilinear)
interpolated (otherwise nearest-neighbour), at any orientation, and with
a
per-pixel alpha channel. Where these are not natively supported by a
device, the graphics engine provides some routines for scaling and
rotating
raster images (see for example the X11 device). The dev_Cap() function
should return a representation of a raster image captured from the
current
device. This will only make sense for some devices (see for example the
Cairo device in the 'grDevices' package).
A little more information and a couple of small examples are provided at
http://developer.r-project.org/Raster/raster-RFC.html
Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi,
Thanks for the fix. I hope the quartz bugs are not related to a bad
configuration on my side (I don't have access to another Mac to test
it).
I was quite happy with this proof-of-concept of filling patterns for
rectangles, and I was wondering if perhaps you had considered adding a
similar tiling option to grid.raster (at the C level)?
Best regards,
baptiste
2009/12/6 Paul Murrell p.murr...@auckland.ac.nz:
Hi
baptiste auguie wrote:
Hi again,
I found two possible bugs related to grid.raster, one with the quartz
device and the other with pdf.
In my example I was playing with the idea of using grid.raster to
create a filling pattern for rectangles. The pdf output does not seem
to respect the clipping (it may have nothing to do with grid.raster
though), whilst the quartz device with pdf file output often crashes
for more than 4 different raster objects (but not always). I'm afraid
I couldn't pinpoint the exact circumstance of the crash with a more
concise example.
Thanks again for the report.
I have committed a fix for the PDF clipping.
Still looking at the Quartz crashes.
Paul
Thanks in advance for any insights,
baptiste
### Start example ###
library(grid)
## create a motif
grid45 - function(..., width=0.5, height=0.5){
x11(width=width, height=height)
grid.polygon(...)
m - grid.cap()
dev.off()
invisible(m)
}
.grid45 - grid45()
## grid.raster(.grid45)
tile.motif - function(m, nx=10, ny=nx){
cols - matrix(rep(m, nx), ncol=ncol(m)*nx, byrow=F)
matrix(rep(t(cols), ny), nrow=nrow(cols)*ny, byrow=T)
}
## quartz()
## grid.raster(tile.motif(.grid45, 2, 3))
patternGrob - function(x=unit(0.5, npc), y=unit(0.5, npc),
width=unit(1, npc), height=unit(1, npc),
motif=matrix(white), AR=1,
motif.width=unit(5, mm),
motif.height=AR*motif.width,
pattern.offset=c(0, 0), # unimplemented
default.units=npc,
clip=TRUE, # testing purposes
gp=gpar(fill=NA), ...)
{
grob(x=x, y=y, width=width, height=height,
motif=motif, motif.width=motif.width,
motif.height=motif.height, clip=clip, gp=gp, ..., cl=pattern)
}
widthDetails.pattern - function(x) x$width
heightDetails.pattern - function(x) x$height
drawDetails.pattern - function(x, recording=TRUE){
## calculate the number of tiles
nx - ceiling(convertUnit(x$width, in, value=TRUE) /
convertUnit(x$motif.width, in, value=TRUE)) + 1
ny - ceiling(convertUnit(x$height, in, axisFrom = y, value=TRUE) /
convertUnit(x$motif.height, in, axisFrom = y,
value=TRUE)) + 1
width - convertUnit(x$width, in)
height - convertUnit(x$height, in, axisFrom = y)
## clip the raster
pushViewport(viewport(x=x$x, y=x$y,
width=x$width, height=x$height, clip=x$clip))
grid.raster(tile.motif(x$motif, nx, ny), width=nx*x$motif.width,
height=ny*x$motif.height)
upViewport()
## overlay the rectangle
grid.rect(x=x$x, y=x$y,
width=x$width, height=x$height,
just=center, gp=x$gp)
}
g - patternGrob(x=0.7, width=unit(0.3, npc),
height=unit(5.2, cm),
clip=TRUE, motif=.grid45)
## interactive use: OK
quartz()
grid.newpage()
grid.draw(g)
## png: OK
png(file=pngClip.png)
grid.newpage()
grid.draw(g)
dev.off()
## pdf: clipping does not occur
pdf(file=pdfClip.pdf)
grid.newpage()
grid.draw(g)
dev.off()
## quartz pdf: OK, but see below
quartz(file=quartzClip.pdf, type=pdf)
grid.newpage()
grid.draw(g)
dev.off()
g1 - patternGrob(x=0.2, width=unit(0.2, npc),
height=unit(5.2, cm),
clip=TRUE, motif=.grid45)
g2 - patternGrob(x=0.4, width=unit(0.2, npc),
height=unit(5.2, cm),
clip=TRUE, motif=.grid45)
g3 - patternGrob(x=0.6, width=unit(0.2, npc),
height=unit(5.2, cm),
clip=TRUE, motif=.grid45)
g4 - patternGrob(x=0.8, width=unit(0.2, npc),
height=unit(5.2, cm),
clip=TRUE, motif=.grid45)
quartz(file=quartzClip2.pdf, type=pdf)
grid.newpage()
grid.draw(g1)
grid.draw(g2)
grid.draw(g3)
grid.draw(g4)
dev.off()
*** caught segfault ***
address 0x15dda018, cause 'memory not mapped'
Traceback:
1: dev.off()
sessionInfo()
R version 2.11.0 Under development (unstable) (2009-11-30 r50622)
i386-apple-darwin9.8.0
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] grid stats graphics grDevices utils datasets methods
[8] base
2009/12/2 Paul Murrell p.murr...@auckland.ac.nz:
Hi
baptiste auguie wrote:
Very nice, thank you for this great addition to R graphics! I can't
wait to see lattice and ggplot2 functions that use rasterGrob to
display images. The pdf
Re: [Rd] raster support in graphics devices
Dear all,
It seems to me that grid.raster is a special case of grid.rect as far
as the intended visual output is concerned. The example below
illustrates how both can be used to produce an image of the volcano
data,
d - volcano
cols - grey(t(d)/max(c(d)))
xy - expand.grid(x=seq(0, 1, length=ncol(d)), y=seq(0, 1, length=nrow(d)))
pdf(comparison.pdf, width=10, height=10/2*ncol(d)/nrow(d))
pushViewport(viewport(layout=grid.layout(1, 2)))
pushViewport(viewport(layout.pos.r=1, layout.pos.c=1))
grid.rect(xy$y, rev(xy$x), 1/(nrow(d)), 1/(ncol(d)), gp=gpar(col=NA,
fill=cols))
grid.text(grid.rect)
upViewport()
pushViewport(viewport(layout.pos.r=1, layout.pos.c=2))
cols.mat - matrix(cols, ncol=ncol(d), byrow=T)
grid.raster(t(cols.mat))
grid.text(grid.raster)
dev.off()
Of course grid.raster provides a much better output in terms of file
size, speed, visualisation artifacts, and interpolation. My question
though: is it necessary to have a distinct grob for raster output?
Couldn't raster be an option in grid.rect when the width and height
are constant?
Alternatively, it might be useful to provide a function that converts
a rectGrob into a rasterGrob,
rect2raster - function(g){
with(g,
rasterGrob(matrix(gp$fill, ncol=length(unique(x))), mean(x),mean(y)))
}
This way, much of the existing code relying on grid.rect (e.g in
lattice or ggplot2) could easily be adapted to work with grid.raster
in favorable cases.
Best regards,
baptiste
2009/12/1 Paul Murrell p.murr...@auckland.ac.nz:
Hi
This is for developers of extension packages that provide extra *graphics
devices* for R.
In the *development* version of R, support has been added to the graphics
engine for sending raster images (bitmaps) to a graphics device. This
consists mainly of two new device functions: dev_Raster() and dev_Cap().
The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as a
marker of this change.
This means that, at a minimum, all graphics devices should be updated to
provide dummy implementations of these new functions that just say the
feature is not yet implemented (see for example the PicTeX and XFig devices
in the 'grDevices' package).
A full implementation of dev_Raster() should be able to draw a raster image
(provided as an array of 32-bit R colors) at any size, possibly (bilinear)
interpolated (otherwise nearest-neighbour), at any orientation, and with a
per-pixel alpha channel. Where these are not natively supported by a
device, the graphics engine provides some routines for scaling and rotating
raster images (see for example the X11 device). The dev_Cap() function
should return a representation of a raster image captured from the current
device. This will only make sense for some devices (see for example the
Cairo device in the 'grDevices' package).
A little more information and a couple of small examples are provided at
http://developer.r-project.org/Raster/raster-RFC.html
Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi, You can use grid.cap, x11() plot(1:10) g = grid.cap() dev.off() str(g) # chr [1:672, 1:671] white white white white white ... but as far as I understand in ?grid.cap and the underlying code there is no capGrob equivalent that wouldn't require opening a new device before capturing the output. I hope I'm mistaken. Best, baptiste 2009/12/4 Gabor Grothendieck ggrothendi...@gmail.com: Currently I have an application that saves the current graphics image (that was created with classic graphics or grid graphics) to a file and then reads the file back in using readBin: png(my.png) plot(1:10) dev.off() raw.img - readBin(my.png, raw, size = 1, n = 1) (I am doing this on Windows but would like to be able to do it on any platform.) Does the new raster functionality give me any way to get the object raw.img without creating the intermediate file, my.png? If so what is the corresponding code? On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell p.murr...@auckland.ac.nzwrote: Hi This is for developers of extension packages that provide extra *graphics devices* for R. In the *development* version of R, support has been added to the graphics engine for sending raster images (bitmaps) to a graphics device. This consists mainly of two new device functions: dev_Raster() and dev_Cap(). The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as a marker of this change. This means that, at a minimum, all graphics devices should be updated to provide dummy implementations of these new functions that just say the feature is not yet implemented (see for example the PicTeX and XFig devices in the 'grDevices' package). A full implementation of dev_Raster() should be able to draw a raster image (provided as an array of 32-bit R colors) at any size, possibly (bilinear) interpolated (otherwise nearest-neighbour), at any orientation, and with a per-pixel alpha channel. Where these are not natively supported by a device, the graphics engine provides some routines for scaling and rotating raster images (see for example the X11 device). The dev_Cap() function should return a representation of a raster image captured from the current device. This will only make sense for some devices (see for example the Cairo device in the 'grDevices' package). A little more information and a couple of small examples are provided at http://developer.r-project.org/Raster/raster-RFC.html Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/http://www.stat.auckland.ac.nz/%7Epaul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Very nice, thank you for this great addition to R graphics! I can't wait to see lattice and ggplot2 functions that use rasterGrob to display images. The pdf output is so much better in every way! Incidentally, I ran into a segfault with grid.cap on the quartz device, but maybe it's normal at this stage. This works fine: library(grid) x11() grid.text(test) cap - grid.cap() This doesn't: library(grid) quartz() grid.text(test) cap - grid.cap() *** caught segfault *** address 0x18330001, cause 'memory not mapped' Traceback: 1: .Call(fnname, ..., PACKAGE = grid) 2: grid.Call(L_cap) 3: grid.cap() Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace [R.app GUI 1.30 (5527) i386-apple-darwin9.8.0] sessionInfo() R version 2.11.0 Under development (unstable) (2009-11-30 r50622) i386-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base Best regards, baptiste 2009/12/1 Paul Murrell p.murr...@auckland.ac.nz: Hi This is for developers of extension packages that provide extra *graphics devices* for R. In the *development* version of R, support has been added to the graphics engine for sending raster images (bitmaps) to a graphics device. This consists mainly of two new device functions: dev_Raster() and dev_Cap(). The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as a marker of this change. This means that, at a minimum, all graphics devices should be updated to provide dummy implementations of these new functions that just say the feature is not yet implemented (see for example the PicTeX and XFig devices in the 'grDevices' package). A full implementation of dev_Raster() should be able to draw a raster image (provided as an array of 32-bit R colors) at any size, possibly (bilinear) interpolated (otherwise nearest-neighbour), at any orientation, and with a per-pixel alpha channel. Where these are not natively supported by a device, the graphics engine provides some routines for scaling and rotating raster images (see for example the X11 device). The dev_Cap() function should return a representation of a raster image captured from the current device. This will only make sense for some devices (see for example the Cairo device in the 'grDevices' package). A little more information and a couple of small examples are provided at http://developer.r-project.org/Raster/raster-RFC.html Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to document stuff most users don't want to see
If help was only displayed in the form of html pages, one could perhaps mimic the javascript trick sometimes found in wikipedia, e.g. http://en.wikipedia.org/wiki/Mathematical_induction#Example; (see the show/hide toggle at the bottom). I don't see how this could work with plain text or pdf output. Regards, baptiste __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] puzzle with drawDetails for a class derived from a gTree
Dear all,
I've tried all sorts of variations discussed in R graphics by Paul
Murrell, but I still can't understand how to write a drawDetails
method for a class derived from a gTree.
Below is a minimal, dummy example where two strings are plotted in two
separate viewports. I require the creation of the strings to be
evaluated inside the drawDetails function because my real example will
need to calculate a grob size on-the-fly (the viewport size as well,
for which I have no clue where to place the code).
The tests below present two issues:
- editing the gp component of the gTree only affects one child for some reason
- the resulting gTree doesn't appear to contain children, they seem
hidden from the user in the drawDetails method
Any advice will be much appreciated!
Best regards,
Baptiste
## two function that create the text grobs
make.test.right - function(lab, col) {
textGrob(lab, gp=gpar(col=col), name=right, vp=rightvp)
}
make.test.left - function(lab, col) {
textGrob(lab, gp=gpar(col=col), name=left, vp=leftvp)
}
grid.test - function(right=right text, left=left text, col = red,
edits=NULL, draw=TRUE,
name=NULL, gp=gpar()) {
## layout for the two children
vp - viewport(layout=grid.layout(1, 2))
## viewports, one for each child
cvp - vpList(viewport(layout.pos.row=1, layout.pos.col=1, name=leftvp),
viewport(layout.pos.row=1, layout.pos.col=2, name=rightvp))
x - gTree(right=right, left=left, col=col,
childrenvp=cvp,
edits=edits,
name=name, gp=gp, vp=vp,
cl=test)
if(draw)
grid.draw(x)
invisible(x)
}
drawDetails.test - function(x, recording=TRUE) {
x - applyEdits(x, x$edits)
## create the two grobs
left - make.test.left(x$left, x$col)
right - make.test.right(x$right, x$col)
## add them to the gTree
x - addGrob(x, right)
x - addGrob(x, left)
## borrowed from grid.xaxis
## draw the children only
for(child in childNames(x))
grid.draw(getGrob(x, child))
}
grid.test(a, b, edits=gEdit(left=left text, col=blue), name=test)
# works as expected
grid.newpage()
grid.test(left=left text, right=right text, name=test)
grid.edit(test,left=test) # OK
grid.edit(test, col=blue) # OK
grid.edit(test, right=big too?, gp=gpar(cex=2))
# here only the left grob is altered???
grid.edit(test::right, gp=gpar(cex=2)) ## fails
## as test doesn't have children, apparently
# similarly
grid.gedit(right, right=testing)
# 'gPath' (right) not found
sessionInfo()
R version 2.9.2 (2009-08-24)
i386-apple-darwin8.11.1
locale:
en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets grid methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected behavior of `[-` method for class unit.arithmetic
Dear Paul and others,
Thanks for the quick response.
2009/9/25 Paul Murrell p.murr...@auckland.ac.nz:
Hi
The bit you found that says ...
# Write [-.unit methods too ??
... is the crucial bit.
When I figured that, I had already written up my email so I thought
I'd ask anyway from a naive user point of view (in this regard,
perhaps the help page of unit.c could mention what common methods are
not available). The results I got can be quite surprising at first.
Would it be possible to add such a method?
Almost certainly, it just needs someone to repeatedly bug the person who can
make the change :) Thanks for the suggestion for code BTW; I'll take a
look at that.
I'm afraid I won't be of much help here, I merely copied and pasted
the [.unit method with a minimal change that seemed to make it work
for illustrative purposes. I don't really understand unit.arithmetic
and unit in general.
In the meantime, the fact that this has only come up once before, while
surprising, suggests that people may have written code in a different style.
Either that or people have struggled to find their own workaround
every time. I've recently hacked a fake matrix of unit objects, where
perhaps a proper implementation would find other grateful users.
(Given a list of grobs, I needed to compute rowMax and colMax of their
size in a rectangular arrangement -- see example below, also as a
recent post on r-help).
Can you give a succinct example that demonstrates a situation where you
want to assign to a subset of a unit (rather than, say, calculating values,
setting some to 0, then building a unit from the values) ?
Though not as succinct as I'd like, I think the drawDetails method of
tableGrob[*] might present the problem:
drawDetails.table - function(x, recording=TRUE){
# makeTableGrobs returns lists of grobs, and their width and height in
a rectangular layout
lg - with(x, makeTableGrobs(as.character(as.matrix(d)), rows, cols,
nrow(d), ncol(d),
equal.width = equal.width, equal.height = equal.height,
gpar.content = gpar.content,
gpar.col = gpar.col,
gpar.row = gpar.row,
gpar.fill = gpar.fill,
gpar.rowfill = gpar.rowfill,
gpar.colfill = gpar.colfill ) )
# now I need to add some horizontal and vertical padding to each cells,
# EXCEPT for the rownames and colnames if they are not to be shown
# whereby I convert everything to raw values, use normal vector indexing,
# and convert back to unit
widthsv - convertUnit(lg$widths + x$padding.h, mm, valueOnly=TRUE)
heightsv - convertUnit(lg$heights + x$padding.v, mm, valueOnly=TRUE)
widthsv[1] - widthsv[1] * as.numeric(x$show.rownames)
widths - unit(widthsv, mm)
heightsv[1] - heightsv[1] * as.numeric(x$show.colnames)
heights - unit(heightsv, mm)
# once this is done, I can create the layout
cells = viewport(name=table.cells, layout =
grid.layout(lg$nrow+1, lg$ncol+1, width=widths, height=heights) )
# and place the elements
pushViewport(cells)
tg - arrangeTableGrobs(lg$lgt, lg$lgf, lg$nrow, lg$ncol, lg$widths,
lg$heights,
padding.h = x$padding.h, padding.v = x$padding.v,
separator=x$separator, show.box=x$show.box,
show.csep=x$show.csep, show.rsep=x$show.rsep)
upViewport()
}
Of course I could make the calculation of adding padding to the cells
earlier in the chain (in makeTableGrobs) but it's not really its
place.
Best,
baptiste
[*]: http://code.google.com/p/gridextra/source/browse/trunk/R/tableGrob.r
to be run as,
either,
library(grid)
source(http://gridextra.googlecode.com/svn/trunk/R/grob-utils.r;)
source(http://gridextra.googlecode.com/svn/trunk/R/tableGrob.r;)
grid.table(head(iris))
or simply,
Install http://gridextra.googlecode.com/files/gridextra_0.3.tar.gz
library(gridextra)
example(tableGrob)
Paul
baptiste auguie wrote:
Dear list,
Consider the following,
library(grid)
w = unit.c(unit(1, in), unit(2, in))
w2 = w + unit(1, mm)
w[2] - 0
w2[2] - 0
convertUnit(w, mm)
#[1] 25.4mm 0mm
convertUnit(w2, mm)
#Error in grid.Call(L_convert, x, as.integer(whatfrom),
as.integer(whatto), :
# INTEGER() can only be applied to a 'integer', not a 'NULL'
The last line fails, as the naive replacement has destroyed the
structure of w2 instead of having assigned a value of 0 to the second
unit element.
I've also tried,
w = unit.c(unit(1, in), unit(2, in))
w2 = w + unit(1, mm)
w2[[2]][2] - 0
but this time, if the structure is licit, it's the result that's not
as I intended:
convertUnit(w2,mm)
#[1] 26.4mm 1mm
My limited understanding is that an object of class unit.arithmetic is
waiting until the last moment to actually perform its operation,
stored in a tree-like structure. With this premise, I can't think of a
good way to modify one element of a list of unit elements.
As a workaround, I can only think of the following hack where the
objects are forced to be evaluated,
w = unit.c(unit(1
Re: [Rd] unexpected behavior of `[-` method for class unit.arithmetic
Further to my previous message, I just dug this in lattice/R/layout.R :
rearrangeUnit - function(x, pos, u)
{
lx - length(x)
if (lx == 1)
u
else if (pos == 1)
unit.c(u, x[(pos+1):lx])
else if (pos == lx)
unit.c(x[1:(pos-1)], u)
else
unit.c(x[1:(pos-1)], u, x[(pos+1):lx])
}
w = unit.c(unit(1, in), unit(2, in))
w2 = w + unit(1, mm)
rearrangeUnit(w2, 2, unit(0, mm))
Definitely a much prettier trick than mine.
Best,
baptiste
2009/9/25 baptiste auguie baptiste.aug...@googlemail.com:
Dear Paul and others,
Thanks for the quick response.
2009/9/25 Paul Murrell p.murr...@auckland.ac.nz:
Hi
The bit you found that says ...
# Write [-.unit methods too ??
... is the crucial bit.
When I figured that, I had already written up my email so I thought
I'd ask anyway from a naive user point of view (in this regard,
perhaps the help page of unit.c could mention what common methods are
not available). The results I got can be quite surprising at first.
Would it be possible to add such a method?
Almost certainly, it just needs someone to repeatedly bug the person who can
make the change :) Thanks for the suggestion for code BTW; I'll take a
look at that.
I'm afraid I won't be of much help here, I merely copied and pasted
the [.unit method with a minimal change that seemed to make it work
for illustrative purposes. I don't really understand unit.arithmetic
and unit in general.
In the meantime, the fact that this has only come up once before, while
surprising, suggests that people may have written code in a different style.
Either that or people have struggled to find their own workaround
every time. I've recently hacked a fake matrix of unit objects, where
perhaps a proper implementation would find other grateful users.
(Given a list of grobs, I needed to compute rowMax and colMax of their
size in a rectangular arrangement -- see example below, also as a
recent post on r-help).
Can you give a succinct example that demonstrates a situation where you
want to assign to a subset of a unit (rather than, say, calculating values,
setting some to 0, then building a unit from the values) ?
Though not as succinct as I'd like, I think the drawDetails method of
tableGrob[*] might present the problem:
drawDetails.table - function(x, recording=TRUE){
# makeTableGrobs returns lists of grobs, and their width and height in
a rectangular layout
lg - with(x, makeTableGrobs(as.character(as.matrix(d)), rows, cols,
nrow(d), ncol(d),
equal.width = equal.width, equal.height = equal.height,
gpar.content = gpar.content,
gpar.col = gpar.col,
gpar.row = gpar.row,
gpar.fill = gpar.fill,
gpar.rowfill = gpar.rowfill,
gpar.colfill = gpar.colfill ) )
# now I need to add some horizontal and vertical padding to each cells,
# EXCEPT for the rownames and colnames if they are not to be shown
# whereby I convert everything to raw values, use normal vector indexing,
# and convert back to unit
widthsv - convertUnit(lg$widths + x$padding.h, mm, valueOnly=TRUE)
heightsv - convertUnit(lg$heights + x$padding.v, mm, valueOnly=TRUE)
widthsv[1] - widthsv[1] * as.numeric(x$show.rownames)
widths - unit(widthsv, mm)
heightsv[1] - heightsv[1] * as.numeric(x$show.colnames)
heights - unit(heightsv, mm)
# once this is done, I can create the layout
cells = viewport(name=table.cells, layout =
grid.layout(lg$nrow+1, lg$ncol+1, width=widths, height=heights) )
# and place the elements
pushViewport(cells)
tg - arrangeTableGrobs(lg$lgt, lg$lgf, lg$nrow, lg$ncol, lg$widths,
lg$heights,
padding.h = x$padding.h, padding.v = x$padding.v,
separator=x$separator, show.box=x$show.box,
show.csep=x$show.csep, show.rsep=x$show.rsep)
upViewport()
}
Of course I could make the calculation of adding padding to the cells
earlier in the chain (in makeTableGrobs) but it's not really its
place.
Best,
baptiste
[*]: http://code.google.com/p/gridextra/source/browse/trunk/R/tableGrob.r
to be run as,
either,
library(grid)
source(http://gridextra.googlecode.com/svn/trunk/R/grob-utils.r;)
source(http://gridextra.googlecode.com/svn/trunk/R/tableGrob.r;)
grid.table(head(iris))
or simply,
Install http://gridextra.googlecode.com/files/gridextra_0.3.tar.gz
library(gridextra)
example(tableGrob)
Paul
baptiste auguie wrote:
Dear list,
Consider the following,
library(grid)
w = unit.c(unit(1, in), unit(2, in))
w2 = w + unit(1, mm)
w[2] - 0
w2[2] - 0
convertUnit(w, mm)
#[1] 25.4mm 0mm
convertUnit(w2, mm)
#Error in grid.Call(L_convert, x, as.integer(whatfrom),
as.integer(whatto), :
# INTEGER() can only be applied to a 'integer', not a 'NULL'
The last line fails, as the naive replacement has destroyed the
structure of w2 instead of having assigned a value of 0 to the second
unit element.
I've also tried,
w
[Rd] unexpected behavior of `[-` method for class unit.arithmetic
Dear list,
Consider the following,
library(grid)
w = unit.c(unit(1, in), unit(2, in))
w2 = w + unit(1, mm)
w[2] - 0
w2[2] - 0
convertUnit(w, mm)
#[1] 25.4mm 0mm
convertUnit(w2, mm)
#Error in grid.Call(L_convert, x, as.integer(whatfrom),
as.integer(whatto), :
# INTEGER() can only be applied to a 'integer', not a 'NULL'
The last line fails, as the naive replacement has destroyed the
structure of w2 instead of having assigned a value of 0 to the second
unit element.
I've also tried,
w = unit.c(unit(1, in), unit(2, in))
w2 = w + unit(1, mm)
w2[[2]][2] - 0
but this time, if the structure is licit, it's the result that's not
as I intended:
convertUnit(w2,mm)
#[1] 26.4mm 1mm
My limited understanding is that an object of class unit.arithmetic is
waiting until the last moment to actually perform its operation,
stored in a tree-like structure. With this premise, I can't think of a
good way to modify one element of a list of unit elements.
As a workaround, I can only think of the following hack where the
objects are forced to be evaluated,
w = unit.c(unit(1, in), unit(2, in))
w2 = convertUnit(w + unit(1, mm), mm, valueOnly=TRUE)
w2[2] - 0
w2 - unit(w2, mm)
but it clearly isn't a very desirable route.
What is the recommended way to modify one element of a unit vector?
Digging in grid/R/unit.R , I found the following comment,
# Write [-.unit methods too ??
which probably explains the above. Would it be possible to add such a method,
[-.unit.list - function(x, index, value, top=TRUE, ...) {
this.length - length(x)
index - (1L:this.length)[index]
if (top any(index this.length))
stop(Index out of bounds (unit list subsetting))
cl - class(x)
result - unclass(x)
result[(index - 1) %% this.length + 1] - value
class(result) - cl
result
}
a = unit.c(unit(1,mm),unit(2,in))
a[2] - unit(3,in)
a
but for unit.arithmetic also?
Regards,
baptiste
sessionInfo()
R version 2.9.2 (2009-08-24)
i386-apple-darwin8.11.1
locale:
en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets grid methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: [R] size of point symbols
Dear Prof. Ripley and all,
Thank you very much for the pointers and the always insightful
comments. I'd like to add a few further comments below for the sake of
discussion,
On 26 May 2009, at 08:35, Prof Brian Ripley wrote:
I don't know where you get your claims from. R graphics is handled
internally in inches, with a device-specific mapping to pixels/points
etc (which is documented for each device on its help page). This has
to be done carefully, as pixels may not be square.
I saw hints of this use of inches in the code but I started off with
the wrong assumption that symbols would be in mm (partly because
ggplot2 suggested it would be so, partly because it's the natural unit
I was taught to use throughout french technical education).
What the meaning of pch=1:23 is in terms of coordinates is not
documented except via the sources.
I own Paul Murrell's R graphics book but I don't think the precise
description of the symbols' size is presented in there. Perhaps a
useful addition for the next edition?
The source is function GESymbol in
file src/main/engine.c, so for example pch = 2 is
Thank you, I failed to pinpoint this.
case 2: /* S triangle - point up */
xc = RADIUS * GSTR_0;
r = toDeviceHeight(TRC0 * xc, GE_INCHES, dd);
yc = toDeviceHeight(TRC2 * xc, GE_INCHES, dd);
xc = toDeviceWidth(TRC1 * xc, GE_INCHES, dd);
xx[0] = x; yy[0] = y+r;
xx[1] = x+xc; yy[1] = y-yc;
xx[2] = x-xc; yy[2] = y-yc;
gc-fill = R_TRANWHITE;
GEPolygon(3, xx, yy, gc, dd);
break;
which as you see is in inches, not mm as you asserted. The first line
sets xc to 0.375 inches for cex=1, for example.
You need to take the stroke width (as set by lty) into account when
assessing the visual size of symbols
Altering the implementation is definitely way out of my league, but
I'm glad I learned where to find this piece of information should the
need come in the future.
On Mon, 25 May 2009, baptiste auguie wrote:
Dear all,
Having received no answer in r-help I'm trying r-devel (hoping this
is not a
stupid question).
I don't understand the rationale behind the absolute sizes of the
point
symbols, and I couldn't find it documented (I got lost in the C code
graphics.c and gave up).
You are expected to study the sources for yourself. That's part of
the price of R.
There is a manual, 'R Internals', that would have explained to you
that graphics.c is part of base graphics and hence not of grid
graphics.
R is a big project, and these implementation details can be hard to
track down for non-programmers of my sort. That's why I was hoping for
some hints on r-help first. In particular, it's not clear to me
whether base graphics and grid graphics share these sort of
primitive pieces of code. I'll have to read R internals.
As a last note, I'd like to share this idea I've contemplated recently
(currently implementing it at the R level for ggplot2),
The points() symbols (well, rather the par() function, presumably)
could gain an attribute 'type', say, with a few options:
- 'old' for backward compatibility, this choice would set the symbols
to use to the current values in the same way that palette() provides a
default set of colours.
- 'polygons', could provide the user with a set of regular polygons
ordered by the number of vertices (3 to 6 and circle, for instance)
with a consistent set of attributes (all having col and fill
parameters). These could be complemented by starred versions of the
polygons to make for a larger set of shapes.
Such a design could provide several benefits over the current
situation, 1) the possible mapping between symbols and data could be
more straight-forward (in the spirit of the ggplot2 package), 2) the
symbol size could be made consistent either with a constant area or a
constant circumscribing circle, thereby conforming with the idea that
information should minimise visual artefacts in displaying the data
(I'm not saying this is the case currently, but I feel it may not be
optimum.).
- perhaps something else --- TeachingDemos has some interesting
examples in the my.symbols help page.
Thanks again,
baptiste
The example below uses
Grid to check the size of the symbols against a square of 10mm x
10mm.
checkOneSymbol - function(pch=0){
gTree(children=gList(
rectGrob(0.5, 0.5, width=unit(10, mm), height=unit(10,
mm),
gp=gpar(lty=2, fill=NA, col=alpha(black, 0.5))),
pointsGrob(0.5, 0.5, size=unit(10, mm),pch=pch,
gp=gpar(col=alpha(red, 0.5)))
))
}
all.symbols - lapply(0:23, checkOneSymbol)
pdf(symbols.pdf, height=1.2/2.54, width=24.2/2.54)
vp - viewport(width=0.5, height=0.5, name=main)
pushViewport(vp)
pushViewport(viewport(layout=grid.layout(1, 24,
widths=unit(10, mm),
heights=unit(10, mm
