[Rd] weighted.mean uses zero when na.rm=TRUE (PR#14032)
The weighted.mean() function replaces NA values with 0.0 when the user specifies na.rm=TRUE: x <- c(101, 102, NA) mean(x, na.rm=TRUE) # 101.5, correct weighted.mean(x, na.rm=TRUE)# 67.7, wrong weighted.mean(x, w=c(1,1,1), na.rm=TRUE)# 67.7, wrong weighted.mean(x, w=c(1,1,1)/3, na.rm=TRUE) # 67.7, wrong The weights are normalized w<-w/sum(w) before removing the NA values, effectively replacing x[is.na(x)]<-0. This bug was introduced between versions 2.9.2 and 2.10.0. Thanks, Arni __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in `pmatch' (error with too long 'choices')?
I observed the following:
match.arg("white", colors())
yields 'white', but
match.arg("whit", colors())
yields:
`Error in match.arg("whit", colors()) :
'arg' should be one of "white", "aliceblue", '...
this message actually comes from `pmatch'. using a suitable subset of
`colors()' works OK. the precise length were the error occurs seems to
depend on `arg' and `choices'. e.g.
match.arg("whit", colors()[1:650])
works
but the limit seems not be fixed. in another setting it
happend around a length of `choices' of around 130. maybe a memory management
related
bug? or am I missing something?
regards,
joerg
platform powerpc-apple-darwin8.11.1
arch powerpc
os darwin8.11.1
system powerpc, darwin8.11.1
status
major 2
minor 9.2
year 2009
month 08
day24
svn rev49384
language R
version.string R version 2.9.2 (2009-08-24)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] weighted.mean uses zero when na.rm=TRUE (PR#14032)
arn...@hafro.is wrote: The weighted.mean() function replaces NA values with 0.0 when the user specifies na.rm=TRUE: x <- c(101, 102, NA) mean(x, na.rm=TRUE) # 101.5, correct weighted.mean(x, na.rm=TRUE)# 67.7, wrong weighted.mean(x, w=c(1,1,1), na.rm=TRUE)# 67.7, wrong weighted.mean(x, w=c(1,1,1)/3, na.rm=TRUE) # 67.7, wrong The weights are normalized w<-w/sum(w) before removing the NA values, effectively replacing x[is.na(x)]<-0. This bug was introduced between versions 2.9.2 and 2.10.0. Yes, r48644 on May 27, specifically. -- 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] bug in `pmatch' (error with too long 'choices')?
I believe the answer is that you are missing something: partial matching.
The 651'st elt of colors() is "whitesmoke", so it is ambiguous whether
"whit" matches "white" or "whitesmoke". When you leave out the 651'st
elt, "whit" happily matches "white".
> which(substring(colors(), 1, 4)=="whit")
[1] 1 651
> colors()[which(substring(colors(), 1, 4)=="whit")]
[1] "white" "whitesmoke"
> match.arg("whit", colors()[1:650])
[1] "white"
> match.arg("whit", colors())
Error in match.arg("whit", colors()) :
'arg' should be one of “white”, “aliceblue”, ...
> match.arg("whit", colors()[c(1,651)])
Error in match.arg("whit", colors()[c(1, 651)]) :
'arg' should be one of “white”, “whitesmoke”
>
-- Tony Plate
Joerg van den Hoff wrote:
I observed the following:
match.arg("white", colors())
yields 'white', but
match.arg("whit", colors())
yields:
`Error in match.arg("whit", colors()) :
'arg' should be one of "white", "aliceblue", '...
this message actually comes from `pmatch'. using a suitable subset of
`colors()' works OK. the precise length were the error occurs seems to
depend on `arg' and `choices'. e.g.
match.arg("whit", colors()[1:650])
works
but the limit seems not be fixed. in another setting it
happend around a length of `choices' of around 130. maybe a memory management
related
bug? or am I missing something?
regards,
joerg
platform powerpc-apple-darwin8.11.1
arch powerpc
os darwin8.11.1
system powerpc, darwin8.11.1
status
major 2
minor 9.2
year 2009
month 08
day24
svn rev49384
language R
version.string R version 2.9.2 (2009-08-24)
__
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] evince pdf viewing
It was pointed out to me that scatter plots made on our rhel5 system (sessionInfo() below, have the curious feature that when made with pdf() and viewed with evince show the points as "q" not "o". Is this a known problem with evince? It is pretty clearly not a problem with R, since if I bring the pdf file back to my mac and open in acrobat it looks normal. So this is a just-in-case- someone-else-runs-into-this kind of post. > sessionInfo() R version 2.10.0 alpha (2009-10-09 r50012) x86_64-unknown-linux-gnu locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] splines stats graphics grDevices utils datasets methods [8] base other attached packages: [1] survival_2.35-7 quantreg_4.42 SparseM_0.80 loaded via a namespace (and not attached): [1] tools_2.10.0 url:www.econ.uiuc.edu/~rogerRoger Koenker emailrkoen...@uiuc.eduDepartment of Economics vox: 217-333-4558University of Illinois fax: 217-244-6678Urbana, IL 61801 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] quoted strings in foo.Rd rendered as â
Another anomaly from our rhel5 system, again sessionInfo() below. When I'm logged in remotely via ssh from my macpro and view documentation files in my X11 window, strings in single quotes in the files are all abbreviated as â . The same files appear fine when rendered in X11 using the local R, and also appear fine in a terminal window on the linux machine, so this could easily also be some sort of ssh/X11 issue not R at all, but if someone had any suggestion for further checking it would be greatly appreciated. Roger > sessionInfo() R version 2.10.0 alpha (2009-10-09 r50012) x86_64-unknown-linux-gnu locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] splines stats graphics grDevices utils datasets methods [8] base other attached packages: [1] survival_2.35-7 quantreg_4.42 SparseM_0.80 loaded via a namespace (and not attached): [1] tools_2.10.0 url:www.econ.uiuc.edu/~rogerRoger Koenker emailrkoen...@uiuc.eduDepartment of Economics vox: 217-333-4558University of Illinois fax: 217-244-6678Urbana, IL 61801 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] quoted strings in foo.Rd rendered as â
First step to check: update to a released version of R 2.10.0! If that does not help, using options(useFancyQuotes = TRUE) in the released version should (but possibly not as far back as your alpha pre-release). I suspect that whatever you mean my 'my X11 window' (it is the application running in the window that matters, perhaps an xterm?) it is set to the wrong character set. I simply use a Mac terminal window, and that ought to default to UTF-8 (but it can be changed, so check if you try one). On Fri, 30 Oct 2009, Roger Koenker wrote: Another anomaly from our rhel5 system, again sessionInfo() below. When I'm logged in remotely via ssh from my macpro and view documentation files in my X11 window, strings in single quotes in the files are all abbreviated as â . The same files appear fine when rendered in X11 using the local R, and also appear fine in a terminal window on the linux machine, so this could easily also be some sort of ssh/X11 issue not R at all, but if someone had any suggestion for further checking it would be greatly appreciated. Roger sessionInfo() R version 2.10.0 alpha (2009-10-09 r50012) x86_64-unknown-linux-gnu locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] splines stats graphics grDevices utils datasets methods [8] base other attached packages: [1] survival_2.35-7 quantreg_4.42 SparseM_0.80 loaded via a namespace (and not attached): [1] tools_2.10.0 url:www.econ.uiuc.edu/~rogerRoger Koenker emailrkoen...@uiuc.eduDepartment of Economics vox: 217-333-4558University of Illinois fax: 217-244-6678Urbana, IL 61801 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] evince pdf viewing
Yes, it is known: it is described with workarounds (thanks to Marc Schwarz, AFAIR) on the ?pdf help page. On Fri, 30 Oct 2009, Roger Koenker wrote: It was pointed out to me that scatter plots made on our rhel5 system (sessionInfo() below, have the curious feature that when made with pdf() and viewed with evince show the points as "q" not "o". Is this a known problem with evince? It is pretty clearly not a problem with R, since if I bring the pdf file back to my mac and open in acrobat it looks normal. So this is a just-in-case-someone-else-runs-into-this kind of post. sessionInfo() R version 2.10.0 alpha (2009-10-09 r50012) x86_64-unknown-linux-gnu locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] splines stats graphics grDevices utils datasets methods [8] base other attached packages: [1] survival_2.35-7 quantreg_4.42 SparseM_0.80 loaded via a namespace (and not attached): [1] tools_2.10.0 url:www.econ.uiuc.edu/~rogerRoger Koenker emailrkoen...@uiuc.eduDepartment of Economics vox: 217-333-4558University of Illinois fax: 217-244-6678Urbana, IL 61801 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parse_Rd and/or lazyload problem
On 30/10/2009 12:50 AM, mark.braving...@csiro.au wrote: I'm encountering problems when making lazy-loadable databases of the output from 'parse_Rd'. The lazy-load database is of seemingly limitless size when I try to reload it... Admittedly I am using functions that I'm not really supposed to use, which is why this isn't a bug report, but there does seem to be something strange going on; my code is very similar to code that lives inside 'tools:::.install_package_Rd_objects'. The problems occur with just-released R2.10.0 on Windows. object.size() has problems when working on Rd objects, because it counts every environment separately, even though they may all be references to the same one. I haven't looked at your code, but that could be a problem. Duncan Murdoch The examples below use files which can be found at ftp://ftp.csiro.au/MarkBravington, but you'll obviously need to modify the paths. The file "scrunge.Rd" is just "Rdiff.Rd" from the 'tools' package. The file "fakepack.7z" should unzip to create a fake package with a DESCRIPTION file and a "man" directory that contains two Rd files. Transcript of first example: eglist <- list( scrunge=tools:::prepare_Rd( 'd:/temp/scrunge.Rd', defines=.Platform$OS.type, stages='install', warningCalls=FALSE)) tools:::makeLazyLoadDB( eglist, 'd:/temp/ll', compress=FALSE) tools:::fetchRdDB( 'd:/temp/ll') # Error: cannot allocate vector of size 1.4 Gb The second example triggers an error with 'tools:::.install_package_Rd_objects' itself. It doesn't happen the first time, but frequently does after the Rd files have been changed. Transcript: # Make sure d:/temp/help/ is empty, then test> tools:::.install_package_Rd_objects( 'd:/temp/fakepack', 'd:/temp') test> tools:::fetchRdDB( 'd:/temp/help/temp') # All good. Next, I *removed* one of the two Rd files in "d:/temp/fakepack/man", ... # ...deleted "d:/temp/help/temp*", and tried again test> tools:::.install_package_Rd_objects( 'd:/temp/fakepack', 'd:/temp') test> tools:::fetchRdDB( 'd:/temp/help/temp') Warning: Reached total allocation of 1535Mb: see help(memory.size) Warning: Reached total allocation of 1535Mb: see help(memory.size) Warning: Reached total allocation of 1535Mb: see help(memory.size) Warning: Reached total allocation of 1535Mb: see help(memory.size) Error: cannot allocate vector of size 1.9 Gb # Or on other occasions I get Error: internal error -3 in R_decompress1 Mark Bravington CSIRO CMIS Hobart Australia --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 2 minor = 10.0 year = 2009 month = 10 day = 26 svn rev = 50208 language = R version.string = R version 2.10.0 (2009-10-26) Windows XP (build 2600) Service Pack 2 Locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 Search Path: .GlobalEnv, ROOT, package:grDevices, package:ad, package:chstuff, package:handy2, package:tweedie, package:statmod, package:handy, package:debug, package:mvbutils, mvb.session.info, package:tools, package:tcltk, package:stats, package:graphics, package:utils, package:methods, Autoloads, package:base __ 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] parse_Rd and/or lazyload problem
The errors are generated inside lazyLoadDBfetch; I don't call object.size, so unfortunately that's not the issue (unless o.s. is called somewhere inside the .Primitive for lazyLoadDBfetch). > > I'm encountering problems when making lazy-loadable databases of the output > > from 'parse_Rd'. The lazy- > > load database is of seemingly limitless size when I try to reload it... > > Admittedly I am using functions > > that I'm not really supposed to use, which is why this isn't a bug report, > > but there does seem to be > > something strange going on; my code is very similar to code that lives > > inside > > 'tools:::.install_package_Rd_objects'. The problems occur with > > just-released R2.10.0 on Windows. > > object.size() has problems when working on Rd objects, because it counts > every environment separately, even though they may all be references to > the same one. I haven't looked at your code, but that could be a problem. > > Mark From: Duncan Murdoch [murd...@stats.uwo.ca] Sent: 31 October 2009 08:59 To: Bravington, Mark (CMIS, Hobart) Cc: r-devel@r-project.org Subject: Re: [Rd] parse_Rd and/or lazyload problem On 30/10/2009 12:50 AM, mark.braving...@csiro.au wrote: > I'm encountering problems when making lazy-loadable databases of the output > from 'parse_Rd'. The lazy-load database is of seemingly limitless size when I > try to reload it... Admittedly I am using functions that I'm not really > supposed to use, which is why this isn't a bug report, but there does seem to > be something strange going on; my code is very similar to code that lives > inside 'tools:::.install_package_Rd_objects'. The problems occur with > just-released R2.10.0 on Windows. object.size() has problems when working on Rd objects, because it counts every environment separately, even though they may all be references to the same one. I haven't looked at your code, but that could be a problem. Duncan Murdoch > > The examples below use files which can be found at > ftp://ftp.csiro.au/MarkBravington, but you'll obviously need to modify the > paths. The file "scrunge.Rd" is just "Rdiff.Rd" from the 'tools' package. The > file "fakepack.7z" should unzip to create a fake package with a DESCRIPTION > file and a "man" directory that contains two Rd files. > > Transcript of first example: > eglist <- list( scrunge=tools:::prepare_Rd( 'd:/temp/scrunge.Rd', > defines=.Platform$OS.type, stages='install', warningCalls=FALSE)) > tools:::makeLazyLoadDB( eglist, 'd:/temp/ll', compress=FALSE) > tools:::fetchRdDB( 'd:/temp/ll') > # Error: cannot allocate vector of size 1.4 Gb > > The second example triggers an error with > 'tools:::.install_package_Rd_objects' itself. It doesn't happen the first > time, but frequently does after the Rd files have been changed. Transcript: > > # Make sure d:/temp/help/ is empty, then > test> tools:::.install_package_Rd_objects( 'd:/temp/fakepack', 'd:/temp') > test> tools:::fetchRdDB( 'd:/temp/help/temp') > # All good. Next, I *removed* one of the two Rd files in > "d:/temp/fakepack/man", ... > # ...deleted "d:/temp/help/temp*", and tried again > test> tools:::.install_package_Rd_objects( 'd:/temp/fakepack', 'd:/temp') > test> tools:::fetchRdDB( 'd:/temp/help/temp') > Warning: Reached total allocation of 1535Mb: see help(memory.size) > Warning: Reached total allocation of 1535Mb: see help(memory.size) > Warning: Reached total allocation of 1535Mb: see help(memory.size) > Warning: Reached total allocation of 1535Mb: see help(memory.size) > Error: cannot allocate vector of size 1.9 Gb > # Or on other occasions I get > Error: internal error -3 in R_decompress1 > > Mark Bravington > CSIRO CMIS > Hobart > Australia > > --please do not edit the information below-- > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = > major = 2 > minor = 10.0 > year = 2009 > month = 10 > day = 26 > svn rev = 50208 > language = R > version.string = R version 2.10.0 (2009-10-26) > Windows XP (build 2600) Service Pack 2 > Locale: > LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 > Search Path: > .GlobalEnv, ROOT, package:grDevices, package:ad, package:chstuff, > package:handy2, package:tweedie, package:statmod, package:handy, > package:debug, package:mvbutils, mvb.session.info, package:tools, > package:tcltk, package:stats, package:graphics, package:utils, > package:methods, Autoloads, package:base > __ > 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] Suggestion for exception handling: More informative error message for "no applicable method..." (S3)
Thanks for this silent update, whoever did it:
> foo <- function(...) UseMethod("foo")
> foo.ClassA <- function(object, ...) { cat("foo() for ClassA called.\n") }
> foo(structure(1, class="ClassA"))
foo() for ClassA called.
> foo(NULL)
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class "NULL"
> foo(Sys.time())
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class
"c('POSIXt', 'POSIXct')"
This is great.
> sessionInfo()
R version 2.10.0 Patched (2009-10-26 r50212)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
/Henrik
On Tue, Oct 20, 2009 at 12:44 PM, Henrik Bengtsson
wrote:
> I'd like to suggest that whenever there is no S3 method implementation
> available for a particular class, that the error message would also
> report the class structure of the object dispatched on.
>
> Example:
>
> foo <- function(...) UseMethod("foo")
> foo.ClassA <- function(object, ...) { cat("foo() for ClassA called.\n") }
>
>> foo(structure(1, class="ClassA"))
> foo() for ClassA called.
>
> Now:
>
>> foo(NULL)
> Error in UseMethod("foo") : no applicable method for "foo"
>
>> foo(Sys.time())
> Error in UseMethod("foo") : no applicable method for "foo"
>
> Suggestion:
>
>> foo(NULL)
> Error in UseMethod("foo") : no applicable foo() method: list
>
>> foo(Sys.time())
> Error in UseMethod("foo") : no applicable foo() method: POSIXt, POSIXct
>
> This would really help troubleshooting, especially when running in
> batch mode where you don't have direct access to the object without
> modifying the script and/or functions.
>
> /Henrik
>
> PS. I know that one as a workaround can create a "default" method that
> reports this, but I believe it is much better that the builtin
> exception handling should report this/carry this information.
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
