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
