[Rd] R Lapack – why a subset?

[Baptiste Auguie]

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

[Rd] documentation / warning when passing a vector as lower/upper bound in stats::integrate()

[Baptiste Auguie]

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

[Baptiste Auguie]

On 24 May 2015 at 14:01, Duncan Murdoch  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] NEWS.md support on CRAN

[Baptiste Auguie]

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  wrote:

> On 23/05/2015 9:25 AM, Gábor Csárdi wrote:
> > On Sat, May 23, 2015 at 8:14 AM, Duncan Murdoch
> > 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] r wiki

[Baptiste Auguie]

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 
wrote:

> > Philippe Grosjean 
> > 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
> >  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
> >>  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  Web: http://yihui.name
> >>>
> >>>
> >>> On Mon, Sep 8, 2014 at 12:10 PM, Philippe GROSJEAN
> >>>  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 thi

Re: [Rd] Where to put package vignettes

[baptiste auguie]

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

[baptiste auguie]

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. wrote:

> 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

Re: [Rd] formals() adds 0 to complex function arguments

[baptiste auguie]

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

[Rd] formals() adds 0 to complex function arguments

[baptiste auguie]

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] Straight-quotes for usage and examples sections in PDF docs?

[baptiste auguie]

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  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] I wish xlim=c(0, NA) would work. How about I send you a patch?

[baptiste auguie]

Hi,

Using range wouldn't help if you wanted to restrict one of the limits,
not stretch it

plot(1:11, y <- seq(-5, 5), ylim= range(0, y))

baptiste

On 17 April 2012 08:20, Greg Snow <538...@gmail.com> wrote:
> The simple work around is to use the range function, if you use
> something like:  xlim=range(0,x) then 0 will be included in the range
> of the x axis (and if there are values less than 0 then those values
> will be included as well) and the max is computed from the data as
> usual.  The range function will also accept multiple vectors and make
> the range big enough to include all of them on the plot (this is what
> I use when I will be adding additional information using points or
> lines).
>
> With this functionality in range I don't really see much need for the
> proposed change, maybe an example on the plot help page to show this
> would suffice.
>
> On Mon, Apr 16, 2012 at 11:52 AM, Paul Johnson  wrote:
>> I'm looking for an R mentor.  I want to propose a change in management
>> of plot options xlim and ylim.
>>
>> Did you ever want to change one coordinate in xlim or ylim? It happens
>> to me all the time.
>>
>> x <- rnorm(100, m=5, s=1)
>> y <- rnorm(100, m=6, s=1)
>> plot(x,y)
>>
>> ## Oh, I want the "y axis" to show above x=0.
>>
>> plot(x,y, xlim=c(0, ))
>>
>> ##Output: Error in c(0, ) : argument 2 is empty
>>
>>  plot(x,y, xlim=c(0,NA ))
>> ## Output: Error in plot.window(...) : need finite 'xlim' values
>>
>>
>> I wish that plot would let me supply just the min (or max) and then
>> calculate the other value where needed.
>> It is a little bit tedious for the user to do that for herself.  The
>> user must be knowledgeable enough to know where the maximum (MAX) is
>> supposed to be, and then supply xlim=c(0, MAX). I can't see any reason
>> for insisting users have that deeper understanding of how R calculates
>> ranges for plots.
>>
>> Suppose the user is allowed to supply NA to signal R should fill in the 
>> blanks.
>>
>> plot(x,y, xlim=c(0, NA))
>>
>>
>> In plot.default now, I find this code to manage xlim
>>
>>   xlim <- if (is.null(xlim))
>>        range(xy$x[is.finite(xy$x)])
>>
>> And I would change it to be something like
>>   ##get default range
>>   nxlim <- range(xy$x[is.finite(xy$x)])
>>
>>   ## if xlim is NULL, so same as current
>>    xlim <- if (is.null(xlim)) nxlim
>> ## Otherwise, replace NAs in xlim with values from nxlim
>>    else xlim[ is.na(xlim) ] <- nxlim[ is.na(xlim) ]
>>
>>
>> Who is the responsible party for plot.default.  How about it?
>>
>> Think of how much happier users would be!
>>
>> pj
>> --
>> Paul E. Johnson
>> Professor, Political Science    Assoc. Director
>> 1541 Lilac Lane, Room 504     Center for Research Methods
>> University of Kansas               University of Kansas
>> http://pj.freefaculty.org            http://quant.ku.edu
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Gregory (Greg) L. Snow Ph.D.
> 538...@gmail.com
>
> __
> 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

[baptiste auguie]

+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  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

[baptiste auguie]

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

[baptiste auguie]

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

[baptiste auguie]

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.

[baptiste auguie]

Hi,

On 5 May 2011 02:56, Duncan Murdoch  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  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 Ellis  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

[baptiste auguie]

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

[baptiste auguie]

On 27 April 2011 11:06, 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
>

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

[baptiste auguie]

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

Re: [Rd] gList and gTree methods of grid::grobX

[baptiste auguie]

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

[Rd] gList and gTree methods of grid::grobX

[baptiste auguie]

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] using rasterImage within image

[baptiste auguie]

On 14 February 2011 18:26, Ben Bolker  wrote:
> Paul Murrell  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

[baptiste auguie]

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  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
>>  wrote:
>>>
>>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>>>
 On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
  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

[baptiste auguie]

Hi,

I was recently given some interesting tips on a similar issue, see
R-help "puzzle with integrate over infinite range"


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

[baptiste auguie]

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

[baptiste auguie]

Hi,

Thanks for the follow-up.

On 2 October 2010 09:33, Deepayan Sarkar  wrote:
> On Fri, Oct 1, 2010 at 12:17 AM, baptiste auguie
>  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

[baptiste auguie]

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

[baptiste auguie]

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

[baptiste auguie]

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

[baptiste auguie]

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?

[baptiste auguie]

Hi,

I submitted a bug report today.

On 17 April 2010 22:34, Simon Urbanek  wrote:
> On Apr 17, 2010, at 2:43 PM, baptiste auguie wrote:
>
>> Hi,
>>
>> On 17 April 2010 18:51, Simon Urbanek  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"]
>&g

Re: [Rd] grid.cap() requires more time?

[baptiste auguie]

Hi,

On 17 April 2010 18:51, Simon Urbanek  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] grid.cap() requires more time?

[baptiste auguie]

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

[Rd] grid.cap() requires more time?

[baptiste auguie]

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] R logo as SVG ?

[baptiste auguie]

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  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 ?

[baptiste auguie]

On 21 February 2010 14:48, Barry Rowlingson
 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)

[baptiste auguie]

Dear all,

Running this minimal example,

library(grid)
postscript("test-123456.eps")
grid.newpage()
grid.lines(gp=gpar(lty="123456", lineend = "butt"))
dev.off()

produces eps output with the following setdash description towards the
end of the file,

## [ 0.00 3.00 2.00 5.00 4.00 7.00] 0 setdash

I consulted the postscript reference manual (page 667 *), which
indicates that the array should rather be [1 2 3 4 5 6] as intended
(and as produced by, e.g., quartz())

(*): http://www.adobe.com/products/postscript/pdfs/PLRM.pdf

Regards,

baptiste

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] incorrect linetype with pdf device (PR#14128)

[baptiste auguie]

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

[baptiste auguie]

Hi,

[my message below is a bit off-topic]

2009/12/14 Paul Murrell :

> 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 quartz device (PR#14129)

[baptiste . auguie]

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] incorrect linetype with pdf device (PR#14128)

[baptiste . auguie]

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] lty parameter not respected by pdf device

[baptiste auguie]

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

[baptiste auguie]

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 :
> 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)
>> de

Re: [Rd] raster support in graphics devices

[baptiste auguie]

Hi,

2009/12/6 Paul Murrell :
> 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 :
>>>
>>> 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

[baptiste auguie]

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 :
> 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

[baptiste auguie]

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 :
> 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 wrote:
>
>> 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
>>
>
>        [[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

[baptiste auguie]

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 :
> 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

[baptiste auguie]

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

[baptiste auguie]

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

[baptiste auguie]

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 :
> Dear Paul and others,
>
> Thanks for the quick response.
>
> 2009/9/25 Paul Murrell :
>> 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";)
&g

Re: [Rd] unexpected behavior of `[<-` method for class unit.arithmetic

[baptiste auguie]

Dear Paul and others,

Thanks for the quick response.

2009/9/25 Paul Murrell :
> 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(un

[Rd] unexpected behavior of `[<-` method for class unit.arithmetic

[baptiste auguie]

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

[baptiste auguie]

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, wid

[Rd] Fwd: [R] size of point symbols

[baptiste auguie]

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). 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"),
   just="center")))

for(ii in 0:23){
pushViewport(viewport(layout.pos.col=ii+1, layout.pos.row=1))
grid.draw(all.symbols[[ii+1]])
upViewport(1)
}
dev.off()



What dictates the size of each symbol? (in other words, why is pch=21
a circle of radius given in inches, while pch=2 is a triangle of base
length specified  in mm and offset vertically?, etc.)

I'm trying to develop a new symbol for the ggplot2 package where the  
size is to be accurately mapped onto the data either in linear size or  
area. I was expecting a similar idea behind the choice of base  
symbols. Is this documented?


Best regards,

baptiste

_

Baptiste Auguié

School of Physics
University of Exeter
Stocker Road,
Exeter, Devon,
EX4 4QL, UK

Phone: +44 1392 264187

http://newton.ex.ac.uk/research/emag

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel