Re: [Rd] "open-ended" plot limits?
Thanks, everyone, for all the responses! Ted. On 05-Feb-09 20:48:33, Ted Harding wrote: > Hi Folks, > Maybe I've missed it already being available somehow, > but if the following isn't available I'd like to suggest it. > > If you're happy to let plot() choose its own limits, > then of course plot(x,y) will do it. > > If you know what limits you want, then > plot(x,y,xlim=c(x0,x1),ylim(y0,y1) > will do it. > > But sometimes one would like to > a) make sure that (e.g.) the y-axis has a lower limit (say) 0 > b) let plot() choose the upper limit. > > In that case, something like > > plot(x,y,ylim=c(0,NA)) > > would be a natural way of specifying it. But of course that > does not work. > > I would like to suggest that this possibility should be available. > What do people think? > > Best wishes, > Ted. > > > E-Mail: (Ted Harding) > Fax-to-email: +44 (0)870 094 0861 > Date: 05-Feb-09 Time: 20:48:30 > -- XFMail -- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel E-Mail: (Ted Harding) Fax-to-email: +44 (0)870 094 0861 Date: 05-Feb-09 Time: 23:08:25 -- XFMail -- E-Mail: (Ted Harding) Fax-to-email: +44 (0)870 094 0861 Date: 06-Feb-09 Time: 00:21:44 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "open-ended" plot limits?
Or use range( 0, y1, y2, y3, na.rm=TRUE, finite=TRUE ) -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 > -Original Message- > From: William Dunlap [mailto:wdun...@tibco.com] > Sent: Thursday, February 05, 2009 2:38 PM > To: Greg Snow; marc_schwa...@comcast.net; ted.hard...@manchester.ac.uk > Cc: R-Devel > Subject: RE: [Rd] "open-ended" plot limits? > > > > -Original Message- > > From: r-devel-boun...@r-project.org > > [mailto:r-devel-boun...@r-project.org] On Behalf Of Greg Snow > > Sent: Thursday, February 05, 2009 1:15 PM > > To: marc_schwa...@comcast.net; ted.hard...@manchester.ac.uk > > Cc: R-Devel > > Subject: Re: [Rd] "open-ended" plot limits? > > > > I use range( 0, y ) rather than c(0, max(y)), that way if > > there are any y values less than 0, the limits still include > > them (and it is slightly shorter :-). > > To mimic what plot does by default you must ignore the NA's > and Inf's in y with something like >range(0,y[is.finite(y)]) > It might be nice to have an na.rm-like argument for ignoring > the Inf's - it gets tedious to write >range(0, y1[!is.finite(y1)], y2[!is.finite(y2)], ...) > Also, when you get into really long vectors the explicit subscripting > can run you out of memory. > > Bill Dunlap > TIBCO Software Inc - Spotfire Division > wdunlap tibco.com > > > > > This also extends to cases where you may know that you will > > be adding additional data using points or lines, so you can > > do ylim=range(0, y1, y2, y3) and it will give enough room to > > add the other y variables in latter. > > > > Hope this helps, > > > > -- > > Gregory (Greg) L. Snow Ph.D. > > Statistical Data Center > > Intermountain Healthcare > > greg.s...@imail.org > > 801.408.8111 > > > > > > > -Original Message- > > > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r- > > > project.org] On Behalf Of Marc Schwartz > > > Sent: Thursday, February 05, 2009 1:57 PM > > > To: ted.hard...@manchester.ac.uk > > > Cc: R-Devel > > > Subject: Re: [Rd] "open-ended" plot limits? > > > > > > on 02/05/2009 02:48 PM (Ted Harding) wrote: > > > > Hi Folks, > > > > Maybe I've missed it already being available somehow, > > > > but if the following isn't available I'd like to suggest it. > > > > > > > > If you're happy to let plot() choose its own limits, > > > > then of course plot(x,y) will do it. > > > > > > > > If you know what limits you want, then > > > > plot(x,y,xlim=c(x0,x1),ylim(y0,y1) > > > > will do it. > > > > > > > > But sometimes one would like to > > > > a) make sure that (e.g.) the y-axis has a lower limit (say) 0 > > > > b) let plot() choose the upper limit. > > > > > > > > In that case, something like > > > > > > > > plot(x,y,ylim=c(0,NA)) > > > > > > > > would be a natural way of specifying it. But of course that > > > > does not work. > > > > > > > > I would like to suggest that this possibility should be > available. > > > > What do people think? > > > > > > > > Best wishes, > > > > Ted. > > > > > > Ted, > > > > > > Unless I am mistaken in what you are looking for: > > > > > > plot(x, y, ylim = c(0, max(y))) > > > > > > would seem do what you want. If otherwise unspecified, plot() uses > > > range(y) to define 'ylim'. > > > > > > HTH, > > > > > > Marc Schwartz > > > > > > __ > > > 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] "open-ended" plot limits?
> -Original Message- > From: r-devel-boun...@r-project.org > [mailto:r-devel-boun...@r-project.org] On Behalf Of Greg Snow > Sent: Thursday, February 05, 2009 1:15 PM > To: marc_schwa...@comcast.net; ted.hard...@manchester.ac.uk > Cc: R-Devel > Subject: Re: [Rd] "open-ended" plot limits? > > I use range( 0, y ) rather than c(0, max(y)), that way if > there are any y values less than 0, the limits still include > them (and it is slightly shorter :-). To mimic what plot does by default you must ignore the NA's and Inf's in y with something like range(0,y[is.finite(y)]) It might be nice to have an na.rm-like argument for ignoring the Inf's - it gets tedious to write range(0, y1[!is.finite(y1)], y2[!is.finite(y2)], ...) Also, when you get into really long vectors the explicit subscripting can run you out of memory. Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com > > This also extends to cases where you may know that you will > be adding additional data using points or lines, so you can > do ylim=range(0, y1, y2, y3) and it will give enough room to > add the other y variables in latter. > > Hope this helps, > > -- > Gregory (Greg) L. Snow Ph.D. > Statistical Data Center > Intermountain Healthcare > greg.s...@imail.org > 801.408.8111 > > > > -Original Message- > > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r- > > project.org] On Behalf Of Marc Schwartz > > Sent: Thursday, February 05, 2009 1:57 PM > > To: ted.hard...@manchester.ac.uk > > Cc: R-Devel > > Subject: Re: [Rd] "open-ended" plot limits? > > > > on 02/05/2009 02:48 PM (Ted Harding) wrote: > > > Hi Folks, > > > Maybe I've missed it already being available somehow, > > > but if the following isn't available I'd like to suggest it. > > > > > > If you're happy to let plot() choose its own limits, > > > then of course plot(x,y) will do it. > > > > > > If you know what limits you want, then > > > plot(x,y,xlim=c(x0,x1),ylim(y0,y1) > > > will do it. > > > > > > But sometimes one would like to > > > a) make sure that (e.g.) the y-axis has a lower limit (say) 0 > > > b) let plot() choose the upper limit. > > > > > > In that case, something like > > > > > > plot(x,y,ylim=c(0,NA)) > > > > > > would be a natural way of specifying it. But of course that > > > does not work. > > > > > > I would like to suggest that this possibility should be available. > > > What do people think? > > > > > > Best wishes, > > > Ted. > > > > Ted, > > > > Unless I am mistaken in what you are looking for: > > > > plot(x, y, ylim = c(0, max(y))) > > > > would seem do what you want. If otherwise unspecified, plot() uses > > range(y) to define 'ylim'. > > > > HTH, > > > > Marc Schwartz > > > > __ > > 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] "open-ended" plot limits?
I use range( 0, y ) rather than c(0, max(y)), that way if there are any y values less than 0, the limits still include them (and it is slightly shorter :-). This also extends to cases where you may know that you will be adding additional data using points or lines, so you can do ylim=range(0, y1, y2, y3) and it will give enough room to add the other y variables in latter. Hope this helps, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 > -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r- > project.org] On Behalf Of Marc Schwartz > Sent: Thursday, February 05, 2009 1:57 PM > To: ted.hard...@manchester.ac.uk > Cc: R-Devel > Subject: Re: [Rd] "open-ended" plot limits? > > on 02/05/2009 02:48 PM (Ted Harding) wrote: > > Hi Folks, > > Maybe I've missed it already being available somehow, > > but if the following isn't available I'd like to suggest it. > > > > If you're happy to let plot() choose its own limits, > > then of course plot(x,y) will do it. > > > > If you know what limits you want, then > > plot(x,y,xlim=c(x0,x1),ylim(y0,y1) > > will do it. > > > > But sometimes one would like to > > a) make sure that (e.g.) the y-axis has a lower limit (say) 0 > > b) let plot() choose the upper limit. > > > > In that case, something like > > > > plot(x,y,ylim=c(0,NA)) > > > > would be a natural way of specifying it. But of course that > > does not work. > > > > I would like to suggest that this possibility should be available. > > What do people think? > > > > Best wishes, > > Ted. > > Ted, > > Unless I am mistaken in what you are looking for: > > plot(x, y, ylim = c(0, max(y))) > > would seem do what you want. If otherwise unspecified, plot() uses > range(y) to define 'ylim'. > > HTH, > > Marc Schwartz > > __ > 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] "open-ended" plot limits?
On 2/5/2009 3:48 PM, (Ted Harding) wrote: Hi Folks, Maybe I've missed it already being available somehow, but if the following isn't available I'd like to suggest it. If you're happy to let plot() choose its own limits, then of course plot(x,y) will do it. If you know what limits you want, then plot(x,y,xlim=c(x0,x1),ylim(y0,y1) will do it. But sometimes one would like to a) make sure that (e.g.) the y-axis has a lower limit (say) 0 b) let plot() choose the upper limit. In that case, something like plot(x,y,ylim=c(0,NA)) would be a natural way of specifying it. But of course that does not work. I would like to suggest that this possibility should be available. What do people think? I'd rather not assume NA is intentional since there are so many unintentional ways to generate it. Marc told you the simple workaround to get the effect you want. Duncan Murdoch Best wishes, Ted. E-Mail: (Ted Harding) Fax-to-email: +44 (0)870 094 0861 Date: 05-Feb-09 Time: 20:48:30 -- XFMail -- __ 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] "open-ended" plot limits?
on 02/05/2009 02:48 PM (Ted Harding) wrote: > Hi Folks, > Maybe I've missed it already being available somehow, > but if the following isn't available I'd like to suggest it. > > If you're happy to let plot() choose its own limits, > then of course plot(x,y) will do it. > > If you know what limits you want, then > plot(x,y,xlim=c(x0,x1),ylim(y0,y1) > will do it. > > But sometimes one would like to > a) make sure that (e.g.) the y-axis has a lower limit (say) 0 > b) let plot() choose the upper limit. > > In that case, something like > > plot(x,y,ylim=c(0,NA)) > > would be a natural way of specifying it. But of course that > does not work. > > I would like to suggest that this possibility should be available. > What do people think? > > Best wishes, > Ted. Ted, Unless I am mistaken in what you are looking for: plot(x, y, ylim = c(0, max(y))) would seem do what you want. If otherwise unspecified, plot() uses range(y) to define 'ylim'. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "open-ended" plot limits?
Hi Folks, Maybe I've missed it already being available somehow, but if the following isn't available I'd like to suggest it. If you're happy to let plot() choose its own limits, then of course plot(x,y) will do it. If you know what limits you want, then plot(x,y,xlim=c(x0,x1),ylim(y0,y1) will do it. But sometimes one would like to a) make sure that (e.g.) the y-axis has a lower limit (say) 0 b) let plot() choose the upper limit. In that case, something like plot(x,y,ylim=c(0,NA)) would be a natural way of specifying it. But of course that does not work. I would like to suggest that this possibility should be available. What do people think? Best wishes, Ted. E-Mail: (Ted Harding) Fax-to-email: +44 (0)870 094 0861 Date: 05-Feb-09 Time: 20:48:30 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] no visible binding for global variable
Everyone,
I know that this has been discussed a few times on the list, but I
think that there is a high false positive rate of messages from
findGlobals during R CMD check (I know the help page has that "The
result is an approximation").
Here are two examples of from the caret package:
This function get the message "predictors.gbm: no visible binding for
global variable 'rel.inf'"
predictors.gbm <- function(x, ...)
{
library(gbm)
varList <- if(hasTerms(x)) predictors(x$terms) else colnames(x$data$x.order)
relImp <- summary(x, plotit = FALSE)
varUsed <- as.character(subset(relImp, rel.inf != 0)$var)
basicVars(varList, varUsed)
}
So it didn't take the context into account that subset isn't
(necessarily) looking in the global environment.
Also, the package has a file splsda.R that has the message
"splsda.default: no visible binding for global variable 'ncomp'". The
oddness of this one is that there is no variable named ncomp
explicitly mentioned in the file (confirmed by grep and I checked that
the function wasn't accidentally defined twice).
In fairness, this function has caught little issues in my code that
could have led to issues, so I'm certainly not implying that it is
ineffective. Looking through the page with package check results,
there are a lot of packages with these types of notes and it makes me
wonder how many of them are real issues. Of course they are only
notes, but the extra verboseness might make people not pay as much
attention when a big issues arises.
Thanks
Max
> sessionInfo()
R version 2.9.0 Under development (unstable) (2009-01-22 r47686)
i386-apple-darwin9.6.0
locale:
en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] codetools_0.2-1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Multiple-Line Comment (PR#13503)
(no cc to r-bugs)
One obvious work around is to use an editor that lets you comment/
uncomment many lines of code at once. ESS/Emacs for example, has this
feature. Many other editors do as well. I actually find it easier to
see what is commented out this way.
Clearly this does not address the question as written though.
Kasper
On Feb 5, 2009, at 3:30 , udo.jungh...@nw-fva.de wrote:
Hello,
sorry for writing here because my problem is not a realt bug but may
be
a solution for many people working with R:
I miss the feature for commenting some lines of code at once without
writing a bunch of "#" in front of each line.
This is interesting for trying out some code.
I found some workarounds like
IFELSE(FALSE){} and
`!`<- function(x)
{
if (inherits(x, "character") == FALSE)
.Primitive("!")(x) else invisible(x)
}
but IFELSE needs valid code and the '!' <- function breaks when a "
' "
appears in the comment
so it would be fine to have something like /* ... */ or so for
multiple lines
with regards
Udo Junghans
--
Udo Junghans
Abteilung Waldschutz, Käfer und Mittelprüfung
Nordwestdeutsche Forstliche Versuchsanstalt
Grätzelstrasse 2
D-37079 Göttingen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Is abline misbehaving?
Apparently the fix was simpler than I anticipated (at least for Prof. Ripley). Thanks for finding and implementing this improvement. -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 > -Original Message- > From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] > Sent: Thursday, February 05, 2009 6:42 AM > To: Greg Snow > Cc: Jim Lemon; r-devel@r-project.org > Subject: Re: [R] Is abline misbehaving? > > [Moved to R-devel, where it probably should have started and it is > getting to C-level functions now.] > > abline is not 'misbehaving' (don't be rude about the work of > volunteers who are in your audience), but behaving in the same way as > other graphics calls. > > The real story is this (and R is Open Source, so you can read the code > too). > > Most base graphics functions call GClip to set the graphics clip state > before drawing). GClip only does anything if the xpd state has > changed since the last time it was used, and in the case of a plot > like this with axes which were drawn in the margins, it has done so. > Now, the tricky bit is 'was used', which can be very hard to > determine. Just setting the par is not enough: it has to be 'used'. > > What I have done in R-devel is make clip() 'use' xpd, and that will > ensure that the clip region it sets persists until xpd is next > changed. There the example works as I believe you intended. > > > On Sat, 24 Jan 2009, Greg Snow wrote: > > > This is a known issue, the documentation of clip talks about some > plotting functions resetting the clipping region and some don't. > abline is apparently one of those that plots first, then resets the > clipping region (so the first time it doesn't acknowledge it, but does > afterwards). The function clipplot in the TeachingDemos package uses a > similar kludge to what you do below (and I guess that puts my standing > in the hall of fame at even higher risk than yours) except that it uses > the box function with a transparent box to reset the clipping region, > which means that you get strange boxes if your graphics device does not > handle transparency. It was a question like yours that I asked in > order to try to eliminate the kludge from clipplot that originally lead > to the clip function being added, and it does cover the initial cases > that I asked about. > > > > In order to change things to work like we would like (always > resetting the clipping region at the appropriate place so that clip > always does what we expect) will probably require going through every > basic command that could put something into the plot and figure out > exactly when to have them reset the clipping region (which may not be a > simple decision, doing it too early may break existing code). The > amount of tedious work required for not much return places this fairly > low on the priority list, especially when there is a work around (as > you have found), even if it feels like a bit of a kludge. > > > > So while this probably does not fix your problem, at least hopefully > this helps you understand a bit more of what is happening here, and at > least you know that you are not alone in hall of kludge infamy. > > > > -- > > Gregory (Greg) L. Snow Ph.D. > > Statistical Data Center > > Intermountain Healthcare > > greg.s...@imail.org > > 801.408.8111 > > > > > >> -Original Message- > >> From: r-help-boun...@r-project.org [mailto:r-help-boun...@r- > >> project.org] On Behalf Of Jim Lemon > >> Sent: Saturday, January 24, 2009 2:51 AM > >> To: r-h...@r-project.org > >> Subject: [R] Is abline misbehaving? > >> > >> Hi experts, > >> I was graciously offered a function to enhance abline by restricting > >> the > >> extent of the line to less than the plotting region. This seems a > >> useful > >> idea, and it looked like the easiest way to program it was to set up > a > >> clipping region with "clip", draw the abline and then restore the > >> previous clipping region. Let us call this function ablineclip. > After > >> quite a bit of testing, I have found that the first call to > ablineclip > >> ignores the clipping region. It's not that simple. Successive calls > to > >> ablineclip respect the clipping region, even if it changes. I can > >> reproduce the behavior like this: > >> > >> plot(-3:3,-3:3) > >> clip(-2,2,-2,2) > >> abline(v=0) > >> clip(-2,2,-2,2) > >> abline(h=0) > >> > >> > >> The first abline ignores the clip, the second respects it. I have > >> programmed around this, with the pathetic kludge of calling "abline" > >> with a line outside the plotting area, calling "clip" a second time, > >> and > >> then calling "abline" with the line that was requested. While this > >> works, my place in programming history will be ineradicably > compromised > >> if the Programmers' Hall of Fame ever finds out. Any suggestions? > >> > >> R-2.7.2 > >> FC9 Linux > >> > >> Jim > >> > >> __ > >> r-h...@r-proje
Re: [Rd] JGR extension not working (PR#13501)
Erik,
fist, this is not a bug in R (not a bug at all, really), so we
specifically ask you to not waste other people's time and report it to
the maintainers. It is about a contributed package and there is a
mailing list specifically for JGR
http://mailman.rz.uni-augsburg.de/mailman/listinfo/stats-rosuda-devel
In addition, you are apparently using a custom-built R so you are
expected to know what you're doing. If you had used the R binary from
CRAN all would work. If you insist on compiling it from sources you
have to set NOAWT=1 and install latest iplots in order to prevent AWT
from starting since it's not supported on Mac OS X 10.5 inside single-
threaded applications (such as R).
Cheers,
Simon
On Feb 5, 2009, at 3:15 , er...@phonetik.uni-muenchen.de wrote:
Full_Name: Erik Lukac
Version: R version 2.8.1 (2008-12-22)
OS: Mac OS 10.5
Submission from: (NULL) (141.84.28.167)
I tried to install JGR, but somehow it doesnt work.
install.packages("JGR")
Warning in install.packages("JGR") :
argument 'lib' is missing: using
'/Users/erikl/R/i386-apple-darwin9.6.0-library/2.8'
trying URL 'http://cran.rakanu.com/src/contrib/JGR_1.6-2.tar.gz'
Content type 'application/x-gzip' length 428978 bytes (418 Kb)
opened URL
==
downloaded 418 Kb
* Installing *source* package 'JGR' ...
** R
** inst
** preparing package for lazy loading
Loading required package: rJava
Loading required package: JavaGD
Loading required package: iplots
Note: On Mac OS X we strongly recommend using iplots from within JGR.
Proceed at your own risk as iplots cannot resolve potential ev.loop
deadlocks.
'Yes' is assumed for all dialogs as they cannot be shown without a
deadlock,
also ievent.wait() is disabled.
2009-02-05 09:04:31.028 R[6886:613] Apple AWT Java VM was loaded on
first thread
-- can't start AWT.
Warning in .jnew("org/rosuda/iplots/Framework") :
NewObject("org/rosuda/iplots/Framework","()V",...) failed
Exception in thread "main" java.lang.InternalError: Can't start the
AWT because
Java was started on the first thread. Make sure StartOnFirstThread
is not
specified in your application's Info.plist or on the command line
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1822)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1723)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:
50)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1509)
at java.awt.Toolkit.(Toolkit.java:1530)
at java.awt.Color.(Color.java:250)
at org.rosuda.ibase.Common.(Common.java:47)
at org.rosuda.iplots.Framework.(Framework.java:43)
Error in .jnew("org/rosuda/iplots/Framework") :
Failed to create object of class `org/rosuda/iplots/Framework'
Error: package 'iplots' could not be loaded
Execution halted
ERROR: lazy loading failed for package 'JGR'
** Removing '/Users/erikl/R/i386-apple-darwin9.6.0-library/2.8/JGR'
The downloaded packages are in
/private/var/folders/Vg/Vgf6mZdSH8mlJdsK7HKoATI/-Tmp-/
RtmpgsoIqo/downloaded_packages
Warning message:
In install.packages("JGR") :
installation of package 'JGR' had non-zero exit status
__
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] Capturing all warnings (with messages)
Hello,
There is a function captureAll() in the svMisc package on CRAN. Although
in its current version, it simulates textual output you got at the
console, it should be rather easy to modify it to return separately
output, errors and warnings. There is one point to consider: the
function cannot catch some output from c code, and it does not work well
with R code needing interaction at the console, like browser() for
instance. For the rest, its handling of output (visible versus invisible
output) and of warnings, including management of options(warn = ) is
very similar to what is done at the console.
Best,
Philippe
..<°}))><
) ) ) ) )
( ( ( ( (Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( (Numerical Ecology of Aquatic Systems
) ) ) ) ) Mons-Hainaut University, Belgium
( ( ( ( (
..
l...@stat.uiowa.edu wrote:
Kurt Hornik and I have discussed off an on a mechanism for setting
default condition handlers. So far we haven't come up with anything
satisfactory but we may yet. In some ways this would be easier if the
top level was written in R, along the lines of .Program, so I've
played around with that a bit, but not to the point where it is usable
in production yet.
luke
On Wed, 4 Feb 2009, William Dunlap wrote:
In SV3 (or Splus prior to 5.0) one could redefine
the .Program expression, which
by default was close to print(eval(parse(stdin())) along
with some extras like printing warnings and errors in
certain ways and recording input in a .Audit file. I
once wrote toy .Programs that used select() to
listen for data arriving on a socket and for commands
from stdin. The data would be appended to a certain
dataset as it arrived and the user could ask to replot
it whenever he wanted. You could use options("warning.expression")
and try() to present warnings and errors to the user in
whatever way you wanted. I think it was used in old
versions of Splus on Windows to implement the connection
to the GUI.
Is this the sort of functionality you are looking for?
If you are writing a front-end for R the .Program is not
needed, as your front end can easily wrap boilerplate,
like eval.with.details, around whatever text the user types in.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Jon Clayden
Sent: Wednesday, February 04, 2009 4:31 PM
To: hadley wickham
Cc: R-devel@r-project.org
Subject: Re: [Rd] Capturing all warnings (with messages)
Jeff, Hadley,
Many thanks for your responses. The eval.with.details package sounds
interesting and I'll certainly take a closer look, but it still seems
to me that these approaches are focussed on trapping warnings within
specific snippets of code rather than changing the way all warnings
(including those in standard packages) are reported.
This ability would surely be useful anytime that you wish to change
the reporting of warnings from the default. Say, for example, that you
wanted to include a timestamp with each warning message. You'd do it,
I would expect, by writing a function that checks the time and formats
the message appropriately. This is the kind of thing I'm after -- I
hope this clarifies things a bit more.
The warn.expression option *appears* to provide a way to do what I
want, but because the warning is not passed to the expression (or so
it seems), and last.warning is not set before the expression is
evaluated, the expression can only know that *some* warning condition
has been raised, not *which* one. Perhaps there is a reason that
last.warning cannot be set first (?), but this limits the usefulness
of the option.
Jon
2009/2/4 hadley wickham :
Hi Jon,
I have an in-development package that attempts to do this. It's
called eval.with.details and is available from
http://github.com/hadley/eval.with.details. As you might
guess, it's
a version of eval that captures all details like messages, warnings,
errors and output so you can do whatever you want with them. It
captures them in the way Jeff Horner describes - but there are a lot
of fiddly details to get right.
Unfortunately there isn't any documentation yet, but the majority of
what you're interested in is present in eval.r. The code has been
fairly well tested - I'm using it in my own implementation
of a sweave
like system.
Hadley
On Wed, Feb 4, 2009 at 6:59 AM, Jon Clayden
wrote:
Dear all,
For an open-source project that I'm working on (1), which
uses R for all its
heavy lifting but includes a wrapper shell script, I was
hoping to find a
way to capture all warnings (and, in fact, errors too),
and handle them in
my own way. I realise I can do this for a single
expression using something
like:
f <- function(w) print(w$message)
withCallingHandlers(warning("Test"),warning=f)
[1] "Test"
Warning message:
In withCalling
[Rd] bug in proj() (PR#13505)
The result of proj() is not currently coerced to data.frame when requested. I use this capability pedagogically all the time. It did work when I wrote proj() for the Chambers and Hastie book, and it still works in S-Plus. A minimal repair is in the as.data.frame.aovproj definition below. Rich > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 8.1 year 2008 month 12 day22 svn rev47281 language R version.string R version 2.8.1 (2008-12-22) > ## using the example in ?aov utils::data(npk, package="MASS") npk.aov <- aov(yield ~ block + N * P + K, npk) proj(npk.aov) cbind(npk, proj(npk.aov)) as.data.frame.aovproj <- function(x, ...) as.data.frame(unclass(x), ...) cbind(npk, proj(npk.aov)) > cbind(npk, proj(npk.aov)) Error in as.data.frame.default(x[[i]], optional = TRUE) : cannot coerce class "aovproj" into a data.frame > as.data.frame.aovproj <- function(x, ...) as.data.frame(unclass(x), ...) > cbind(npk, proj(npk.aov)) block N P K yield (Intercept) block N P K 1 1 0 1 1 49.5 54.875 -0.850 -2.808333 -0.5916667 -1.991667 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in the parser (?) (PR#13504)
johnc.d...@yahoo.com wrote:
> Full_Name: John C. Deva
> Version: 2.8.1
> OS: Fedora Linux 8, 64 bit
> Submission from: (NULL) (193.200.150.189)
>
>
> I notice that it is possible to redefine 'if' as a function of an arbitrary
> number of arguments. Such redefined 'if' can then be used as any other user
> function, except for that the parser still demands exactly three arguments to
> be
> given to if. Furthermore, even if 'if' is defined with three arguments, its
> application must still be made with the original syntax, and not the usual
> syntax of function application:
>
>
>> `if` <- function(a,b,c)
>>
> + {
> + assign(deparse(substitute(a)), b+c, envir=parent.frame()
> + }
>
>
>> if (x) 1 else 2
>> x
>>
> [1] 3
>
>
>> if(x, 1, 2)
>>
> Error: unexpected ',' in "if(x,"
>
> The later expression above should be the only valid when 'if' is redefined as
> above, but it is not the case.
>
i've had a similar question discussed with peter dalgaard (i think)
offline (i think), with a close, though less tricky and exotic example.
the issue is, when you redefine if, it does not propagate to the parser,
which still treats every occurrence of 'if' to be a keyword with the
usual syntactic constraints. thus, the only way to apply such redefined
if is to use the original if syntax.
arguably, the parser could be parsing 'if' as a regular name in some
syntactic contexts, thus making you happily apply it as you want:
if(x) 1else 2 # parse as the conditional keyword 'if', since '1 else 2'
is present
if(x) 1 # likewise, since otherwise '1' after 'if(x)' would be
syntactically invalid
if() # parse as a function name, in a 0-argument call
if(x) # likewise, a 1-argument call
if(x, 1) # likewise, a 2-argument call
if(x, 1, 2) # likewise, ...
...
now you could redefine and use if as follows, for example (for whatever
reason might you wish to have if perform such weird actions):
if = function(...)
assign(deparse(substitute(a)), sum(...), envir=parent.frame())
# note, no need to quote 'if' for the assignment
# if the parser would not force 'if' to be a keyword here
x = 0
if(x) 1 else 2
# 2
if(x) 1
# NULL, invisibly
if(x)
# x is sum()
if(x, 1)
# x is 1
if(x, 1, 2)
# x is 3
or maybe
if = function(if, x) if(if(x)) x else if
if(is.integer, 2)
# .Primitive("is.integer")
if(is.integer, 2L)
# 2
you probably don't really need to redefine if this way, or any other
way, but the point is valid, imho, and applicable to any other reserved
word. it's rather weird that you *can* redefine if and use it as a
regular function but with the original syntax, as in your example.
you'll certainly get bashed for the bug report; it's not a bug, rather a
design issue, and not necessarily a problem.
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in the parser (?) (PR#13504)
johnc.d...@yahoo.com wrote:
> Full_Name: John C. Deva
> Version: 2.8.1
> OS: Fedora Linux 8, 64 bit
> Submission from: (NULL) (193.200.150.189)
>
>
> I notice that it is possible to redefine 'if' as a function of an arbitrary
> number of arguments. Such redefined 'if' can then be used as any other user
> function, except for that the parser still demands exactly three arguments to
> be
> given to if. Furthermore, even if 'if' is defined with three arguments, its
> application must still be made with the original syntax, and not the usual
> syntax of function application:
>
>> `if` <- function(a,b,c)
> + {
> + assign(deparse(substitute(a)), b+c, envir=parent.frame()
> + }
>
>> if (x) 1 else 2
>> x
> [1] 3
>
>> if(x, 1, 2)
> Error: unexpected ',' in "if(x,"
>
> The later expression above should be the only valid when 'if' is redefined as
> above, but it is not the case.
A bug report with a ? in the title is in general ill-advised. If you are
not sure that something is a bug, then ask a question instead.
In this case, no, it is not a bug. Syntax is syntax and "if(x,1,2)" is a
syntax error no matter how if() is defined. Parsing is controlled by the
fact that "if" is a keyword, the function definition is not used at all
at that stage. `if`(x,1,2) works perfectly well, though, at least until
you try deparsing it:
> quote(`if`(x,1,2))
if (x) 1 else 2
Redefining "if" is a really Bad Idea, excepting things like code
analysis tools (which I believe are the main reason it is not explicitly
forbidden).
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Is abline misbehaving?
[Moved to R-devel, where it probably should have started and it is getting to C-level functions now.] abline is not 'misbehaving' (don't be rude about the work of volunteers who are in your audience), but behaving in the same way as other graphics calls. The real story is this (and R is Open Source, so you can read the code too). Most base graphics functions call GClip to set the graphics clip state before drawing). GClip only does anything if the xpd state has changed since the last time it was used, and in the case of a plot like this with axes which were drawn in the margins, it has done so. Now, the tricky bit is 'was used', which can be very hard to determine. Just setting the par is not enough: it has to be 'used'. What I have done in R-devel is make clip() 'use' xpd, and that will ensure that the clip region it sets persists until xpd is next changed. There the example works as I believe you intended. On Sat, 24 Jan 2009, Greg Snow wrote: This is a known issue, the documentation of clip talks about some plotting functions resetting the clipping region and some don't. abline is apparently one of those that plots first, then resets the clipping region (so the first time it doesn't acknowledge it, but does afterwards). The function clipplot in the TeachingDemos package uses a similar kludge to what you do below (and I guess that puts my standing in the hall of fame at even higher risk than yours) except that it uses the box function with a transparent box to reset the clipping region, which means that you get strange boxes if your graphics device does not handle transparency. It was a question like yours that I asked in order to try to eliminate the kludge from clipplot that originally lead to the clip function being added, and it does cover the initial cases that I asked about. In order to change things to work like we would like (always resetting the clipping region at the appropriate place so that clip always does what we expect) will probably require going through every basic command that could put something into the plot and figure out exactly when to have them reset the clipping region (which may not be a simple decision, doing it too early may break existing code). The amount of tedious work required for not much return places this fairly low on the priority list, especially when there is a work around (as you have found), even if it feels like a bit of a kludge. So while this probably does not fix your problem, at least hopefully this helps you understand a bit more of what is happening here, and at least you know that you are not alone in hall of kludge infamy. -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -Original Message- From: r-help-boun...@r-project.org [mailto:r-help-boun...@r- project.org] On Behalf Of Jim Lemon Sent: Saturday, January 24, 2009 2:51 AM To: r-h...@r-project.org Subject: [R] Is abline misbehaving? Hi experts, I was graciously offered a function to enhance abline by restricting the extent of the line to less than the plotting region. This seems a useful idea, and it looked like the easiest way to program it was to set up a clipping region with "clip", draw the abline and then restore the previous clipping region. Let us call this function ablineclip. After quite a bit of testing, I have found that the first call to ablineclip ignores the clipping region. It's not that simple. Successive calls to ablineclip respect the clipping region, even if it changes. I can reproduce the behavior like this: plot(-3:3,-3:3) clip(-2,2,-2,2) abline(v=0) clip(-2,2,-2,2) abline(h=0) The first abline ignores the clip, the second respects it. I have programmed around this, with the pathetic kludge of calling "abline" with a line outside the plotting area, calling "clip" a second time, and then calling "abline" with the line that was requested. While this works, my place in programming history will be ineradicably compromised if the Programmers' Hall of Fame ever finds out. Any suggestions? R-2.7.2 FC9 Linux Jim __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting- guide.html and provide commented, minimal, self-contained, reproducible code. __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. -- 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 __
[Rd] Bug in the parser (?) (PR#13504)
Full_Name: John C. Deva
Version: 2.8.1
OS: Fedora Linux 8, 64 bit
Submission from: (NULL) (193.200.150.189)
I notice that it is possible to redefine 'if' as a function of an arbitrary
number of arguments. Such redefined 'if' can then be used as any other user
function, except for that the parser still demands exactly three arguments to be
given to if. Furthermore, even if 'if' is defined with three arguments, its
application must still be made with the original syntax, and not the usual
syntax of function application:
> `if` <- function(a,b,c)
+ {
+ assign(deparse(substitute(a)), b+c, envir=parent.frame()
+ }
> if (x) 1 else 2
> x
[1] 3
> if(x, 1, 2)
Error: unexpected ',' in "if(x,"
The later expression above should be the only valid when 'if' is redefined as
above, but it is not the case.
Sincerely,
John C.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] JGR extension not working (PR#13501)
Full_Name: Erik Lukac
Version: R version 2.8.1 (2008-12-22)
OS: Mac OS 10.5
Submission from: (NULL) (141.84.28.167)
I tried to install JGR, but somehow it doesnt work.
> install.packages("JGR")
Warning in install.packages("JGR") :
argument 'lib' is missing: using
'/Users/erikl/R/i386-apple-darwin9.6.0-library/2.8'
trying URL 'http://cran.rakanu.com/src/contrib/JGR_1.6-2.tar.gz'
Content type 'application/x-gzip' length 428978 bytes (418 Kb)
opened URL
==
downloaded 418 Kb
* Installing *source* package 'JGR' ...
** R
** inst
** preparing package for lazy loading
Loading required package: rJava
Loading required package: JavaGD
Loading required package: iplots
Note: On Mac OS X we strongly recommend using iplots from within JGR.
Proceed at your own risk as iplots cannot resolve potential ev.loop deadlocks.
'Yes' is assumed for all dialogs as they cannot be shown without a deadlock,
also ievent.wait() is disabled.
2009-02-05 09:04:31.028 R[6886:613] Apple AWT Java VM was loaded on first thread
-- can't start AWT.
Warning in .jnew("org/rosuda/iplots/Framework") :
NewObject("org/rosuda/iplots/Framework","()V",...) failed
Exception in thread "main" java.lang.InternalError: Can't start the AWT because
Java was started on the first thread. Make sure StartOnFirstThread is not
specified in your application's Info.plist or on the command line
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1822)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1723)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1509)
at java.awt.Toolkit.(Toolkit.java:1530)
at java.awt.Color.(Color.java:250)
at org.rosuda.ibase.Common.(Common.java:47)
at org.rosuda.iplots.Framework.(Framework.java:43)
Error in .jnew("org/rosuda/iplots/Framework") :
Failed to create object of class `org/rosuda/iplots/Framework'
Error: package 'iplots' could not be loaded
Execution halted
ERROR: lazy loading failed for package 'JGR'
** Removing '/Users/erikl/R/i386-apple-darwin9.6.0-library/2.8/JGR'
The downloaded packages are in
/private/var/folders/Vg/Vgf6mZdSH8mlJdsK7HKoATI/-Tmp-/RtmpgsoIqo/downloaded_packages
Warning message:
In install.packages("JGR") :
installation of package 'JGR' had non-zero exit status
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Multiple-Line Comment (PR#13503)
Hello,
sorry for writing here because my problem is not a realt bug but may be
a solution for many people working with R:
I miss the feature for commenting some lines of code at once without
writing a bunch of "#" in front of each line.
This is interesting for trying out some code.
I found some workarounds like
IFELSE(FALSE){} and
`!`<- function(x)
{
if (inherits(x, "character") == FALSE)
.Primitive("!")(x) else invisible(x)
}
but IFELSE needs valid code and the '!' <- function breaks when a " ' "
appears in the comment
so it would be fine to have something like /* ... */ or so for
multiple lines
with regards
Udo Junghans
--
Udo Junghans
Abteilung Waldschutz, Käfer und Mittelprüfung
Nordwestdeutsche Forstliche Versuchsanstalt
Grätzelstrasse 2
D-37079 Göttingen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#8192) [ subscripting sometimes loses names
it's becoming an old story, but here's a bit to be added. Peter Dalgaard wrote: > Duncan Murdoch wrote: >> On 31/01/2009 7:31 AM, Andrew Piskorski wrote: >>> This (tangential) discussion really should be a separate thread so I >>> changed the subject line above. >>> >>> On Fri, Jan 30, 2009 at 11:51:00AM -0500, Simon Urbanek wrote: Subject: Re: [Rd] (PR#13487) Segfault when mistakenly calling [.data.frame >>> > My boss was debugging an issue in our R code. We have our own > "[" > functions, because stock R drops names when subscripting. ... if you tell it to do so, yes. If you tell it to not do that, it won't ... ever tried drop=FALSE ? >>> >>> Simon, no, the drop=FALSE argument has nothing to do with what >>> Christian was talking about. The kind of thing he meant is PR# 8192, >>> "Subject: [ subscripting sometimes loses names": >>> >>> http://bugs.r-project.org/cgi-bin/R/wishlist?id=8192 >> >> In that bug report you were asked to provide simple examples, and you >> didn't. I imagine that's why there was no action on it. It is not >> that easy for someone else to actually find the simple example that >> led you to print >> >> $vec.1 >> BAD $vec.1[[1]] $vec.1[[2]] >> ac a c no >> 13 NA 1 3 NA >> >> I just tracked this one down, and can put together this simple example: >> >> > (1:3)["no"] >> [1] NA >> >> where I think you would want the name "no" attached to the output. >> (Or maybe your more complicated example is wanted? You don't >> explain.) But that looks like documented behaviour to me: according >> to my reading of "Indexing by vectors" in the R Language Definition >> manual, it should give the same answer as (1:3)[4], and it does. So >> it's not a bug, but a wishlist item. >> >> And the other two cases where you list "BAD" behaviour? I didn't >> track them down. > > I did, and they boil down to variations of > > > data.frame(val=1:3,row.names=letters[1:3])[,1] > [1] 1 2 3 > > but it's not obvious that the result should be named using the > row.names and (in particular) whether or why it should differ from > .[[1]] and $val. once you are saying that, be prepared to explain why it should *not* differ from [[1]] and $val. reading ?'[' carefully, you'll find: " The most important distinction between '[', '[[' and '$' is that the '[' can select more than one element whereas the other two select a single element." that's actually quite enough to justify why [,1] (or rather [, indices], with an arbitrary vector of indices) should differ from [[1]] and $val. precisely because: a) [[index]] and $name are *guaranteed* to return one column (or fail), so it's reasonable to *always* drop the dimension -- because it will be done in the case of every successful selection; b) [, indices] *may* or *may not* return one column in a successful selection, and now dropping the dimension (and names) depends not on the type of the indices used (positive numeric, negative numeric, character, whatever), but on the length of the index vector. why is external consistence of [ (being like [[ and $) when a single index is used more important than its internal consistence (returning the same type of data -- a data frame, or a like-dimensioned matrix -- irrespectively of the length of the index vector)? i realize that the issue of drop=FALSE vs drop=TRUE as the default has been discussed before, but i don't find clear arguments given for the first option, beyond that it just is so and would break much old code if were to be changed. i'm actually hoping not for this to be changed, but for users not to be blamed for assuming [,1] returns a data frame with row names. it's *not* their fault they are wrong. > Given that for most purposes, extracting the relevant names would just > be unnecessary red tape, I'd say that we can do without it. > would keeping the dimensions and class be just unnecessary red tape, too? can you know what most users' purposes are? vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
