[Rd] R Lapack – why a subset?

Hi, Why doesn't R include a full Lapack but only a subset? My cda package (now archived) relying on RcppArmadillo has broken multiple times on CRAN over the past few years following updates in the underlying Armadillo library, Every time it follows the same pattern: Armadillo adds a function to s

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

Dear R-dev list, I wonder if stats::integrate shouldn't warn the user when a numeric vector of length > 1 is passed as lower or upper bounds. If a vector is passed, only the first value is used and the others are silently ignored: integrate(sin, lower=0, upper=pi) integrate(sin, lower=0:10, upper

Re: [Rd] NEWS.md support on CRAN

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 o

Re: [Rd] NEWS.md support on CRAN

John MacFarlane, the author of Pandoc, has been working on a project ( http://commonmark.org/) to define a standard reference for Markdown*. There are already two reference implementations, one in javascript, the other in C: https://github.com/jgm/cmark Regards, baptiste * There was some initia

Re: [Rd] r wiki

One small technical issue currently limiting the deployment of true reproducible wikis based on knitr + github-markdown is the lack of reverse synchronisation between the rendered output (markdown), edited online, and the original Rmd source. It think the combination of wiki features + reproducible

Re: [Rd] Where to put package vignettes

Hi, You should take the following steps: 1) upgrade R, 2) specify VignetteBuilder: knitr in your DESCRIPTION file, 3) check how other CRAN packages using knitr do it (e.g. knitr itself). No makefile is needed, that was a temporary workaround, now irrelevant. HTH, baptiste On 20 February 2014

Re: [Rd] Package checking: verifying plots

Hi, Winston Chang designed the vtest package for a similar purpose, https://github.com/wch/ggplot2/wiki/Visual-test-system https://github.com/wch/vtest I don't know if / how well it works outside the ggplot2 framework, but it's pretty slick. HTH, baptiste On 22 January 2014 11:35, Therneau

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

Thank you Peter and Duncan, for the explanation and discussion. As for a workaround, I think it is more readable to define, test <- function(a = complex(real=1, imaginary=2)){} Best regards, baptiste On 19 January 2014 18:45, Duncan Murdoch wrote: > On 14-01-19 4:16 PM, peter dalgaard wrote

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

Dear list, I'm facing an issue with the automated documentation of a function using roxygen2. The function has a complex-valued default argument, which is picked up by roxygen2 using formals() to generate the corresponding Usage section of the Rd file. Unfortunately, it appears that formals() refo

Re: [Rd] Straight-quotes for usage and examples sections in PDF docs?

There's a trivial variation named Inconsolata-dz, http://nodnod.net/2009/feb/12/adding-straight-single-and-double-quotes-inconsola/ which I've used happily with XeTeX; maybe R can use it in place of the original if you rename it Inconsolata, but that would presumably be against the font licence. b

Re: [Rd] I wish xlim=c(0, NA) would work. How about I send you a patch?

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

Re: [Rd] Please explain your workflow from R code -> package -> R code -> package

+1 for roxygen2, lazycoolness oblige. An alternative that has not been mentioned is inlinedocs, http://inlinedocs.r-forge.r-project.org/ I don't use it myself, but it might appeal to your workflow. baptiste On 10 September 2011 06:41, Hadley Wickham wrote: >> | In other languages, I've seen to

Re: [Rd] one way to solve bad looking density plots in postscript

Hi, I was going to suggest panel.last to redraw a box around the image, but for some reason it does not seem to come after the image neither (this is perhaps to be expected from the note in ?plot.default). plot(1,1, panel.last={box(lwd=50, col="#FF")}) image(volcano, panel.last={box(lwd=50,

Re: [Rd] package encoding warning

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

[Rd] package encoding warning

Dear list, I'd like to get rid off a couple of warnings that have appeared in checking my package on CRAN (I did not find them on my local machine before submission). What puzzles me is that different platforms return different warnings, only one of which I recognise as my obvious mistake. The che

Re: [Rd] Curry: proposed new functional programming, er, function.

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

Re: [Rd] grid stringHeight

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

Re: [Rd] grid stringHeight

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

[Rd] grid stringHeight

Dear all, I'm puzzled by the behavior of stringHeight in the grid package. Consider the following test, library(grid) test <- function(lab="dog", ...){ g1 <- textGrob(lab) g2 <- rectGrob(height=grobHeight(g1), width=grobWidth(g1)) gg <- gTree(children=gList(g1,g2), ...) print(c("height:

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

Hi, Thanks for the clarification. Perhaps something along those lines could be added to the help page. Regards, baptiste On 15 February 2011 19:51, Paul Murrell wrote: > Hi > > baptiste auguie wrote: >> >> Dear all, >> >> In an attempt to draw fill

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

Dear all, In an attempt to draw fill patterns in grid graphics, I have encountered a behavior of grobX that I cannot understand from the documentation. Consider this, library(grid) ## gTree g1 <- gTree(children=gList( rectGrob(0.5,0.5, width=unit(0.8,"npc"), he

Re: [Rd] using rasterImage within image

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

Re: [Rd] using rasterImage within image

Dear all, Back when grid.raster() was introduced, it was suggested that perhaps grid.rect() could use grid.raster() in case of even spacing. The response at the time was that it would be best to keep the two functions separate at a lower level, that is grid.rect() and grid.raster(), but perhaps a

Re: [Rd] 0.5 != integrate(dnorm,0,20000) = 0

Hi, I was recently given some interesting tips on a similar issue, see R-help "puzzle with integrate over infinite range" Maybe "fails" can be a bit misleading here (fails to produce the actual result vs. returning an error message). As a result of this

Re: [Rd] Roxygen: @example tag does not work for me

Hi, I think you could achieve this using the brew package. Define a function that reads your external example file, and have brew insert the resulting string in your script, which can then be processed by roxygen. I'm curious to hear other suggestions, but I doubt it could work out-of-the-box lik

Re: [Rd] strange interaction between rasterImage and Grid graphics

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

[Rd] strange interaction between rasterImage and Grid graphics

Dear all, This may be specific to Mac, I haven't had a chance to test another platform. Consider this, plot(1,1,t="n") rasterImage(matrix(1),1,1,1,1) library(grid) grid.rect(gp=gpar(fill="grey")) The grid.rect covers the full device window as expected. However, when I resize the window ever so s

Re: [Rd] Automatically retrieve correct collation

Hi, roxygen can create the collate field for you, if you specify the dependencies in the commented code. I've never tested it with S4 classes though. HTH, baptiste On 18 August 2010 22:28, Janko Thyson wrote: > Dear List, > > consider the following scenario: > > setClass(Class = "A", represent

Re: [Rd] gpar fill and transparency on devices

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., ba

[Rd] gpar fill and transparency on devices

Dear list, I'm puzzled by the graphical output in the following example, library(grid) foo <- function(){ grid.rect(gp=gpar(fill="black")) print(get.gpar()$fill) grid.rect(width=0.2,height=0.2) } png("test.png", bg = "transparent") foo() dev.off() png("test1.png", bg = "white") foo() dev

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

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 mail

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

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

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

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 int

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

Dear all, I am puzzled by the following behavior of the new grid.cap() function, which appears to run out of time when capturing the output of a graphic. It works fine if I introduce a Sys.sleep(1) before executing more code, library(grid) quartz() grid.circle(gp=gpar(fill="black")) gg <- grid.c

Re: [Rd] R logo as SVG ?

You got the first two letters right, but it's actually *Barry*'s work! As a matter of personal taste, I like the 3D rendering of the current logo; my only wish would be for an open source to reproduce it. baptiste On 27 February 2010 19:55, Jens Elkner wrote: > BTW: What do you think about Bap

Re: [Rd] R logo as SVG ?

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

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

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

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

Dear list, A small follow up on this issue. The same behavior is observed for postscript() and pdf(), so I suspect the erroneous code is in grDevices/src/devPS.c. In particular, this macro, static void PostScriptSetLineTexture(FILE *fp, const char *dashlist, int nlty, double lwd) { /* use same ma

Re: [Rd] raster support in graphics devices

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

[Rd] incorrect linetype with quartz device (PR#14129)

Full_Name: baptiste auguié Version: 2.10.1 RC (2009-12-06 r50690) OS: Mac OSX 10.5 Submission from: (NULL) (90.25.215.172) The quartz() device, either in interactive use or with pdf file output, produces an incorrect dashed line when the data is dense. Consider the following comparison between q

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

Full_Name: baptiste auguié Version: 2.10.1 RC (2009-12-06 r50690) OS: Mac OSX 10.5 Submission from: (NULL) (90.25.215.172) The following code, run with a vanilla R session, produces different visual output for the two devices, library(grid) pdf("test-pdf.pdf") grid.newpage() grid.lines(gp=gpar

[Rd] lty parameter not respected by pdf device

Dear all, Several of us ggplot2 users noticed the disappearance of some dashed lines in the pdf output produced with the pdf device. They looked fine on screen or with quartz() output. When opening the file with Illustrator I noted that the missing line was in fact present, but with a dashed patte

Re: [Rd] raster support in graphics devices

milar 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

Re: [Rd] raster support in graphics devices

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 bot

Re: [Rd] raster support in graphics devices

Dear all, It seems to me that grid.raster is a special case of grid.rect as far as the intended visual output is concerned. The example below illustrates how both can be used to produce an image of the volcano data, d <- volcano cols <- grey(t(d)/max(c(d))) xy <- expand.grid(x=seq(0, 1, length=n

Re: [Rd] raster support in graphics devices

Hi, You can use grid.cap, x11() plot(1:10) g = grid.cap() dev.off() str(g) # chr [1:672, 1:671] "white" "white" "white" "white" "white" ... but as far as I understand in ?grid.cap and the underlying code there is no "capGrob" equivalent that wouldn't require opening a new device before capturing

Re: [Rd] raster support in graphics devices

Very nice, thank you for this great addition to R graphics! I can't wait to see lattice and ggplot2 functions that use rasterGrob to display images. The pdf output is so much better in every way! Incidentally, I ran into a segfault with grid.cap on the quartz device, but maybe it's normal at this

Re: [Rd] how to document stuff most users don't want to see

If help was only displayed in the form of html pages, one could perhaps mimic the javascript trick sometimes found in wikipedia, e.g. "http://en.wikipedia.org/wiki/Mathematical_induction#Example"; (see the "show/hide" toggle at the bottom). I don't see how this could work with plain text or pdf ou

[Rd] puzzle with drawDetails for a class derived from a gTree

Dear all, I've tried all sorts of variations discussed in "R graphics" by Paul Murrell, but I still can't understand how to write a drawDetails method for a class derived from a gTree. Below is a minimal, dummy example where two strings are plotted in two separate viewports. I require the creation

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

it.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 othe

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

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

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

Dear list, Consider the following, library(grid) w = unit.c(unit(1, "in"), unit(2, "in")) w2 = w + unit(1, "mm") w[2] <- 0 w2[2] <- 0 convertUnit(w, "mm") #[1] 25.4mm 0mm convertUnit(w2, "mm") #Error in grid.Call("L_convert", x, as.integer(whatfrom), as.integer(whatto), : # INTEGER() can onl

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

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 2

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

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 u