Re: [Rd] Lattice: Drawing a single contour line with a negative value fails
On 8/19/09, Thorn Thaler wrote: > Hi everybody, > > I want to add a single contourline to a levelplot. While everything works > fine if the value at which the line should be drawn is positive, there is an > error if the value is negative: > > library(lattice) > my.panel <- function(..., at, contour=FALSE, labels=NULL) { >panel.levelplot(..., at=at, contour=contour, labels=labels) >panel.contourplot(..., contour=TRUE, labels="Contour", lwd=2, > at=con) > } > > x <- y <- 1:100 > df <- expand.grid(x=x, y=y) > df$z <- apply(df, 1, function(x) >(x[1]^2+x[2]^2)*ifelse(x[1]^2+x[2]^2 < 5000, -1,1)) > col.regions <- heat.colors(50) > > # Works > con <- 1000 > levelplot(df$z~df$x+df$y, col.regions=col.regions, panel=my.panel) > > # Does not work > con <- -1000 > levelplot(df$z~df$x+df$y, col.regions=col.regions, panel=my.panel) > > I've tracked down the error to the function "cut.default", which takes an > argument "breaks", which should be "either a numeric vector of two or more > cut points or a single number (greater than or equal to 2) giving the number > of intervals into which 'x' is to be cut." > > So it seems to me that a single contourline at a positive value works > because the value is interpreted as the number of intervals, even though > there is just this single line in the resulting plot. > > What would be the correct way to add just a single contour line to a > levelplot, or is it indeed a bug? Definitely a bug. It should be easy to fix (but I haven't had time to get to it yet). Using something like con <- c(-1000, NA) seems to work though. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
On Sat, Aug 22, 2009 at 12:00:44AM +0200, Martin Maechler wrote: > I have taken up the issue now, > and after thinking, studying the source, trying to define a > 'method = ' argument, came to the conclusion that both > the implementation and documentation (and source code "self-explanation") > are easiest to program, maintain, and understand, > if I introduce explicit binary switches, > so I now propose the following R-level interface which keeps > the current behavior the default: > > >> Usage: > >> > >> identical(x, y, num.EQ = TRUE, one.NA = TRUE, attrib.asSet = TRUE) > >> > >> Arguments: > >> > >> x, y: any R objects. > >> > >> num.EQ: logical indicating if ('double' and 'complex' non-'NA') > >> numbers should be compared using '==', or by bitwise > >> comparison. The latter (non-default) differentiates between > >> '-0' and '+0'. > >> > >> one.NA: logical indicating if there is conceptually just one numeric > >> 'NA' and one 'NaN'; 'one.NA = FALSE' differentiates bit > >> patterns. > >> > >> attrib.asSet: logical indicating if 'attributes' of 'x' and 'y' should > >> be treated as _unordered_ tagged pairlists ("sets"); this > >> currently also applies to 'slot's of S4 objects. It may well > >> be too strict to set 'attrib.asSet = FALSE'. I appreciate having several binary switches. Besides the arguments above, this is also useful for an interactive use of identical(), for example, for debugging purposes. If there is a difference between objects, then the switches allow to get more information concerning what is the type of the difference. > I'm open for better names of arguments, but will not accept "_" > in the argument names {just my taste; no reason for argueing...}. I would slightly prefere one.NaN instead of one.NA. In IEEE 754 terminology, R's 'NA's are a subset of 'NaN's. So. NaN is a bit more general notion, although in R, the sets of 'NA's an 'NaN's are disjoint. Moreover, the name one.NaN specifies more clearly, that the issue is important only for numeric types and not, for example, for integer. Petr. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] more special completions
Not sure, but another example may be a class dependent completion for generic functions depending on first argument. Like print(df,... ) where df a data.frame to complete, digits = NULL, quote = FALSE, right = TRUE, row.names = TRUE instead of only (x,...). That sort of already happens (have you tried?), Oh, sorry, I have been confusing display of args list in emacs with R completions facilities. Emacs implements that directly through try(args(function). but instead of print.data.frame, it gives you arguments of all print methods (only for S3 generics though). Finding the right signature needs evaluation of the right (usually first, but not necessarily) argument, which may actually involve another function call. Inheritance makes things more complicated. I'm not sure it's worth the overhead. If custom function as Romain proposed, had an argument of all names typed after "(" (say "fArgs"), a whole range of possibilities opens up. At least one case when evaluation is not that demanding is new(); new() could generate completions for classes if fArgs is empty and completions for slots of class fArgs[1] otherwise. Not to mention that various RGuis could use this facility to generate the list of context dependent arguments for in-line functions. Wouldn't that be great?! What concerns S4 methods, findMethodSignatures is already there: require("Matrix") formals(getMethod("*", findMethodSignatures("*")[4, ])) $e1 $e2 so it seems to me (a simple user) like the main "overhead" would be to implement custom functions with fArgs argument. Vitalie -Deepayan -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
On Sat, Aug 22, 2009 at 1:22 AM, Petr Savicky wrote: > On Sat, Aug 22, 2009 at 12:00:44AM +0200, Martin Maechler wrote: >> I have taken up the issue now, >> and after thinking, studying the source, trying to define a >> 'method = ' argument, came to the conclusion that both >> the implementation and documentation (and source code "self-explanation") >> are easiest to program, maintain, and understand, >> if I introduce explicit binary switches, >> so I now propose the following R-level interface which keeps >> the current behavior the default: >> >> >> Usage: >> >> >> >> identical(x, y, num.EQ = TRUE, one.NA = TRUE, attrib.asSet = TRUE) >> >> >> >> Arguments: >> >> >> >> x, y: any R objects. >> >> >> >> num.EQ: logical indicating if ('double' and 'complex' non-'NA') >> >> numbers should be compared using '==', or by bitwise >> >> comparison. The latter (non-default) differentiates between >> >> '-0' and '+0'. >> >> >> >> one.NA: logical indicating if there is conceptually just one numeric >> >> 'NA' and one 'NaN'; 'one.NA = FALSE' differentiates bit >> >> patterns. >> >> >> >> attrib.asSet: logical indicating if 'attributes' of 'x' and 'y' should >> >> be treated as _unordered_ tagged pairlists ("sets"); this >> >> currently also applies to 'slot's of S4 objects. It may well >> >> be too strict to set 'attrib.asSet = FALSE'. My only comment is to make the argument notation a bit more consistent: (num.Eq, one.NA, attrib.as.set) or (numEq, oneNA, attribAsSet) Also, maybe "single" instead of "one". Thanks Henrik > > I appreciate having several binary switches. Besides the arguments above, > this is also useful for an interactive use of identical(), for example, > for debugging purposes. If there is a difference between objects, then > the switches allow to get more information concerning what is the type > of the difference. > >> I'm open for better names of arguments, but will not accept "_" >> in the argument names {just my taste; no reason for argueing...}. > > I would slightly prefere one.NaN instead of one.NA. In IEEE 754 terminology, > R's 'NA's are a subset of 'NaN's. So. NaN is a bit more general notion, > although in R, the sets of 'NA's an 'NaN's are disjoint. Moreover, the > name one.NaN specifies more clearly, that the issue is important only > for numeric types and not, for example, for integer. > > Petr. > > __ > 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] improving ?RweaveLatex
Dear developers Please read below. On 6/25/09, Marc Schwartz wrote: > You can use the following *after* the \begin{document} directive: > \setkeys{Gin}{width=0.8\textwidth} > > The above is the default. Reset it to what you would like. > > Note, as per that manual page, that the Sweave options 'height' and 'width' > affect the size of the PDF and EPS files created, but it is the above > command that controls the size of the image in the document itself. > Could this information be incorporate into the RweaveLatex help page? Concerning the sizes of graphs, it contains only the following information: " width: numeric (6), width of figures in inches. height: numeric (6), height of figures in inches. " Unfortunately this concise information can easily mislead into believing that these two options affect the graphs dynamically produced and included in the final .pdf file. It might help for these two sentences to specify what figures they're affecting, and also to include some info about "\setkeys{Gin}{width=0.8\textwidth}". Thank you Liviu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] improving ?RweaveLatex
On Aug 22, 2009, at 2:45 PM, Liviu Andronic wrote: Dear developers Please read below. On 6/25/09, Marc Schwartz wrote: You can use the following *after* the \begin{document} directive: \setkeys{Gin}{width=0.8\textwidth} The above is the default. Reset it to what you would like. Note, as per that manual page, that the Sweave options 'height' and 'width' affect the size of the PDF and EPS files created, but it is the above command that controls the size of the image in the document itself. Could this information be incorporate into the RweaveLatex help page? Concerning the sizes of graphs, it contains only the following information: " width: numeric (6), width of figures in inches. height: numeric (6), height of figures in inches. " Unfortunately this concise information can easily mislead into believing that these two options affect the graphs dynamically produced and included in the final .pdf file. It might help for these two sentences to specify what figures they're affecting, and also to include some info about "\setkeys{Gin}{width=0.8\textwidth}". Thank you Liviu It would also be worthwhile to include the information that Frank found on disabling the impact of this option, so that the use of the width and height arguments do actually define the plot image dimensions in the resultant document. Frank noted it here: https://stat.ethz.ch/pipermail/r-help/2009-June/202757.html The key content is: Regarding the issue of preventing Sweave from issuing the Gin option to set all graphics output to have a width of 0.8\textwidth, it's as easy as using \usepackage[nogin]{Sweave} ... After seeing Frank's reference, the only way that one would otherwise note it is to read Sweave.sty directly. In my Sweave template .Rnw file, I am now actually using the [nogin] option by default and set the plot dimensions for each figure chunk as required. Thanks Liviu for the above. HTH, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] improving ?RweaveLatex
On Aug 22, 2009, at 3:03 PM, Marc Schwartz wrote: On Aug 22, 2009, at 2:45 PM, Liviu Andronic wrote: Dear developers Please read below. On 6/25/09, Marc Schwartz wrote: You can use the following *after* the \begin{document} directive: \setkeys{Gin}{width=0.8\textwidth} The above is the default. Reset it to what you would like. Note, as per that manual page, that the Sweave options 'height' and 'width' affect the size of the PDF and EPS files created, but it is the above command that controls the size of the image in the document itself. Could this information be incorporate into the RweaveLatex help page? Concerning the sizes of graphs, it contains only the following information: " width: numeric (6), width of figures in inches. height: numeric (6), height of figures in inches. " Unfortunately this concise information can easily mislead into believing that these two options affect the graphs dynamically produced and included in the final .pdf file. It might help for these two sentences to specify what figures they're affecting, and also to include some info about "\setkeys{Gin}{width=0.8\textwidth}". Thank you Liviu It would also be worthwhile to include the information that Frank found on disabling the impact of this option, so that the use of the width and height arguments do actually define the plot image dimensions in the resultant document. Frank noted it here: https://stat.ethz.ch/pipermail/r-help/2009-June/202757.html The key content is: Regarding the issue of preventing Sweave from issuing the Gin option to set all graphics output to have a width of 0.8\textwidth, it's as easy as using \usepackage[nogin]{Sweave} ... After seeing Frank's reference, the only way that one would otherwise note it is to read Sweave.sty directly. In my Sweave template .Rnw file, I am now actually using the [nogin] option by default and set the plot dimensions for each figure chunk as required. Thanks Liviu for the above. I have some proposed modifications to RweaveLatex.Rd which I include here as a patch against the R-devel version of the file from svn. I have added comments about the issue that Liviu raised, the use of the [nogin] option and while I was at it, the [noae] option as well. There are added to the 'details' section of the file. I hope that this is helpful. Regards, Marc --- RweaveLatexOld.Rd 2009-08-22 15:45:29.0 -0500 +++ RweaveLatex.Rd 2009-08-22 16:13:54.0 -0500 @@ -49,6 +49,30 @@ \env{SWEAVE_STYLEPATH_DEFAULT}, or is \code{FALSE} it that is unset or empty. If set, it should be exactly \code{TRUE} or \code{FALSE}: any other values are taken as \code{FALSE}. + + By default, \file{Sweave.sty} sets the width of all included graphics to: + + \code{\\setkeys{Gin}{width=0.8\\textwidth}} + + You can adjust this by including the above in your .Rnw file after the + \code{\\begin{document}} directive and adjust the \code{width} + parameter above accordingly. Note that this parameter determines the actual + graphic dimensions in your final document and therefore overrides the + \code{height} and \code{width} options that you may use in each + figure chunk or have set globally. The \code{height} and \code{width} + options will determine the dimensions of the runtime generated + \code{PDF} and \code{EPS} files created in this setting. + + If you wish to override this default behavior, you can use + \code{\\usepackage[nogin]{Sweave}} in your preamble. In this case, the + \code{height} and \code{width} options will determine the runtime + generated graphic file sizes and the size of the graphics in your + final document. + + \file{Sweave.sty} also supports the \code{[noae]} option, which + suppresses that use of the \code{ae} package, the use of which may + interfere with certain encoding and typeface selections. If you have + problems in the rendering of certain character sets, try this option. } \section{Supported Options}{ \code{RweaveLatex} supports the following options for code chunks (the values __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] improving ?RweaveLatex
On Aug 22, 2009, at 4:30 PM, Marc Schwartz wrote: I have some proposed modifications to RweaveLatex.Rd which I include here as a patch against the R-devel version of the file from svn. I have added comments about the issue that Liviu raised, the use of the [nogin] option and while I was at it, the [noae] option as well. There are added to the 'details' section of the file. OK, once more I noted a typo and also neglected to add pointers to the Details section in the descriptions of the height and width options. Here is a corrected version of the patch file. Marc --- RweaveLatexOld.Rd 2009-08-22 15:45:29.0 -0500 +++ RweaveLatex.Rd 2009-08-22 16:49:00.0 -0500 @@ -49,6 +49,30 @@ \env{SWEAVE_STYLEPATH_DEFAULT}, or is \code{FALSE} it that is unset or empty. If set, it should be exactly \code{TRUE} or \code{FALSE}: any other values are taken as \code{FALSE}. + + By default, \file{Sweave.sty} sets the width of all included graphics to: + + \code{\\setkeys{Gin}{width=0.8\\textwidth}} + + You can adjust this by including the above in your .Rnw file after the + \code{\\begin{document}} directive and adjust the \code{width} + parameter above accordingly. Note that this parameter determines the actual + graphic dimensions in your final document and therefore overrides the + \code{height} and \code{width} options that you may use in each + figure chunk or have set globally. The \code{height} and \code{width} + options will determine the dimensions of the runtime generated + PDF and EPS files created in this setting. + + If you wish to override this default behavior, you can use + \code{\\usepackage[nogin]{Sweave}} in your preamble. In this case, the + \code{height} and \code{width} options will determine the runtime + generated graphic file sizes and the size of the graphics in your + final document. + + \file{Sweave.sty} also supports the \code{[noae]} option, which + suppresses the use of the \code{ae} package, the use of which may + interfere with certain encoding and typeface selections. If you have + problems in the rendering of certain character sets, try this option. } \section{Supported Options}{ \code{RweaveLatex} supports the following options for code chunks (the values @@ -101,8 +125,8 @@ generated. Ignored if \code{fig = FALSE}.} \item{pdf.version, pdf.encoding:}{passed to \code{\link{pdf}} to set the version and encoding. Defaults taken from \code{pdf.options()}.} -\item{width:}{numeric (6), width of figures in inches.} -\item{height:}{numeric (6), height of figures in inches.} +\item{width:}{numeric (6), width of figures in inches. See \sQuote{Details}.} +\item{height:}{numeric (6), height of figures in inches. See \sQuote{Details}.} \item{expand:}{logical (\code{TRUE}). Expand references to other chunks so that only R code appears in the output file. If \code{FALSE}, the chunk reference (e.g. \code{<>}) will appear. The __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel