Re: [Rd] help.start() displays index.html in emacs (PR#13293)
On Sun, 16 Nov 2008, [EMAIL PROTECTED] wrote: Full_Name: Juergen Rose Version: 2.8.0 (2008-10-20) OS: Linux 2.6.27.4 x86_64 Intel Submission from: (NULL) (87.185.220.122) If I start as ordinary user rose R and help.start(), the help is displayed in emacs. If I do as the user root, file:///tmp/Rtmpyzlc7Y/.R/doc/html/index.html is shown as expected in a firefox windows. So it seems to be connected with my private configuration. But I can not find such a configurations: So why report this as a bug in R (especially without reading the help pages concerned)? help.start uses R_BROWSER to select the browser in use via browseURL: see the help for help.start and browseURL. Check options(browser) in each of the accounts. Another thing you have not told us is how you installed R: the default for R_BROWSER is set at install time in R_HOME/etc/Renviron. However, as it works correctly for 'root', I guess it is your account that has some setting of the browser to be used. [EMAIL PROTECTED]:/home/rose(114)$ ll ~/.R* -rw-r--r-- 1 rose users 2369 Jan 20 2008 /home/rose/.RapidSVN I also tried to start R with strace: [EMAIL PROTECTED]:/home/rose(119)$ strace -f -o R_strace.log R and greped for mime: [EMAIL PROTECTED]:/home/rose(120)$ grep open.*rose.*mime R_strace.log 7221 open(/home/rose/.local/share//mime/mime.cache, O_RDONLY) = 14 7221 open(/home/rose/.local/share/applications/mimeinfo.cache, O_RDONLY) = 14 7221 open(/home/rose/.local/share/applications/mimeapps.list, O_RDONLY) = 14 7223 open(/home/rose/.local/share//mime/mime.cache, O_RDONLY) = 7 and then I searched for emacs in these files: [EMAIL PROTECTED]:/home/rose(121)$ for f in /home/rose/.local/share//mime/mime.cache /home/rose/.local/share/applications/mimeinfo.cache /home/rose/.local/share/applications/mimeapps.list /home/rose/.local/share//mime/mime.cache; do echo -- f=$f --; grep emacs $f ; done -- f=/home/rose/.local/share//mime/mime.cache -- -- f=/home/rose/.local/share/applications/mimeinfo.cache -- application/x-x509-ca-cert=emacs-21-usercustom.desktop -- f=/home/rose/.local/share/applications/mimeapps.list -- -- f=/home/rose/.local/share//mime/mime.cache -- But I could not find anything suspicious __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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] chisq.test with simulate.p.value=TRUE (PR#13292)
G'day Reginaldo, On Sun, 16 Nov 2008 01:00:09 +0100 (CET) [EMAIL PROTECTED] wrote: Full_Name: Reginaldo Constantino Version: 2.8.0 OS: Ubuntu Hardy (32 bit, kernel 2.6.24) Submission from: (NULL) (189.61.88.2) For many tables, chisq.test with simulate.p.value=TRUE gives a p value that is obviously incorrect and inversely proportional to the number of replicates: Why is this Monte-Carlo p-value obviously incorrect? In your example, did you look at the observed ChiSquare statistics? Any idea how likely it is to observe a value that is at least as extreme as the one observed? Essentially, you are doing B Monte-Carlo simulations and in none of these simulations do you obtain a statistic that is at least as extreme as the one that you have observed. So your Monte-Carlo p-value ends up to be 1/(B+1). I do not see any problem or bug here. data(HairEyeColor) x - margin.table(HairEyeColor, c(1, 2)) chisq.test(x,simulate.p.value=TRUE,B=2000) Pearson's Chi-squared test with simulated p-value (based on 2000 replicates) data: x X-squared = 138.2898, df = NA, p-value = 0.0004998 chisq.test(x,simulate.p.value=TRUE,B=1) X-squared = 138.2898, df = NA, p-value = 1e-04 chisq.test(x,simulate.p.value=TRUE,B=10) X-squared = 138.2898, df = NA, p-value = 1e-05 chisq.test(x,simulate.p.value=TRUE,B=100) X-squared = 138.2898, df = NA, p-value = 1e-06 ... Also tested the same R version under Windows XP and got the same results. Cheers, Berwin === Full address = Berwin A TurlachTel.: +65 6516 4416 (secr) Dept of Statistics and Applied Probability+65 6516 6650 (self) Faculty of Science FAX : +65 6872 3919 National University of Singapore 6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED] Singapore 117546http://www.stat.nus.edu.sg/~statba __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stringsAsFactors = FALSE
Hi all, I love the option to not automatically convert strings into factors, but there are three places that the current option doesn't work where I think it should: options(stringsAsFactors = FALSE) str(expand.grid(letters)) str(type.convert(letters)) df - read.fwf(textConnection(paste(letters,collapse=\n)), 1) str(df) I think type.convert and read.fwf can be fixed by giving them a stringsAsFactors argument and then using asis = !stringsAsFactors (like read.table). The key lines in expand.grid would seem to be if (!is.factor(x) is.character(x)) x - factor(x, levels = unique(x)) but I'm not sure why they are being converted to factors in the first place. Regards, Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R problem with the seq function (PR#13295)
Hello, =20 Something wrong happens when I use the seq (function). Here it is an exampl= e from my R console, I have the R version 2.7.2 (2008-08-25) running on Mic= rosoft windows XP Version 2002 Service Pack 3, and my machine is a Dell Opt= ilex GX280 with a processor Intel Pentium 4 CPU 2.80GHhz, 0.99 GB RAM: =20 =20 r=3Dseq(0.150,0.180,0.001) =20 r[16] =20 [1] 0.165 =20 class(r[16]) =20 [1] numeric =20 for (i in (150:180)/1000) =20 + show(which(r=3D=3Di)) =20 [1] 1 [1] 2 [1] 3 [1] 4 [1] 5 [1] 6 [1] 7 [1] 8 [1] 9 [1] 10 [1] 11 [1] 12 [1] 13 [1] 14 [1] 15 integer(0) integer(0) integer(0) integer(0) integer(0) integer(0) integer(0) [1] 23 [1] 24 [1] 25 [1] 26 [1] 27 [1] 28 [1] 29 [1] 30 [1] 31 =20 Could you explain me why from the 16th element to the 22nd the value is int= eger (0) ? I really don't understand... so it would be very nice of you to= do it. =20 Best regards=20 =20 Fabien Roussel,=20 Student=20 Institute of Marine Research Troms=F8 Norway [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R problem with the seq function (PR#13295)
From the FAQ, section 9.1 If a command does the wrong thing, that is a bug. But be sure you know for certain what it ought to have done. If you aren't familiar with the command, or don't know for certain how the command is supposed to work, then it might actually be working right. For example, people sometimes think there is a bug in R's mathematics because they don't understand how finite-precision arithmetic works. Rather than jumping to conclusions, show the problem to someone who knows for certain. Unexpected results of comparison of decimal numbers, for example `0.28 * 100 != 28' or `0.1 + 0.2 != 0.3', are not a bug. See FAQ 7.31 for more details. As a student, you should seek advice from your teachers about things you 'really don't understand'. On Mon, 17 Nov 2008, [EMAIL PROTECTED] wrote: Hello, =20 Something wrong happens when I use the seq (function). Here it is an exampl= e from my R console, I have the R version 2.7.2 (2008-08-25) running on Mic= rosoft windows XP Version 2002 Service Pack 3, and my machine is a Dell Opt= ilex GX280 with a processor Intel Pentium 4 CPU 2.80GHhz, 0.99 GB RAM: =20 =20 r=3Dseq(0.150,0.180,0.001) =20 r[16] =20 [1] 0.165 =20 class(r[16]) =20 [1] numeric =20 for (i in (150:180)/1000) =20 + show(which(r=3D=3Di)) =20 [1] 1 [1] 2 [1] 3 [1] 4 [1] 5 [1] 6 [1] 7 [1] 8 [1] 9 [1] 10 [1] 11 [1] 12 [1] 13 [1] 14 [1] 15 integer(0) integer(0) integer(0) integer(0) integer(0) integer(0) integer(0) [1] 23 [1] 24 [1] 25 [1] 26 [1] 27 [1] 28 [1] 29 [1] 30 [1] 31 =20 Could you explain me why from the 16th element to the 22nd the value is int= eger (0) ? I really don't understand... so it would be very nice of you to= do it. =20 Best regards=20 =20 Fabien Roussel,=20 Student=20 Institute of Marine Research Troms=F8 Norway [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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] stringsAsFactors = FALSE
On Mon, 17 Nov 2008, hadley wickham wrote: Hi all, I love the option to not automatically convert strings into factors, but there are three places that the current option doesn't work where I think it should: Perhaps you mean 'when I would like it to'? Things *should* work as documented, surely? options(stringsAsFactors = FALSE) str(expand.grid(letters)) str(type.convert(letters)) df - read.fwf(textConnection(paste(letters,collapse=\n)), 1) str(df) I get str(df) 'data.frame': 26 obs. of 1 variable: $ V1: chr a b c d ... so what is wrong with that? read.fwf just calls read.table, so the default options of read.table apply. I think type.convert and read.fwf can be fixed by giving them a stringsAsFactors argument and then using asis = !stringsAsFactors (like read.table). Seems to me that there is nothing wrong with read.fwf. For type.convert() we could have the default as.is = !default.stringsAsFactors() but I think a strong case needs to be made to change the documented behaviour. The key lines in expand.grid would seem to be if (!is.factor(x) is.character(x)) x - factor(x, levels = unique(x)) but I'm not sure why they are being converted to factors in the first place. Nor I am, but it goes back to at least r2107, over 10 years ago. I don't see much problem with adding a 'stringsAsFactors' argument there. -- Brian D. Ripley, [EMAIL PROTECTED] 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] stringsAsFactors = FALSE
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of hadley wickham Sent: Monday, November 17, 2008 5:10 AM To: r-devel@r-project.org Subject: [Rd] stringsAsFactors = FALSE ... The key lines in expand.grid would seem to be if (!is.factor(x) is.character(x)) x - factor(x, levels = unique(x)) but I'm not sure why they are being converted to factors in the first place. I think expand.grid converts input strings to factors so they retain the order they have in the input. (Note that the levels argument is unique(x), not the sort(unique(x)) that data.frame uses.) People generally give expand.grid sorted input and expect it to not alter the order (the order of the levels affects tables and and some plots). lapply(expand.grid(Grade=c(Bad,Good,Better),Size=c(Small,Medium ,Large)), levels) $Grade [1] BadGood Better $Size [1] Small Medium Large lapply(data.frame(Grade=c(Bad,Good,Better),Size=c(Small,Medium ,Large)), levels) $Grade [1] BadBetter Good $Size [1] Large Medium Small I have nothing against adding the stringsAsFactors argument to expand.grid. Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stringsAsFactors = FALSE
On Mon, 17 Nov 2008, Prof Brian Ripley wrote: On Mon, 17 Nov 2008, hadley wickham wrote: Hi all, I love the option to not automatically convert strings into factors, but there are three places that the current option doesn't work where I think it should: Perhaps you mean 'when I would like it to'? Things *should* work as documented, surely? options(stringsAsFactors = FALSE) str(expand.grid(letters)) str(type.convert(letters)) df - read.fwf(textConnection(paste(letters,collapse=\n)), 1) str(df) I get str(df) 'data.frame': 26 obs. of 1 variable: $ V1: chr a b c d ... so what is wrong with that? read.fwf just calls read.table, so the default options of read.table apply. I think type.convert and read.fwf can be fixed by giving them a stringsAsFactors argument and then using asis = !stringsAsFactors (like read.table). Seems to me that there is nothing wrong with read.fwf. For type.convert() we could have the default as.is = !default.stringsAsFactors() but I think a strong case needs to be made to change the documented behaviour. It seems only to be used in RODBC (where I have some extra control pending), simecol and BioC:beadarraySNP (both with as.is=TRUE) and reshape (author, one Hadley Wickham). Given it is documented as a help utilty, it seems up to the caller to set the behaviour he wants. The key lines in expand.grid would seem to be if (!is.factor(x) is.character(x)) x - factor(x, levels = unique(x)) but I'm not sure why they are being converted to factors in the first place. Nor I am, but it goes back to at least r2107, over 10 years ago. I don't see much problem with adding a 'stringsAsFactors' argument there. -- Brian D. Ripley, [EMAIL PROTECTED] 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 -- Brian D. Ripley, [EMAIL PROTECTED] 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] stringsAsFactors = FALSE
On Mon, Nov 17, 2008 at 11:06 AM, William Dunlap [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of hadley wickham Sent: Monday, November 17, 2008 5:10 AM To: r-devel@r-project.org Subject: [Rd] stringsAsFactors = FALSE ... The key lines in expand.grid would seem to be if (!is.factor(x) is.character(x)) x - factor(x, levels = unique(x)) but I'm not sure why they are being converted to factors in the first place. I think expand.grid converts input strings to factors so they retain the order they have in the input. (Note that the levels argument is unique(x), not the sort(unique(x)) that data.frame uses.) People generally give expand.grid sorted input and expect it to not alter the order (the order of the levels affects tables and and some plots). Ah, that makes sense. (Although the conversion to factors just seems to be a convenient way to achieve the desired effect in this case - there's no reason they have to be factors in the output) Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stringsAsFactors = FALSE
On Mon, Nov 17, 2008 at 9:03 AM, Prof Brian Ripley [EMAIL PROTECTED] wrote: On Mon, 17 Nov 2008, hadley wickham wrote: Hi all, I love the option to not automatically convert strings into factors, but there are three places that the current option doesn't work where I think it should: Perhaps you mean 'when I would like it to'? Things *should* work as documented, surely? In an ideal world, I think things should be documented *and* consistent. options(stringsAsFactors = FALSE) str(expand.grid(letters)) str(type.convert(letters)) df - read.fwf(textConnection(paste(letters,collapse=\n)), 1) str(df) I get str(df) 'data.frame': 26 obs. of 1 variable: $ V1: chr a b c d ... so what is wrong with that? read.fwf just calls read.table, so the default options of read.table apply. Ok, that's weird. I get factors. I think type.convert and read.fwf can be fixed by giving them a stringsAsFactors argument and then using asis = !stringsAsFactors (like read.table). Seems to me that there is nothing wrong with read.fwf. For type.convert() we could have the default as.is = !default.stringsAsFactors() but I think a strong case needs to be made to change the documented behaviour. Well, my intuition was that type.convert should mirror the behaviour of read.table, since it is what does the conversion behind the scenes. I can of course change my own code. The key lines in expand.grid would seem to be if (!is.factor(x) is.character(x)) x - factor(x, levels = unique(x)) but I'm not sure why they are being converted to factors in the first place. Nor I am, but it goes back to at least r2107, over 10 years ago. I don't see much problem with adding a 'stringsAsFactors' argument there. Great, thanks. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stringsAsFactors = FALSE
William Dunlap wrote: but I'm not sure why they are being converted to factors in the first place. I think expand.grid converts input strings to factors so they retain the order they have in the input. Yep. These things do matter. Incidentally, I recently got burned by cooking an example using expand.grid, writing the data to a file with write.table and reading it back in during lecture with read.table. Odds ratio turned upside down... -- 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] stringsAsFactors = FALSE
WD == William Dunlap [EMAIL PROTECTED]
on Mon, 17 Nov 2008 09:06:49 -0800 writes:
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
hadley wickham Sent: Monday, November 17, 2008 5:10 AM
To: r-devel@r-project.org Subject: [Rd] stringsAsFactors
= FALSE ... The key lines in expand.grid would seem to
be
if (!is.factor(x) is.character(x)) x - factor(x,
levels = unique(x))
but I'm not sure why they are being converted to factors
in the first place.
WD I think expand.grid converts input strings to factors so
WD they retain the order they have in the input. (Note
WD that the levels argument is unique(x), not the
WD sort(unique(x)) that data.frame uses.) People generally
WD give expand.grid sorted input and expect it to not alter
WD the order (the order of the levels affects tables and
WD and some plots).
WD lapply(expand.grid(Grade=c(Bad,Good,Better),Size=c(Small,Medium
WD ,Large)), levels) $Grade [1] Bad Good Better
WD $Size [1] Small Medium Large
WD lapply(data.frame(Grade=c(Bad,Good,Better),Size=c(Small,Medium
WD ,Large)), levels) $Grade [1] Bad Better Good
WD $Size [1] Large Medium Small
WD I have nothing against adding the stringsAsFactors
WD argument to expand.grid.
That's fine, but I am VERY MUCH against
making the default of that argument depend on the ominous
default.stringsAsFactors()
which is determined by getOption(stringsAsFactors).
Why would I hate such a change very much :
Note that we have here an option which would change the
result of a standard R (S) function expand.grid().
Whereas I already did not like that change when it happened for
read.table(), in that case, one could at least say, that
read.table() is in some way platform dependent
{(because it
typically depends on files of the local platform, but as we
know this is not true even there; even now, if I tell my
students, or a book author tells her readers to use
read.table(http://.;) I can no longer be sure that my
students get the same data frame, because they could have
different settings of getOptions(stringsAsFactors)
horrible, really!! )}
Please, R should stay as much a functional language as possible
and sensible!
If we start having global options more and more influence
the result of standard R functions, we are going down a very
slippery rope, and one that is making R even more idionsyncratic
than it already needs to be.
Please, no !!
Rather revert the read.table() default of stringsAsFactors to
not depend on the option, and maybe provide another set of short
forms of the various
read.table(*, stringsAsFactors=FALSE)
incantations such that
all the factor-haters-string-lovers can use these short forms...
At the very first DSC, 1999, Joe Eaton, author of GNU octave,
told us how he regretted that he had started going down that bad
path, because users had started asking for it.
In the extreme case, we are ending up with a language that
depends on a whole huge status setting, and what a given
function computes can no longer be predicted by looking at the
function calls, unless you simultaneously know that whole status.
Please, No !!
Martin Maechler, ETH Zurich
WD Bill Dunlap TIBCO Software Inc - Spotfire Division
WD wdunlap tibco.com
WD __
WD R-devel@r-project.org mailing list
WD https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] lines.formula() problem when data argument is missing (PR#13296)
Full_Name: Steven McKinney
Version: R 2.8.0 Patched svn rev 46845
OS: powerpc-apple-darwin9.5.0
Submission from: (NULL) (142.103.207.10)
insert bug report here
lines.formula() throws an error when subset argument is used but nothing is
provided for data argument.
Reproduce:
x-1:5
y-c(1,3,NA,2,5)
plot(y~x, type=n) # set up frame
lines(y~x, subset=!is.na(y)) # works OK
lines(y~x, type=o, col=blue) # works OK
# but
lines(y~x, subset=!is.na(y), col=red) # gives an error:
This situation is handled appropriately by points.formula().
Following the coding style of points.formula() the
proposed modifications would be
lines.formula -
function (formula, data = parent.frame(), ..., subset)
{
m - match.call(expand.dots = FALSE)
if (is.matrix(eval(m$data, parent.frame(
m$data - as.data.frame(data)
dots - m$...
dots - lapply(dots, eval, data, parent.frame())
m$... - NULL
m[[1]] - as.name(model.frame)
m - as.call(c(as.list(m), list(na.action = NULL)))
mf - eval(m, parent.frame())
if (!missing(subset)) {
s - eval(m$subset, data, parent.frame())
###current
### l - nrow(data)
###\current
###new (as per points.formula)
if (!missing(data)) {
l - nrow(data)
}
else {
mtmp - m
mtmp$subset - NULL
l - nrow(eval(mtmp, parent.frame()))
}
###\new
dosub - function(x) if (length(x) == l)
x[s]
else x
###current
###dots - lapply(dots, dosub, s)
###\current
###new (as per points.formula)
dots - lapply(dots, dosub)
###\new
}
response - attr(attr(mf, terms), response)
if (response) {
varnames - names(mf)
y - mf[[response]]
if (length(varnames) 2)
stop(cannot handle more than one 'x' coordinate)
xn - varnames[-response]
if (length(xn) == 0)
do.call(lines, c(list(y), dots))
else do.call(lines, c(list(mf[[xn]], y), dots))
}
else stop(must have a response variable)
}
Original report from R-help was:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of John Field
Sent: Thursday, November 13, 2008 4:41 PM
To: [EMAIL PROTECTED]
Subject: [R] lines.formula with subset
Dear list,
When I try to use lines.formula with subset and another argument I
get an error.
e.g.
x-1:5
y-c(1,3,NA,2,5)
plot(y~x, type=n) # set up frame
lines(y~x, subset=!is.na(y)) # works OK
lines(y~x, type=o, col=blue) # works OK
# but
lines(y~x, subset=!is.na(y), col=red) # gives an error:
Error in if (length(x) == l) x[s] else x : argument is of length zero
Why does this happen?
It happens because the function
graphics:::lines.formula
tries to assess the number of rows of data in the data frame
containing the variables in the formula y~x
(see the line of code
l - nrow(data)
in graphics:::lines.formula
This is the 'el' in the 'length(x) == l'
portion of the line you see in the error message)
Because you did not provide the data frame,
nrow(data) returns NULL, and thus the
if() clause is 'length(x) == NULL' which
yields answer logical(0), an invalid
answer in an if() clause.
Done this way, all is well:
mydf - data.frame(x = 1:5, y = c(1,3,NA,2,5))
plot(y~x, type=n, data = mydf) # set up frame
lines(y~x, subset=!is.na(y), data = mydf) # works OK
lines(y~x, type=o, col=blue, data = mydf) # works OK
lines(y~x, subset=!is.na(y), col=red, data = mydf) # works OK
The formula - based functions expect to see a dataframe object
from the 'data' arg, but don't enforce this in this case.
This may qualify as a logical bug in the graphics:::lines.formula
function. An error should have been thrown before the if()
clause evaluation, but I'm not sure where in the chain of
function calls the check for a valid data object should be
done and the error thrown. Otherwise, the data objects
y and x that you set up should have been passed downwards
in some fashion for evaluation. R-core members who know
the rules better than I will have to determine how best to
handle this one.
HTH
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
With thanks,
John
=
John Field Consulting Pty Ltd
10 High Street, Burnside SA 5066
Phone 08 8332 5294 or 0409 097 586
Fax 08 8332 1229
Email [EMAIL PROTECTED]
__
[EMAIL PROTECTED] 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.
--please do not edit the information below--
Version:
platform = powerpc-apple-darwin9.5.0
arch = powerpc
os =
[Rd] assign(FALSE, TRUE)
It was recently pointed out by Wacek Kusnierczyk that although one is
prevented from doing
FALSE - TRUE
one *can* do
assign(FALSE,TRUE)
and have an object named ``FALSE'' with value TRUE in one's workspace.
This apparently has no deleterious effects; e.g. doing
sample(1:7,replace=FALSE)
gives a random permutation of 1:7 as expected and desired. I.e. the
local object named ``FALSE'' is not used.
Still, this seems counterintuitive and a bit confusing. Is it the
intended
state of affairs? I would have thought that
FALSE - whatever
and
assign(FALSE,whatever)
would be completely equivalent.
This is clearly not a very important issue, but it might bear some
thinking about.
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
RT == Rolf Turner [EMAIL PROTECTED] on Tue, 18 Nov 2008 08:49:21 +1300 writes: RT It was recently pointed out by Wacek Kusnierczyk that RT although one is prevented from doing RT FALSE - TRUE RT one *can* do RT assign(FALSE,TRUE) RT and have an object named ``FALSE'' with value TRUE in RT one's workspace. RT This apparently has no deleterious effects; e.g. doing RT sample(1:7,replace=FALSE) RT gives a random permutation of 1:7 as expected and RT desired. I.e. the local object named ``FALSE'' is not RT used. RT Still, this seems counterintuitive and a bit confusing. RT Is it the intended state of affairs? I would have RT thought that RT FALSE - whatever RT and RT assign(FALSE,whatever) RT would be completely equivalent. Yes, such thoughts are understandable but wrong as you now know. Clearly assign(a b c, abc) does work, but a b c - abc does not; only `a b c` - abc does, as well as `FALSE` - TRUE and Wacek did mention the backticks. But in spite of all that I agree that I'd have liked `FALSE` - whatever to signal an error about the fact that it is a reserved word. RT This is clearly not a very important issue, but it might RT bear some thinking about. Yes. I'd propose that R-core look into how to make assignment to a reserved word an error. Thank you, Rolf, Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
Rolf Turner wrote: It was recently pointed out by Wacek Kusnierczyk that although one is prevented from doing FALSE - TRUE one *can* do assign(FALSE,TRUE) and have an object named ``FALSE'' with value TRUE in one's workspace. This apparently has no deleterious effects; e.g. doing sample(1:7,replace=FALSE) gives a random permutation of 1:7 as expected and desired. I.e. the local object named ``FALSE'' is not used. Still, this seems counterintuitive and a bit confusing. Is it the intended state of affairs? I would have thought that FALSE - whatever and assign(FALSE,whatever) would be completely equivalent. No, FALSE is a _keyword_ representing the logical value. e - quote(`FALSE` FALSE) e[[2]] `FALSE` e[[3]] [1] FALSE mode(e[[3]]) [1] logical mode(e[[2]]) [1] name The thing that is equivalent to assign(FALSE,whatever) is `FALSE`-whatever. There are a couple of other keywords: TRUE, if, else, for, while, repeat, next, break, function. Did I forget any? The stuff you can do with FALSE isn't really any stranger than `2` - pi 2+2 [1] 4 so that two and two remains four for any value of `2`. You can't do 2-pi anymore than you can do FALSE-foo. This is clearly not a very important issue, but it might bear some thinking about. -- 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] assign(FALSE, TRUE)
Martin Maechler wrote: But in spite of all that I agree that I'd have liked `FALSE` - whatever to signal an error about the fact that it is a reserved word. RT This is clearly not a very important issue, but it might RT bear some thinking about. Yes. I'd propose that R-core look into how to make assignment to a reserved word an error. I disagree. In a sense, this is the point of having the backtick operator: allowing you to work with names that would otherwise be syntax errors (notice that such names are sometimes created outside your control, e.g. via column names in data frames). If you start disallowing some of them again, well, that way lies madness! -- 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
[Rd] checking for executable files ... WARNING
In R 2.8. I get the following warning when checking my package: * checking for executable files ... WARNING Found the following executable file(s): .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 ... (for about 300 lines) I've tried putting .git in my .Rbuildignore, but this doesn't help the problem. Any ideas? Thanks, Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chisq.test with simulate.p.value=TRUE (PR#13292)
constant at unb.br writes: Full_Name: Reginaldo Constantino Version: 2.8.0 OS: Ubuntu Hardy (32 bit, kernel 2.6.24) Submission from: (NULL) (189.61.88.2) For many tables, chisq.test with simulate.p.value=TRUE gives a p value that is obviously incorrect and inversely proportional to the number of replicates: data(HairEyeColor) x - margin.table(HairEyeColor, c(1, 2)) chisq.test(x,simulate.p.value=TRUE,B=2000) Pearson's Chi-squared test with simulated p-value (based on 2000 replicates) data: x X-squared = 138.2898, df = NA, p-value = 0.0004998 chisq.test(x,simulate.p.value=TRUE,B=1) X-squared = 138.2898, df = NA, p-value = 1e-04 chisq.test(x,simulate.p.value=TRUE,B=10) X-squared = 138.2898, df = NA, p-value = 1e-05 chisq.test(x,simulate.p.value=TRUE,B=100) X-squared = 138.2898, df = NA, p-value = 1e-06 ... Also tested the same R version under Windows XP and got the same results. Could you explain why this is wrong? The data are extremely unlikely under the null hypothesis (the standard chisq.test() gives p2.2e-16), so the result of the simulation protocol is always 1/(B+1); that is, as is standard with these protocols, the observed value is added to the ensemble of simulations. Why is the p value obviously incorrect? cheers Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checking for executable files ... WARNING
On Mon, 17 Nov 2008, hadley wickham wrote: In R 2.8. I get the following warning when checking my package: * checking for executable files ... WARNING Found the following executable file(s): .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 ... (for about 300 lines) I've tried putting .git in my .Rbuildignore, but this doesn't help the problem. Any ideas? Does 'R CMD build' a tarball and then 'R CMD check' not solve this? 'build' skips git files, and you only need to worry about executables in a tarball you ship. Thanks, Hadley -- http://had.co.nz/ -- Brian D. Ripley, [EMAIL PROTECTED] 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
