Re: [Rd] newly introduced lattice bug
On 9/30/06, Richard M. Heiberger <[EMAIL PROTECTED]> wrote: > > library(lattice) > > xyplot(rnorm(10) ~ rnorm(10) | factor(1:10), layout=c(2,3)) > > version >_ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status RC > major 2 > minor 4.0 > year 2006 > month 09 > day27 > svn rev39543 > language R > version.string R version 2.4.0 RC (2006-09-27 r39543) > > > > > This was downloaded two minutes ago from the CRAN page > http://cran.us.r-project.org/bin/windows/base/rtest.html > dated > Last build: 2006-09-29, by Duncan Murdoch > > > The bug is that 2.4.0 RC displays 12 panels, with the incorrect top two panels > on the second page being copies of the correct top two panels on the first > page. > > I just noticed this in R version 2.4.0 beta (2006-09-20 r39421) > and immediately got a newer version of R before reporting it. > > R-2.3.1 displays the correct 10 panels. Thanks for catching this. Some variables were not being reinitialized for new pages. Fixed version should be available soon. Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rcmd install mypkg
I noticed that in "R version 2.4.0 alpha (2006-09-16 r39365)" on Windows XP that I get this error: C:\Rpkgs>Rcmd install mypkg no Perl script 'install' The same command worked with no error in 2.3.1pat. If I capitalize INSTALL it does work; however, this was not necessary previously. Note that C:\Rpkgs>Rcmd check mypkg unlike install, still works in either lower or upper case in 2.4.0 alpha. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] newly introduced lattice bug
> library(lattice) > xyplot(rnorm(10) ~ rnorm(10) | factor(1:10), layout=c(2,3)) > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status RC major 2 minor 4.0 year 2006 month 09 day27 svn rev39543 language R version.string R version 2.4.0 RC (2006-09-27 r39543) > This was downloaded two minutes ago from the CRAN page http://cran.us.r-project.org/bin/windows/base/rtest.html dated Last build: 2006-09-29, by Duncan Murdoch The bug is that 2.4.0 RC displays 12 panels, with the incorrect top two panels on the second page being copies of the correct top two panels on the first page. I just noticed this in R version 2.4.0 beta (2006-09-20 r39421) and immediately got a newer version of R before reporting it. R-2.3.1 displays the correct 10 panels. Rich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of the [[ operator
On 9/30/2006 10:39 AM, Martin Maechler wrote: >> "Herve" == Herve Pages <[EMAIL PROTECTED]> >> on Fri, 29 Sep 2006 18:06:41 -0700 writes: > > Herve> Hi, > Herve> This looks like a bug: > hmm, maybe... > or maybe not; I vaguely recall that this is documented somewhere... > > >> a <- list(b=5) > >> a[['b']] > Herve> [1] 5 > >> a[[t<-'b']] > > Herve> Nothing gets printed! > > Yes, but that is not really much related to "[[" > but rather to "<-" which momentarily turns off auto-printing. I think this is probably not intentional, because the behaviour is so inconsistent. In names.c, the "eval" entry for "[" and "[[" is 0, which is supposed to indicate R_Visible is on. It's the same as for c(), substitute(), quote(), interactive(), expression(), nargs(), and those return a visible result. On the other hand, dim(), dimnames(), as.character(), call(), rep(), seq.int(), seq_along() also have eval=0, and they give an invisible result. Among the eval=10 functions, I see visible results from unlist(), cbind(), rbind(), and invisible ones from sys.parent(), sys.call() etc., parent.frame(), and so on (I gave up testing at this point). I suspect the problem is that these are low level functions where the evaluator does almost nothing automatically, and handling R_Visible was just overlooked. Duncan Murdoch > > Similar things happen in many similar circumstances. > > Herve> I need to use parenthesis to see the expected result: > > >> a[[(t<-'b')]] > Herve> [1] 5 > > Herve> Cheers, > Herve> H. > > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of the [[ operator
True, re name matching, but I think we might want to consider a warning
if they are supplied as the user may not be getting what they expect,
regardless of the documentation
Peter Dalgaard wrote:
> Seth Falcon <[EMAIL PROTECTED]> writes:
>
>>> Similar things happen in many similar circumstances.
>> Here's a similar thing:
>
> Not really, no?
>
>>> v <- 1:5
>>> v
>> [1] 1 2 3 4 5
>>> v[mustBeDocumentedSomewhere=3]
>> [1] 3
>>
>> And this can be confusing if one thinks that subsetting is really a
>> function and behaves like other R functions w.r.t. to treatment of
>> named arguments:
>>
>>> m <- matrix(1:4, nrow=2)
>>> m
>> [,1] [,2]
>> [1,]13
>> [2,]24
>>> m[j=2]
>> [1] 2
>
> Or even
>> m[j=2,i=]
> [1] 2 4
>
> However, what would the argument names be in the >2-dim case? i, j are
> used only in help("[") and that page is quite specific about
> explaining that named matching doesn't work.
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of the [[ operator
Seth Falcon <[EMAIL PROTECTED]> writes:
> > Similar things happen in many similar circumstances.
>
> Here's a similar thing:
Not really, no?
> > v <- 1:5
> > v
> [1] 1 2 3 4 5
> > v[mustBeDocumentedSomewhere=3]
> [1] 3
>
> And this can be confusing if one thinks that subsetting is really a
> function and behaves like other R functions w.r.t. to treatment of
> named arguments:
>
> > m <- matrix(1:4, nrow=2)
> > m
> [,1] [,2]
> [1,]13
> [2,]24
> > m[j=2]
> [1] 2
Or even
> m[j=2,i=]
[1] 2 4
However, what would the argument names be in the >2-dim case? i, j are
used only in help("[") and that page is quite specific about
explaining that named matching doesn't work.
--
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
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of the [[ operator
Martin Maechler <[EMAIL PROTECTED]> writes:
> >> a <- list(b=5)
> >> a[['b']]
> Herve> [1] 5
> >> a[[t<-'b']]
>
> Herve> Nothing gets printed!
>
> Yes, but that is not really much related to "[["
> but rather to "<-" which momentarily turns off auto-printing.
Yes, not being related to "[[" is exactly why it is surprising.
I would expect vv[[f(x)]] to print regardless of f's auto-printing
behavior.
f1 <- function(x) x
f2 <- function(x) return(invisible(x))
a <- list(b=5)
a[[f1("a")]]
a[[f2("a")]]
> Similar things happen in many similar circumstances.
Here's a similar thing:
> v <- 1:5
> v
[1] 1 2 3 4 5
> v[mustBeDocumentedSomewhere=3]
[1] 3
And this can be confusing if one thinks that subsetting is really a
function and behaves like other R functions w.r.t. to treatment of
named arguments:
> m <- matrix(1:4, nrow=2)
> m
[,1] [,2]
[1,]13
[2,]24
> m[j=2]
[1] 2
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of the [[ operator (PR#9263)
Hi Duncan, This is even more confusing with a matrix: > x <- matrix(5:-6, 3) > x [,1] [,2] [,3] [,4] [1,]52 -1 -4 [2,]41 -2 -5 [3,]30 -3 -6 > x[invisible(2),3] [1] -2 > x[2,invisible(3)] > .Last.value [1] -2 Thanks, H. Quoting [EMAIL PROTECTED]: > On 9/29/2006 9:06 PM, Herve Pages wrote: > > Hi, > > > > This looks like a bug: > > > > > a <- list(b=5) > > > a[['b']] > > [1] 5 > > > a[[t<-'b']] > > > > Nothing gets printed! > > > > I need to use parenthesis to see the expected result: > > > > > a[[(t<-'b')]] > > [1] 5 > > Yes, I agree it looks like a bug, and it's still there in R-devel. The > problem is that the assignment sets the R_Visible flag to false, and the > indexing never sets it to true. The same problem happens with a[t <- > 'b'], whether a is a list or not: > > > a <- c(b=5, c=6, d=7) > > a[t <- 'b'] > > .Last.value > b > 5 > > Duncan Murdoch > > __ > 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] Help for methods
> See the .helpForCall function in utils. It would recognize that the > function was an S4 generic, and then work out the signature and look for > matching help. I think working out the signature in the case above > would require it to call lm(...). So there's a precedent for what I > called a "huge mistake": maybe it's not so huge... And I'd imagine, in practice, most people would be doing something like x<- ... ?summary(x) so that wouldn't have to do an extra computation. Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of the [[ operator
> "Herve" == Herve Pages <[EMAIL PROTECTED]> > on Fri, 29 Sep 2006 18:06:41 -0700 writes: Herve> Hi, Herve> This looks like a bug: hmm, maybe... or maybe not; I vaguely recall that this is documented somewhere... >> a <- list(b=5) >> a[['b']] Herve> [1] 5 >> a[[t<-'b']] Herve> Nothing gets printed! Yes, but that is not really much related to "[[" but rather to "<-" which momentarily turns off auto-printing. Similar things happen in many similar circumstances. Herve> I need to use parenthesis to see the expected result: >> a[[(t<-'b')]] Herve> [1] 5 Herve> Cheers, Herve> H. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in Rcons_vprintf
Thanks, Jeffrey, that (change) looks very logical, reasonable, ... and I'll commit a patch to R-devel ASAP. On the other hand, I'm currently not intending to port the fix to the currently "deep frozen" R-2.4-branch [because "you never know ..."] unless you can argue a bit more why the change seems important (or at least can demonstrate bogous behavior that is fixed by it). Martin > "Jeffrey" == Jeffrey Horner <[EMAIL PROTECTED]> > on Fri, 29 Sep 2006 15:22:51 -0500 writes: Jeffrey> In R-2-4-branch r39548, Rcons_vprintf is called from stdout_vfprintf Jeffrey> when R_Outputfile is NULL. When called and output is greater than Jeffrey> R_BUFSIZE, output is truncated to R_BUFSIZE. Here's a one-line fix: Jeffrey> Index: src/main/printutils.c Jeffrey> === Jeffrey> --- src/main/printutils.c (revision 39548) Jeffrey> +++ src/main/printutils.c (working copy) Jeffrey> @@ -638,7 +638,7 @@ Jeffrey> res = R_BUFSIZE; Jeffrey> } Jeffrey> #endif /* HAVE_VA_COPY */ Jeffrey> -R_WriteConsole(p, strlen(buf)); Jeffrey> +R_WriteConsole(p, strlen(p)); Jeffrey> #ifdef HAVE_VA_COPY Jeffrey> if(usedRalloc) vmaxset(vmax); Jeffrey> if(usedVasprintf) free(p); Jeffrey> Jeff Jeffrey> -- Jeffrey> http://biostat.mc.vanderbilt.edu/JeffreyHorner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] lowess: parameter 'delta' has no effect (PR#9264)
In the help page of lowess, it says: delta: values of 'x' which lie within 'delta' of each other are replaced by a single value in the output from 'lowess'. Defaults to 1/100th of the range of 'x'. It doesn't. No matter what value I give for delta, the result always has the same number of points as there are in the input. --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 2 minor = 3.1 year = 2006 month = 06 day = 01 svn rev = 38247 language = R version.string = Version 2.3.1 (2006-06-01) Locale: [EMAIL PROTECTED];LC_NUMERIC=C;[EMAIL PROTECTED];LC_COLLATE=C;[EMAIL PROTECTED];[EMAIL PROTECTED];LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:iL04, package:MASS, package:methods, package:stats, package:utils, package:datasets, package:graphics, package:grDevices, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of the [[ operator (PR#9263)
On 9/29/2006 9:06 PM, Herve Pages wrote: > Hi, > > This looks like a bug: > > > a <- list(b=5) > > a[['b']] > [1] 5 > > a[[t<-'b']] > > Nothing gets printed! > > I need to use parenthesis to see the expected result: > > > a[[(t<-'b')]] > [1] 5 Yes, I agree it looks like a bug, and it's still there in R-devel. The problem is that the assignment sets the R_Visible flag to false, and the indexing never sets it to true. The same problem happens with a[t <- 'b'], whether a is a list or not: > a <- c(b=5, c=6, d=7) > a[t <- 'b'] > .Last.value b 5 Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help for methods
On 9/30/2006 1:17 AM, hadley wickham wrote: >> Yes, I agree that the current help system doesn't work very well on S3 >> methods. But I don't know how to fix it. I think the only way it could >> know what to do on a construction like >> >> ?summary(lm(...)) >> >> would be to actually evaluate summary(lm(...)) (or maybe just lm(...)), >> and I think that would be a huge mistake in the user interface. Some >> functions have side effects, and you don't want to evaluate them unless >> the user asks you to. Asking for help on something should give you >> help, it shouldn't do the thing. > > I keep flipping back and forth on whether or not that's a problem. I > agree that it's not desirable, but may be an ok compromise in > principle. How does the S4 help search work? See the .helpForCall function in utils. It would recognize that the function was an S4 generic, and then work out the signature and look for matching help. I think working out the signature in the case above would require it to call lm(...). So there's a precedent for what I called a "huge mistake": maybe it's not so huge... Duncan Murdoch > >> Do you have an actual suggestion for a change to the current behaviour? > > One obvious heuristic (which I used with the hints function I wrote a > while back) is to iterate through the classes of the first argument > looking for functions (with documentation) of the form generic.class1, > generic.class2 etc. > > Obviously this will fail for functions that don't dispatch on the > first method, but there probably aren't that many. > > Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
