[R] Bug?
Hi! How can I get around in R 2.5.1 in Windows: Error in strsplit(linebuffer, ) : object linebuffer not found It comes a few lines after the actual strsplit, and yesterday everything was fine Thank you in advance Kindest regards, *** Johanna Hasmats Ph.D Student Royal Institute of Technology AlbaNova University Center Stockholm Center for Physics, Astronomy and Biotechnology School of Molecular Biotechnology Department of Gene Technology Visiting address: Roslagstullsbacken 21, Floor 3 106 91 Stockholm, Sweden Delivering address: Roslagsvägen 30 B 104 06 Stockholm, Sweden Phone (office) +46 8 553 783 44 Fax + 46 8 553 784 81 ** [[alternative HTML version deleted]] __ R-help@stat.math.ethz.ch 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.
Re: [R] Bug?
Johanna Hasmats wrote: Hi! How can I get around in R 2.5.1 in Windows: Error in strsplit(linebuffer, ) : object linebuffer not found Why should this be a bug in R, if you have no object named linebuffer in the environments that are on the search path. Uwe Ligges It comes a few lines after the actual strsplit, and yesterday everything was fine… Thank you in advance Kindest regards, *** Johanna Hasmats Ph.D Student Royal Institute of Technology AlbaNova University Center Stockholm Center for Physics, Astronomy and Biotechnology School of Molecular Biotechnology Department of Gene Technology Visiting address: Roslagstullsbacken 21, Floor 3 106 91 Stockholm, Sweden Delivering address: Roslagsvägen 30 B 104 06 Stockholm, Sweden Phone (office) +46 8 553 783 44 Fax + 46 8 553 784 81 ** [[alternative HTML version deleted]] __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug?
On 8/31/07, Uwe Ligges [EMAIL PROTECTED] wrote: Johanna Hasmats wrote: Hi! How can I get around in R 2.5.1 in Windows: Error in strsplit(linebuffer, ) : object linebuffer not found Why should this be a bug in R, if you have no object named linebuffer in the environments that are on the search path. This sounds like it could have something to do with the command completion mechanism through package rcompgen (which does use an internal variable called 'linebuffer'). Since this doesn't seem to be a common problem, you need to give us instructions on how to reproduce it. -Deepayan __ R-help@stat.math.ethz.ch 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] bug in DEoptim package
(the same mail was sent to the author)
When I called the function DEoptim with control=list(strategy=1) or
control=list(strategy=2)
I got the error:
Error in mui[rtd + 1, i] : incorrect number of dimensions
Analysis of the source code of the DEoptim reveals the following fragment
if (con$strategy 5)
st - con$strategy - 5 ## binomial crossover
else {
st - con$strategy ## exponential crossover
mui - sort(t(mui)) ## transpose, collect 1's in each column
for (i in 1:NP) {
n - floor(runif(1) * d)
if (n 0) {
rtd - (rotd + n) %% d
mui[,i] - mui[rtd + 1,i] ## rotate column i by n
}
}
mui - t(mui) ## transpose back
}
sort returns a 1-dimensional vector, this causes the error in the
following indexing operators.
This also shows, that any strategy value from 1 through 5 will cause
this error, while values from 1 through 10 are possible.
Package's DESCRIPTION file contains the following:
Version: 1.1-8
Date: 2007-01-29
My sessionInfo():
sessionInfo()
R version 2.5.1 Patched (2007-08-19 r42614)
i386-pc-mingw32
locale:
LC_COLLATE=Russian_Russia.1251;LC_CTYPE=Russian_Russia.1251;LC_MONETARY=Russian_Russia.1251;LC_NUMERIC=C;LC_TIME=Russian_Russia.1251
attached base packages:
[1] tcltk stats graphics grDevices utils datasets
methods base
other attached packages:
debug mvbutils DEoptim
1.1.0 1.1.1 1.1-8
Unfortunately I haven't submerged deep enough to the algorithm details to
propose the bug fix.
--
View this message in context:
http://www.nabble.com/bug-in-DEoptim-package-tf4353533.html#a12405068
Sent from the R help mailing list archive at Nabble.com.
__
R-help@stat.math.ethz.ch 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] Bug in TAB handling for Win32 rTerm and rGUI in 2.5.1?
Greetings. This seemed like a bug to me, but I wanted to see if this was in fact intended before reporting. Before I start, i want to first extend thanks for the big improvements in integration of command completion for the windows version. Really nice to have now. But i believe there are some issues. In getline/getline.c, the tab case of the charater handling switch statement in getline() simply break;s to the end if tab completion is not enabled, thus eating the tab. Thus, if tab completion is disabled, a tab no longer serves as a tab; it disappears. likewise, in console.c, if k == TABKEY, a return is done without adding the key to kbuf, thus TAB is always discarded, even if completion is disabled. It seems to me that this is wrong. This new TAB behavior now makes it impossible for me to copy/paste text from a text file of R expressions which use TABs. Copy paste behavior which worked in 2.4.x for rTerm now does not, since the discarded TABs mean that keyword separators may disappear, changing the meaning of pasted text. rGUI thankfully still works, since the completion/TAB processing code is bypassed when activating the paste command. I'd like to request the ability to have both --- TAB as a working separator, and the ability to configure the completion key to something other than TAB. This way one can both enjoy completion and successfully copy/paste text containing tabs. Cheers --Rick __ R-help@stat.math.ethz.ch 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] Bug in PDF device when using transparent graphics
Hello, I think I found a bug when creating graphics on a PDF device using transparency. I'm using ggplots2 like this: comp - ggplot(data, aes(x=Problemsize, y=Fitness)) + geom_smooth(fill=alpha(blue, 0.2), aes(colour=factor(Clustersize)), size=2) Which gives me a curve for each Clustersize with a transparent blue cloud around it, indication the standard deviation. Of course, using windows you cannot see this transparent cloud, but when opening a pdf containing the plot in Adobe Acrobat all is displayed properly. But: when printing the resulting pdf, only one of the plotted lines have a transparent stddev, all the others are solid. At first I though this is a bug of the printer driver... But when importing the pdf file to CorelDraw, the result is the same. Only one of the blue stddev markers has a transparency property, the others are simply solid. BTW, trying to crop the pdf by using pdfcrop on linux results in an error. After fixing the missing transparency in CorelDraw and exporting the pdf again, this works as well... I'm not sure if this is a bug or just an improper pdf spec, as Acrobat displays the the pdf properly. Has anyone encountered something like this? Arne __ R-help@stat.math.ethz.ch 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.
Re: [R] bug in closing gzfile-opened connections?
Note that the use of read.table() does make a difference. If you did x - scan(gzfile(xxx.gz), list(,,)) you would leave an unused connection, and showConnections(all=TRUE) would show this. There is a finite pool of connections, and in general the correct way to use them is con - gzfile(xxx.gz) x - scan(con, list(,,)) close(con) read.table() is the exception, so I suspect it is other things that have been done in the session that have used up the pool of connections. On Tue, 3 Jul 2007, Duncan Murdoch wrote: On 03/07/2007 1:37 PM, David Reiss wrote: Hi, I am making multiple calls to gzfile() via read.table(), e.g. x - read.table( gzfile( xxx.gz ) ) After i do this many times (I haven't counted, but probably between 50 and 100 times) I get the error message: Error in open.connection(file, r) : unable to open connection In addition: Warning message: cannot open compressed file 'xxx.gz' however, I also find that: showConnections() description class mode text isopen can read can write so there are no (apparently) open connections. Calling closeAllConnections() does not fix the problem. I have to quit and re-start R. I am using R 2.5.0 on a Mac (OSX 10.4.9). Anyone know if this is a bug or a 'feature'? I see from the gzfile help that: In general functions using connections will open them if they are not open, but then close them again, so to leave a connection open call 'open' explicitly. You didn't give a reproducible example, so I couldn't say. When I create a gzipped version of a write.table output and run for(i in 1:1000) read.table(gzfile(f)) in R 2.5.0 I don't see a problem. This is on Windows, but I doubt that makes a difference. Duncan Murdoch __ R-help@stat.math.ethz.ch 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, [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-help@stat.math.ethz.ch 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] bug in closing gzfile-opened connections?
Hi, I am making multiple calls to gzfile() via read.table(), e.g. x - read.table( gzfile( xxx.gz ) ) After i do this many times (I haven't counted, but probably between 50 and 100 times) I get the error message: Error in open.connection(file, r) : unable to open connection In addition: Warning message: cannot open compressed file 'xxx.gz' however, I also find that: showConnections() description class mode text isopen can read can write so there are no (apparently) open connections. Calling closeAllConnections() does not fix the problem. I have to quit and re-start R. I am using R 2.5.0 on a Mac (OSX 10.4.9). Anyone know if this is a bug or a 'feature'? I see from the gzfile help that: In general functions using connections will open them if they are not open, but then close them again, so to leave a connection open call 'open' explicitly. Thanks. -David [[alternative HTML version deleted]] __ R-help@stat.math.ethz.ch 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.
Re: [R] bug in closing gzfile-opened connections?
On 03/07/2007 1:37 PM, David Reiss wrote: Hi, I am making multiple calls to gzfile() via read.table(), e.g. x - read.table( gzfile( xxx.gz ) ) After i do this many times (I haven't counted, but probably between 50 and 100 times) I get the error message: Error in open.connection(file, r) : unable to open connection In addition: Warning message: cannot open compressed file 'xxx.gz' however, I also find that: showConnections() description class mode text isopen can read can write so there are no (apparently) open connections. Calling closeAllConnections() does not fix the problem. I have to quit and re-start R. I am using R 2.5.0 on a Mac (OSX 10.4.9). Anyone know if this is a bug or a 'feature'? I see from the gzfile help that: In general functions using connections will open them if they are not open, but then close them again, so to leave a connection open call 'open' explicitly. You didn't give a reproducible example, so I couldn't say. When I create a gzipped version of a write.table output and run for(i in 1:1000) read.table(gzfile(f)) in R 2.5.0 I don't see a problem. This is on Windows, but I doubt that makes a difference. Duncan Murdoch __ R-help@stat.math.ethz.ch 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] Bug in seq.date?
seq(as.Date(2000-1-1), as.Date(2001-1-1), months) [1] 2000-01-01 2000-02-01 2000-03-01 2000-04-01 2000-05-01 [6] 2000-06-01 2000-07-01 2000-08-01 2000-09-01 2000-10-01 [11] 2000-11-01 2000-12-01 2001-01-01 seq(as.Date(2000-1-31), as.Date(2001-1-31), months) [1] 2000-01-31 2000-03-02 2000-03-31 2000-05-01 2000-05-31 [6] 2000-07-01 2000-07-31 2000-08-31 2000-10-01 2000-10-31 [11] 2000-12-01 2000-12-31 2001-01-31 Is this a bug? Hadley __ R-help@stat.math.ethz.ch 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.
Re: [R] Bug in seq.date?
No, it's not a bug, it matches with the documentation. see: ?seq.POSIXt Using 'month' first advances the month without changing the day: if this results in an invalid day of the month, it is counted forward into the next month: see the examples. So, it increases the month first, resulting in: 01-31, 02-31, 03-31, 04-31, 05-31, etc Then, for the illegal dates it counts forward. 04-31 becomes 05-01, etc Jonne. On Mon, 2007-06-04 at 09:39 +0200, hadley wickham wrote: seq(as.Date(2000-1-1), as.Date(2001-1-1), months) [1] 2000-01-01 2000-02-01 2000-03-01 2000-04-01 2000-05-01 [6] 2000-06-01 2000-07-01 2000-08-01 2000-09-01 2000-10-01 [11] 2000-11-01 2000-12-01 2001-01-01 seq(as.Date(2000-1-31), as.Date(2001-1-31), months) [1] 2000-01-31 2000-03-02 2000-03-31 2000-05-01 2000-05-31 [6] 2000-07-01 2000-07-31 2000-08-31 2000-10-01 2000-10-31 [11] 2000-12-01 2000-12-31 2001-01-31 Is this a bug? Hadley __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in seq.date?
Note that chron does give the last day of the month: library(chron) seq(chron(1/31/2000), chron(1/31/2001), month) [1] 01/31/00 02/29/00 03/31/00 04/30/00 05/31/00 06/30/00 07/31/00 08/31/00 [9] 09/30/00 10/31/00 11/30/00 12/31/00 01/31/01 The zoo package has a yearmon class whose as.Date.yearmon can convert a Date to the end of the month: library(zoo) library(zoo) as.Date(as.yearmon(seq(as.Date(2000-1-31), as.Date(2001-1-31), month)), 1) [1] 2000-01-31 2000-02-29 2000-03-31 2000-04-30 2000-05-31 [6] 2000-06-30 2000-07-31 2000-08-31 2000-09-30 2000-10-31 [11] 2000-11-30 2000-12-31 2001-01-31 And we do it ourself like this: as.Date(format(seq(as.Date(2000-1-1), as.Date(2001-1-1), month) + 32, %Y-%m-01))-1 [1] 2000-01-31 2000-02-29 2000-03-31 2000-04-30 2000-05-31 [6] 2000-06-30 2000-07-31 2000-08-31 2000-09-30 2000-10-31 [11] 2000-11-30 2000-12-31 2001-01-31 On 6/4/07, hadley wickham [EMAIL PROTECTED] wrote: seq(as.Date(2000-1-1), as.Date(2001-1-1), months) [1] 2000-01-01 2000-02-01 2000-03-01 2000-04-01 2000-05-01 [6] 2000-06-01 2000-07-01 2000-08-01 2000-09-01 2000-10-01 [11] 2000-11-01 2000-12-01 2001-01-01 seq(as.Date(2000-1-31), as.Date(2001-1-31), months) [1] 2000-01-31 2000-03-02 2000-03-31 2000-05-01 2000-05-31 [6] 2000-07-01 2000-07-31 2000-08-31 2000-10-01 2000-10-31 [11] 2000-12-01 2000-12-31 2001-01-31 Is this a bug? Hadley __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in seq.date?
On 6/4/07, Gabor Grothendieck [EMAIL PROTECTED] wrote: Note that chron does give the last day of the month: library(chron) seq(chron(1/31/2000), chron(1/31/2001), month) [1] 01/31/00 02/29/00 03/31/00 04/30/00 05/31/00 06/30/00 07/31/00 08/31/00 [9] 09/30/00 10/31/00 11/30/00 12/31/00 01/31/01 Thanks, that's very useful - I'll switch to using chron instead. Hadley The zoo package has a yearmon class whose as.Date.yearmon can convert a Date to the end of the month: library(zoo) library(zoo) as.Date(as.yearmon(seq(as.Date(2000-1-31), as.Date(2001-1-31), month)), 1) [1] 2000-01-31 2000-02-29 2000-03-31 2000-04-30 2000-05-31 [6] 2000-06-30 2000-07-31 2000-08-31 2000-09-30 2000-10-31 [11] 2000-11-30 2000-12-31 2001-01-31 And we do it ourself like this: as.Date(format(seq(as.Date(2000-1-1), as.Date(2001-1-1), month) + 32, %Y-%m-01))-1 [1] 2000-01-31 2000-02-29 2000-03-31 2000-04-30 2000-05-31 [6] 2000-06-30 2000-07-31 2000-08-31 2000-09-30 2000-10-31 [11] 2000-11-30 2000-12-31 2001-01-31 On 6/4/07, hadley wickham [EMAIL PROTECTED] wrote: seq(as.Date(2000-1-1), as.Date(2001-1-1), months) [1] 2000-01-01 2000-02-01 2000-03-01 2000-04-01 2000-05-01 [6] 2000-06-01 2000-07-01 2000-08-01 2000-09-01 2000-10-01 [11] 2000-11-01 2000-12-01 2001-01-01 seq(as.Date(2000-1-31), as.Date(2001-1-31), months) [1] 2000-01-31 2000-03-02 2000-03-31 2000-05-01 2000-05-31 [6] 2000-07-01 2000-07-31 2000-08-31 2000-10-01 2000-10-31 [11] 2000-12-01 2000-12-31 2001-01-31 Is this a bug? Hadley __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in seq.date?
I think you can easily get the last days of the months by creating a series starting on the first days, and subtracting one from each. seq(as.Date(2000-2-1), as.Date(2001-2-1), months) -1 -Don At 2:01 PM +0200 6/4/07, hadley wickham wrote: On 6/4/07, Gabor Grothendieck [EMAIL PROTECTED] wrote: Note that chron does give the last day of the month: library(chron) seq(chron(1/31/2000), chron(1/31/2001), month) [1] 01/31/00 02/29/00 03/31/00 04/30/00 05/31/00 06/30/00 07/31/00 08/31/00 [9] 09/30/00 10/31/00 11/30/00 12/31/00 01/31/01 Thanks, that's very useful - I'll switch to using chron instead. Hadley The zoo package has a yearmon class whose as.Date.yearmon can convert a Date to the end of the month: library(zoo) library(zoo) as.Date(as.yearmon(seq(as.Date(2000-1-31), as.Date(2001-1-31), month)), 1) [1] 2000-01-31 2000-02-29 2000-03-31 2000-04-30 2000-05-31 [6] 2000-06-30 2000-07-31 2000-08-31 2000-09-30 2000-10-31 [11] 2000-11-30 2000-12-31 2001-01-31 And we do it ourself like this: as.Date(format(seq(as.Date(2000-1-1), as.Date(2001-1-1), month) + 32, %Y-%m-01))-1 [1] 2000-01-31 2000-02-29 2000-03-31 2000-04-30 2000-05-31 [6] 2000-06-30 2000-07-31 2000-08-31 2000-09-30 2000-10-31 [11] 2000-11-30 2000-12-31 2001-01-31 On 6/4/07, hadley wickham [EMAIL PROTECTED] wrote: seq(as.Date(2000-1-1), as.Date(2001-1-1), months) [1] 2000-01-01 2000-02-01 2000-03-01 2000-04-01 2000-05-01 [6] 2000-06-01 2000-07-01 2000-08-01 2000-09-01 2000-10-01 [11] 2000-11-01 2000-12-01 2001-01-01 seq(as.Date(2000-1-31), as.Date(2001-1-31), months) [1] 2000-01-31 2000-03-02 2000-03-31 2000-05-01 2000-05-31 [6] 2000-07-01 2000-07-31 2000-08-31 2000-10-01 2000-10-31 [11] 2000-12-01 2000-12-31 2001-01-31 Is this a bug? Hadley __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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. -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA __ R-help@stat.math.ethz.ch 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.
Re: [R] Bug in seq.date?
On 6/4/07, Don MacQueen [EMAIL PROTECTED] wrote: I think you can easily get the last days of the months by creating a series starting on the first days, and subtracting one from each. seq(as.Date(2000-2-1), as.Date(2001-2-1), months) -1 Thanks for the suggestion, but for my problem the dates are user supplied so I don't know if they fall at the end of the month or not. Hadley __ R-help@stat.math.ethz.ch 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] bug or feature?
R version 2.5.0, under gentoo linux. This may be just my ignorance
about naming conventions inside loops and subsets, but the following
appears like a bug to me.
y = c( 1963, 1963, 1964, 1964, 1965, 1965 );
r1= rnorm(6);
d= data.frame ( y=y, r1=r1 );
## note: I am not attach()ing anything anywhere
## this should give me two results, which it does
ahw.y= subset(d, d$y==1963); print(summary(ahw.y));
## this should give me the same two results, which it does not. All 6
are included now.
for (y in 1963:1963) {
subd= subset(d, d$y==y);
print(summary(subd));
}
## this should give me the same two results, which it does
for (yr in 1963:1963) {
subd= subset(d, d$y==yr);
print(summary(subd));
}
hope this helps. (if its a bother, please let me know and I won't
post such emails anymore. would save me time, too.)
regards,
/ivo
__
R-help@stat.math.ethz.ch 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.
Re: [R] bug or feature?
In the 'subset' function, the 'select' parameter can contain the names of
the columns (without the df$ qualifier). So in your 'for' loop you
basically have
subset(d, d$y ==d$y)
which selects all the data since you have a column name of 'y' which is the
same as your variable.
On 5/17/07, ivo welch [EMAIL PROTECTED] wrote:
R version 2.5.0, under gentoo linux. This may be just my ignorance
about naming conventions inside loops and subsets, but the following
appears like a bug to me.
y = c( 1963, 1963, 1964, 1964, 1965, 1965 );
r1= rnorm(6);
d= data.frame ( y=y, r1=r1 );
## note: I am not attach()ing anything anywhere
## this should give me two results, which it does
ahw.y= subset(d, d$y==1963); print(summary(ahw.y));
## this should give me the same two results, which it does not. All 6
are included now.
for (y in 1963:1963) {
subd= subset(d, d$y==y);
print(summary(subd));
}
## this should give me the same two results, which it does
for (yr in 1963:1963) {
subd= subset(d, d$y==yr);
print(summary(subd));
}
hope this helps. (if its a bother, please let me know and I won't
post such emails anymore. would save me time, too.)
regards,
/ivo
__
R-help@stat.math.ethz.ch 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.
--
Jim Holtman
Cincinnati, OH
+1 513 646 9390
What is the problem you are trying to solve?
[[alternative HTML version deleted]]
__
R-help@stat.math.ethz.ch 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.
Re: [R] bug or feature?
ahh...it is the silent substitution of the data frame in the subset statement. I should have known this. (PS: this may not be desirable behavior; maybe it would be useful to issue a warning if the same name is defined in an upper data frame. just an opinion...) mea misunderstanding. /iaw __ R-help@stat.math.ethz.ch 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.
Re: [R] bug or feature?
... but it **is** explicitly documented in ?subset: For data frames, the subset argument works on the rows. Note that subset will be evaluated in the data frame, so columns can be referred to (by name) as variables in the expression (see the examples). Bert Gunter Genentech Nonclinical Statistics -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ivo welch Sent: Thursday, May 17, 2007 11:53 AM To: jim holtman Cc: r-help Subject: Re: [R] bug or feature? ahh...it is the silent substitution of the data frame in the subset statement. I should have known this. (PS: this may not be desirable behavior; maybe it would be useful to issue a warning if the same name is defined in an upper data frame. just an opinion...) mea misunderstanding. /iaw __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] bug or feature?
of course it is. virtually everything in R is somewhere documented, and once one sees it, pretty well documented, too. my suggestion for a warning is more a matter of user friendliness---a warning, not an error. chances are that if a variable exists in the upper frames, and a user reuses it, there is a good chance that it could be ambiguous. for such cases, a user may be well advised to use subset$variablename explicitly instead of simply variablename IMHO. I believe many C compilers and the perl interpreter routinely issue warnings when there is a good chance that a behavior may not necessarily be what a naive user might expect, even though the code is perfectly correct and unambiguous. of course, I am really NAIVE very often. regards, /ivo On 5/17/07, Bert Gunter [EMAIL PROTECTED] wrote: ... but it **is** explicitly documented in ?subset: For data frames, the subset argument works on the rows. Note that subset will be evaluated in the data frame, so columns can be referred to (by name) as variables in the expression (see the examples). Bert Gunter Genentech Nonclinical Statistics -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ivo welch Sent: Thursday, May 17, 2007 11:53 AM To: jim holtman Cc: r-help Subject: Re: [R] bug or feature? ahh...it is the silent substitution of the data frame in the subset statement. I should have known this. (PS: this may not be desirable behavior; maybe it would be useful to issue a warning if the same name is defined in an upper data frame. just an opinion...) mea misunderstanding. /iaw __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in R 2.4.1 ?
Hi! Replying to my own post: Thanks Duncan for your hint to try the newest version! I did not think of this in the first place as I'm using the newest Ubuntu feisty fawn release which got released a couple of days ago. Nevertheless, the r-cran-hdf5 package is outdated and the newest one available at cran works again as I want it to. So cancel this R bug and and account it for a user bug :-). Greetings, Sebastian On Mon, 2007-04-23 at 11:20 -0400, Duncan Murdoch wrote: On 4/23/2007 10:56 AM, Sebastian Weber wrote: Hello everybody, I'm using hdf5 files to store results from intermediate calculations. These are usually part of a list, called res. As I want the hdf-files to contain all the members of res in its top directory, I used to do attach(res) do.call(hdf5save, args=c(fileout=file.path(dir, ofile), as.list(names(res detach(res) which did what I wanted (R version 2.3.1 under ubuntu edgy). Since the upgrade to ubuntu feisty fawn which ships with R 2.4.1, the code above causes a crash: *** caught segfault *** address 0x11, cause 'memory not mapped' Traceback: 1: .External(do_hdf5save, call, sys.frame(sys.parent()), fileout, ..., PACKAGE = hdf5) 2: hdf5save(fileout = tex/ABpattern_pub/data/knnTest/gTest_annAB.1.statsAll.hdf5, newman, hist, graphProp, graphBins) 3: do.call(hdf5save, args = c(fileout = file.path(dir, ofile), as.list(names(res 4: avgGraphData(dir = tex/ABpattern_pub/data/knnTest) Any ideas on how to fix this or what is wrong? To me it seems to be a bug introduced in R 2.4.1. hdf5save is a function in the hdf5 contributed package, so you should start with its maintainer, Marcus G. Daniels [EMAIL PROTECTED]. But before you bother him, make sure you're using the latest release of it. If you still have problems, give him the usual details requested in the posting guide. Duncan Murdoch __ R-help@stat.math.ethz.ch 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] Bug in xYplot() with method = 'filled bands'
Dear r-helpers,
I have been bitten by a cryptic comment in the help page for xYplot().
Here is some code from Madeline Bauer, one of the authors, which is
essentailly the code on the help page for xYplot():
# This example uses the summarize function in Hmisc to
# compute the median and outer quartiles. The outer quartiles are
# displayed using filled bands
set.seed(111)
dfr - expand.grid(month=1:12, year=c(1997,1998), reps=1:100)
month - dfr$month; year - dfr$year
y - abs(month-6.5) + 2*runif(length(month)) + year-1997
s - summarize(y, llist(month,year), smedian.hilow, conf.int=.5)
# filled bands: default fill = pastel colors matching solid colors
# in superpose.line (this works differently in R)
xYplot ( Cbind ( y, Lower, Upper ) ~ month, groups=year,
method=filled bands , data=s, type=l)
The comment this works differently in R should be ammended to a
more explicit danger sign (otherwise users like myself might find
themselves wasting a great deal of time). There appear to be two
differences between S+ and R here: (1) the default colors of the
bands are not as expected (but they can be changed at will, so that's
not a serious problem); (2) I have not been able get rid of the
outline around the filled bands or change their colors to match the
fill.
I would have thought that ...
xYplot ( Cbind ( y, Lower, Upper ) ~ month, groups=year,
method=filled bands , data=s, type=l, lwd.bands = 0,
lty.bands = 0, col.bands = 'white')
... would do the trick.
I even tried to fix the problem in the code of xYplot:
panel.XYplot
function (x, y, subscripts, groups = NULL, type = if (is.function
(method) ||
...
if (method == filled bands) {
if (.R.)
grid.polygon(x = c(x, rev(x)), y = c(lower, rev(upper)),
gp = gpar(fill = col.fill, col = col.bands,
lty = lty.bands, lwd = lwd.bands),
default.units = native)
else polygon(x = c(x, rev(x)), y = c(lower, rev(upper)),
col = col.fill)
}
...
}
Obviously I don't know grid well enough to fix the problem. Help
would be much appreciated, as well as a more explicit warning on the
xYplot() help page.
There is, of course, the possibility that there's something wrong
with my version of R or my OS or my machine. In that case a
replication or non-replication of this problem on a different OS
might alert me to this.
R version 2.5.0 RC (2007-04-21 r41269)
i386-apple-darwin8.9.1
locale:
C
attached base packages:
[1] grDevices datasets grid graphics stats utils
[7] methods base
other attached packages:
coda lme4 Matrix car
cacheSweave stashR
0.10-7 0.9975-13 0.9975-11 1.2-1
0.3 0.2-1
filehash digest circular boot gmodels
multcompView
0.9-4 0.2.3 0.3-6 1.2-27
2.13.2 0.1-0
reshape vcd colorspace effects
Hmisc acepack
0.7.2 1.0-3 0.95 1.0-10 3.3-1
1.3-2.2
HH multcomp mvtnorm JGR
iplots JavaGD
1.18-30.991-9 0.7-5 1.4-15
1.0-7 0.3-6
MASS gridBase lattice latticeExtra
rJava xtable
7.2-33 0.4-3 0.15-4 0.1-6
0.4-15 1.4-3
Thanks,
Michael Kubovy
__
R-help@stat.math.ethz.ch 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] Bug in R 2.4.1 ?
Hello everybody, I'm using hdf5 files to store results from intermediate calculations. These are usually part of a list, called res. As I want the hdf-files to contain all the members of res in its top directory, I used to do attach(res) do.call(hdf5save, args=c(fileout=file.path(dir, ofile), as.list(names(res detach(res) which did what I wanted (R version 2.3.1 under ubuntu edgy). Since the upgrade to ubuntu feisty fawn which ships with R 2.4.1, the code above causes a crash: *** caught segfault *** address 0x11, cause 'memory not mapped' Traceback: 1: .External(do_hdf5save, call, sys.frame(sys.parent()), fileout, ..., PACKAGE = hdf5) 2: hdf5save(fileout = tex/ABpattern_pub/data/knnTest/gTest_annAB.1.statsAll.hdf5, newman, hist, graphProp, graphBins) 3: do.call(hdf5save, args = c(fileout = file.path(dir, ofile), as.list(names(res 4: avgGraphData(dir = tex/ABpattern_pub/data/knnTest) Any ideas on how to fix this or what is wrong? To me it seems to be a bug introduced in R 2.4.1. Greetings, Sebastian __ R-help@stat.math.ethz.ch 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.
Re: [R] Bug in R 2.4.1 ?
On 4/23/2007 10:56 AM, Sebastian Weber wrote: Hello everybody, I'm using hdf5 files to store results from intermediate calculations. These are usually part of a list, called res. As I want the hdf-files to contain all the members of res in its top directory, I used to do attach(res) do.call(hdf5save, args=c(fileout=file.path(dir, ofile), as.list(names(res detach(res) which did what I wanted (R version 2.3.1 under ubuntu edgy). Since the upgrade to ubuntu feisty fawn which ships with R 2.4.1, the code above causes a crash: *** caught segfault *** address 0x11, cause 'memory not mapped' Traceback: 1: .External(do_hdf5save, call, sys.frame(sys.parent()), fileout, ..., PACKAGE = hdf5) 2: hdf5save(fileout = tex/ABpattern_pub/data/knnTest/gTest_annAB.1.statsAll.hdf5, newman, hist, graphProp, graphBins) 3: do.call(hdf5save, args = c(fileout = file.path(dir, ofile), as.list(names(res 4: avgGraphData(dir = tex/ABpattern_pub/data/knnTest) Any ideas on how to fix this or what is wrong? To me it seems to be a bug introduced in R 2.4.1. hdf5save is a function in the hdf5 contributed package, so you should start with its maintainer, Marcus G. Daniels [EMAIL PROTECTED]. But before you bother him, make sure you're using the latest release of it. If you still have problems, give him the usual details requested in the posting guide. Duncan Murdoch __ R-help@stat.math.ethz.ch 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] ?Bug: '' and '' give different results?
seems to behave strangely and gives different results from e.g. in a data frame selection (regardless whether terms are bracketed)? ===Script=== test=data.frame(gender=c(F,M,M,F,F),side=c(R,L,R,L,R)) test test[test$gender==F test$side==R,] test[test$gender==F test$side==R,] =Output:= test=data.frame(gender=c(F,M,M,F,F),side=c(R,L,R,L,R)) test gender side 1 FR 2 ML 3 MR 4 FL 5 FR test[test$gender==F test$side==R,] gender side 1 FR 5 FR test[test$gender==F test$side==R,] gender side 1 FR 2 ML 3 MR 4 FL 5 FR __ R-help@stat.math.ethz.ch 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.
Re: [R] ?Bug: '' and '' give different results?
As the help page says: '' and '' indicate logical AND and '|' and '||' indicate logical OR. The shorter form performs elementwise comparisons in much the same way as arithmetic operators. The longer form evaluates left to right examining only the first element of each vector. Evaluation proceeds only until the result is determined. The longer form is appropriate for programming control-flow and typically preferred in 'if' clauses. so your results are what I'd expect. Ted. [EMAIL PROTECTED] wrote on 04/02/2007 05:17 PM: seems to behave strangely and gives different results from e.g. in a data frame selection (regardless whether terms are bracketed)? ===Script=== test=data.frame(gender=c(F,M,M,F,F),side=c(R,L,R,L,R)) test test[test$gender==F test$side==R,] test[test$gender==F test$side==R,] =Output:= test=data.frame(gender=c(F,M,M,F,F),side=c(R,L,R,L,R)) test gender side 1 FR 2 ML 3 MR 4 FL 5 FR test[test$gender==F test$side==R,] gender side 1 FR 5 FR test[test$gender==F test$side==R,] gender side 1 FR 2 ML 3 MR 4 FL 5 FR __ R-help@stat.math.ethz.ch 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. -- Dr E.A. Catchpole Visiting Fellow Univ of New South Wales at ADFA, Canberra, Australia _ and University of Kent, Canterbury, England 'v'- www.pems.adfa.edu.au/~ecatchpole / \ - fax: +61 2 6268 8786 m m- ph: +61 2 6268 8895 __ R-help@stat.math.ethz.ch 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] bug in plotrix 2.2
Hi all, Sorry to report that there is a minor bug in the floating.pie function in the new version of plotrix. I inadvertantly changed the bouyancy constant and some users may find that they are farther down the ordinate than they should be. This will be fixed in version 2.2-1. Jim __ R-help@stat.math.ethz.ch 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.
Re: [R] bug in odfWeave
I've verified this bug and will be releasing a new version shortly.
Max
-Original Message-
From: Abhijit Dasgupta [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 23, 2006 12:03 AM
To: r-help@stat.math.ethz.ch; Kuhn, Max
Subject: bug in odfWeave
Hi,
I think there is a minor bug in odfWeave. In the function odfStyleGen,
the following line has an extra =:
if(length(grep(italic, thisStyle$fontType)))
fontText - c(fontText, tagattr(fo:font-style=,
italic))
This is creating an error if some text needs to be formatted as italic,
since the corresponding entry in style.xml is fo:font-style==italic.
For the windows version, which I'm using, I can't correct since the R
files are packaged in odfWeave.rdb (or at least I don't know how).
Hopefully Max Kuhn or someone can update the windows binary to correct
this.
Abhijit Dasgupta
PS: I found the bug after downloading the source files.
--
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
R-help@stat.math.ethz.ch 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] bug in odfWeave
Hi, I think there is a minor bug in odfWeave. In the function odfStyleGen, the following line has an extra =: if(length(grep(italic, thisStyle$fontType))) fontText - c(fontText, tagattr(fo:font-style=, italic)) This is creating an error if some text needs to be formatted as italic, since the corresponding entry in style.xml is fo:font-style==italic. For the windows version, which I'm using, I can't correct since the R files are packaged in odfWeave.rdb (or at least I don't know how). Hopefully Max Kuhn or someone can update the windows binary to correct this. Abhijit Dasgupta PS: I found the bug after downloading the source files. __ R-help@stat.math.ethz.ch 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] bug: Editing function formals deletes the environment
First, here's the specific bug I have. Later I'll say why I care.
ls(zappo)
Error in try(name) : object zappo not found
# good.
f = function(zappo) { function(y) zappo + y }
g = f(1)
g(1)
[1] 2
formals(g)
$y
formals(g)$y
formals(g)$y = 2
g
function (y = 2)
zappo + y
g(1)
Error in g(1) : object zappo not found
# looks like formals strips the environment off stuff.
anything I can do about this?
-Alex
Original question:
I'm trying to change the behaviour of a package, to simplify the
interface.
I'd rather not change the package, although I could.
There's a hidden function whose defaults I wish to change.
I'm using R 2.3.1 for macosX. Upgrading is not an option.
This is what I do:
library(R2HTML)
# get the function to modify
x = getFromNamespace(HTML.data.frame, R2HTML)
# change the default for an argument
formals(x)[Border]=list(NULL)
# put the function back
assignInNamespace(HTML.data.frame, x, R2HTML)
#test the function:
HTML(data.frame(1:2), file=stdout())
Error: could not find function HTMLReplaceNA
# what seems to be happening is that the formals function is
stripping the namespace off the variable x. I can't tell why.
__
R-help@stat.math.ethz.ch 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.
Re: [R] bug: Editing function formals deletes the environment
Ah, it's fixed in 2.4.0. I'll work around it.
-Alex
On 13 Oct 2006, at 11:19, Alex Brown wrote:
First, here's the specific bug I have. Later I'll say why I care.
ls(zappo)
Error in try(name) : object zappo not found
# good.
f = function(zappo) { function(y) zappo + y }
g = f(1)
g(1)
[1] 2
formals(g)
$y
formals(g)$y
formals(g)$y = 2
g
function (y = 2)
zappo + y
g(1)
Error in g(1) : object zappo not found
# looks like formals strips the environment off stuff.
anything I can do about this?
-Alex
Original question:
I'm trying to change the behaviour of a package, to simplify the
interface.
I'd rather not change the package, although I could.
There's a hidden function whose defaults I wish to change.
I'm using R 2.3.1 for macosX. Upgrading is not an option.
This is what I do:
library(R2HTML)
# get the function to modify
x = getFromNamespace(HTML.data.frame, R2HTML)
# change the default for an argument
formals(x)[Border]=list(NULL)
# put the function back
assignInNamespace(HTML.data.frame, x, R2HTML)
#test the function:
HTML(data.frame(1:2), file=stdout())
Error: could not find function HTMLReplaceNA
# what seems to be happening is that the formals function is
stripping the namespace off the variable x. I can't tell why.
__
R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in lowess
Frank Harrell wrote: [...] Thank you Brian. It seems that no matter what is the right answer, the answer currently returned on my system is clearly wrong. lowess()$y should be constrained to be within range(y). Really? That assertion is offered without proof and I am pretty sure is incorrect. Consider x - c(1:10, 20) y - c(1:10, 5) + 0.01*rnorm(11) lowess(x,y) $x [1] 1 2 3 4 5 6 7 8 9 10 20 $y [1] 0.9983192 1.9969599 2.9960805 3.9948224 4.9944158 5.9959855 [7] 6.9964400 7.9981434 8.9990607 10.0002567 19.9946117 Remember that lowess is a local *linear* fitting method, and may give zero weight to some data points, so (as here) it can extrapolate. After reading what src/appl/lowess.doc says should happen with zero weights, I think the answer given on Frank's system probably is the correct one. Rounding error is determining which of the last two points is given zero robustness weight: on a i686 system both of the last two are, and on mine only the last is. As far as I can tell in infinite-precision arithmetic both would be zero, and hence the value at x=120 would be found by extrapolation from those (far) to the left of it. I am inclined to think that the best course of action is to quit with a warning when the MAD of the residuals is effectively zero. However, we need to be careful not to call things 'bugs' that we do not understand well enough. This might be a design error in lowess, but it is not AFAICS a bug in the implementation. -- 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-help@stat.math.ethz.ch 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.
Re: [R] bug: Editing function formals deletes the environment
If you are just modifying an S3 method in a package you may not need to reinsert
the method into the package since UseMethod first looks into the
caller environment
for methods anyways and only second does it look for methods in the
package. Thus:
HTML.data.frame - R2HTML:::HTML.data.frame
HTML.data.frame$Border - 2
HTML(BOD, file = file(clipboard, w), append = FALSE)
would be sufficient if you intend to call HTML.
There is one significant caveat. If you intend to call a function in
R2HTML which in
turn calls HTML then the above would not be enough. You would also
have to modify
the environment of the caller too.
Thus after running the above:
HTML2clip(BOD)
would still get the old Border since we are calling HTML2clip which in
turn calls
HTML (as opposed to calling HTML directly). In this case, we would
need to create
a new HTML2clip with a reset environment too:
HTML2clip - R2HTML:::HTML2clip
environment(HTML2clip) - environment()
HTML2clip(BOD)
would get the Border=2 value.
On 10/13/06, Alex Brown [EMAIL PROTECTED] wrote:
First, here's the specific bug I have. Later I'll say why I care.
ls(zappo)
Error in try(name) : object zappo not found
# good.
f = function(zappo) { function(y) zappo + y }
g = f(1)
g(1)
[1] 2
formals(g)
$y
formals(g)$y
formals(g)$y = 2
g
function (y = 2)
zappo + y
g(1)
Error in g(1) : object zappo not found
# looks like formals strips the environment off stuff.
anything I can do about this?
-Alex
Original question:
I'm trying to change the behaviour of a package, to simplify the
interface.
I'd rather not change the package, although I could.
There's a hidden function whose defaults I wish to change.
I'm using R 2.3.1 for macosX. Upgrading is not an option.
This is what I do:
library(R2HTML)
# get the function to modify
x = getFromNamespace(HTML.data.frame, R2HTML)
# change the default for an argument
formals(x)[Border]=list(NULL)
# put the function back
assignInNamespace(HTML.data.frame, x, R2HTML)
#test the function:
HTML(data.frame(1:2), file=stdout())
Error: could not find function HTMLReplaceNA
# what seems to be happening is that the formals function is
stripping the namespace off the variable x. I can't tell why.
__
R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in lowess
Prof Brian Ripley wrote: Frank Harrell wrote: [...] Thank you Brian. It seems that no matter what is the right answer, the answer currently returned on my system is clearly wrong. lowess()$y should be constrained to be within range(y). Really? That assertion is offered without proof and I am pretty sure is incorrect. Consider x - c(1:10, 20) y - c(1:10, 5) + 0.01*rnorm(11) lowess(x,y) $x [1] 1 2 3 4 5 6 7 8 9 10 20 $y [1] 0.9983192 1.9969599 2.9960805 3.9948224 4.9944158 5.9959855 [7] 6.9964400 7.9981434 8.9990607 10.0002567 19.9946117 Remember that lowess is a local *linear* fitting method, and may give zero weight to some data points, so (as here) it can extrapolate. Brian - thanks - that's a good example though not typical of the kind I see from patients. After reading what src/appl/lowess.doc says should happen with zero weights, I think the answer given on Frank's system probably is the correct one. Rounding error is determining which of the last two points is given zero robustness weight: on a i686 system both of the last two are, and on mine only the last is. As far as I can tell in infinite-precision arithmetic both would be zero, and hence the value at x=120 would be found by extrapolation from those (far) to the left of it. I am inclined to think that the best course of action is to quit with a warning when the MAD of the residuals is effectively zero. However, we need to be careful not to call things 'bugs' that we do not understand well enough. This might be a design error in lowess, but it is not AFAICS a bug in the implementation. Yes it appears to be a weakness in the underlying algorithm. Thanks Frank __ R-help@stat.math.ethz.ch 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.
Re: [R] Bug in lowess
Folks: This interesting dicussion brings up an issue of what I have referred to for some time as safe statistics, by which I mean: Usually, but not necessarily automated)Statistical procedures that are guranteed to give either (a) a reasonable answer; or (b) Do not give an answer and when possible emit useful error messages. All standard least squares procedures taught in basic statistics courses are examples (from many different perspectives) of unsafe statistics. Robustness/resistance clearly takes us some way along this path, but as is clear from the discussion, not the whole way. The reason I think that this is important is a) Based on my own profound ignorance/limitations, I think it's impossible to expect those who need to use many different kinds of sophisticated statistical analyses to understand enough of the technical details to be able to actively and effectively guide their appropriate when this requires such guidance (e.g., least aquares with extensive diagnostics; overfitting in nonlinear regression); b) The explosion of large complex data in all disciplines that **require** some sort of automated analyses to be used (e.g. microarray data?). Having said this, it is unclear to me even **if** safe statistics is a meaningful concept: can it ever be -- at all? But I believe one thing is clear: A lot of people devote a lot of labor to optimal procedures that are far too sensitive to the manifold peculiarities of real data to give reliable, trustworthy results in practice considerable expert coaxing. We at least need a greater variety of less optimal but safer data analysis procedures. R -- or rather it's many contributors-- seems to me to be the exception in recognizing and doing something about this. And as a humble example of what I mean: I like simple running medians of generally small span for smoothing sequential data (please don't waste time giving me counterexamples of why this is bad or how it can go wrong -- I know there are many). I would appreciate anyone else's thoughts on this, pro or con, perhaps privately rather than on the list if you view this as too far off-topic. (NOTE: TO be clear: My personal views, not those of my company or colleagues) My best regards to all, Bert Bert Gunter Genentech Nonclinical Statistics South San Francisco, CA 94404 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank E Harrell Jr Sent: Friday, October 13, 2006 5:51 AM To: Prof Brian Ripley Cc: [EMAIL PROTECTED] Subject: Re: [R] Bug in lowess Prof Brian Ripley wrote: Frank Harrell wrote: [...] Thank you Brian. It seems that no matter what is the right answer, the answer currently returned on my system is clearly wrong. lowess()$y should be constrained to be within range(y). Really? That assertion is offered without proof and I am pretty sure is incorrect. Consider x - c(1:10, 20) y - c(1:10, 5) + 0.01*rnorm(11) lowess(x,y) $x [1] 1 2 3 4 5 6 7 8 9 10 20 $y [1] 0.9983192 1.9969599 2.9960805 3.9948224 4.9944158 5.9959855 [7] 6.9964400 7.9981434 8.9990607 10.0002567 19.9946117 Remember that lowess is a local *linear* fitting method, and may give zero weight to some data points, so (as here) it can extrapolate. Brian - thanks - that's a good example though not typical of the kind I see from patients. After reading what src/appl/lowess.doc says should happen with zero weights, I think the answer given on Frank's system probably is the correct one. Rounding error is determining which of the last two points is given zero robustness weight: on a i686 system both of the last two are, and on mine only the last is. As far as I can tell in infinite-precision arithmetic both would be zero, and hence the value at x=120 would be found by extrapolation from those (far) to the left of it. I am inclined to think that the best course of action is to quit with a warning when the MAD of the residuals is effectively zero. However, we need to be careful not to call things 'bugs' that we do not understand well enough. This might be a design error in lowess, but it is not AFAICS a bug in the implementation. Yes it appears to be a weakness in the underlying algorithm. Thanks Frank __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in lowess
On Wed, 2006-10-11 at 22:29 -0500, Frank E Harrell Jr wrote: x - c(0,7,8,14,15,120,242) y - c(122,128,130,158,110,110,92) lowess(x,y) $x [1] 0 7 8 14 15 120 242 $y [1] 122. 128. 132.2857 158. 110. -4930. 110. Same behaviour here on a more recent R (below), and I recall a posting for a year or so back that reported similar behaviour in the then current version of R. G x - c(0,7,8,14,15,120,242) y - c(122,128,130,158,110,110,92) lowess(x,y) $x [1] 0 7 8 14 15 120 242 $y [1] 122. 128. 132.2857 158. 110. -4930. 110. sessionInfo() R version 2.4.0 Patched (2006-10-03 r39576) i686-pc-linux-gnu locale: LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] methods stats graphics grDevices utils datasets [7] base R version 2.2.1, 2005-12-20, i486-pc-linux-gnu attached base packages: [1] methods stats graphics grDevices utils datasets [7] base other attached packages: lattice Hmisc chron 0.12-11 3.1-1 2.3-8 -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Gavin Simpson [t] +44 (0)20 7679 0522 ECRC ENSIS, UCL Geography, [f] +44 (0)20 7679 0565 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/ UK. WC1E 6BT. [w] http://www.freshwaters.org.uk %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-help@stat.math.ethz.ch 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.
Re: [R] Bug in stepAIC?
You sent this earlier to R-devel. Please do see the posting guide! Since you (incorrectly) thought this was a bug in MASS, you should have contacted the maintainer. On Wed, 11 Oct 2006, Martin C. Martin wrote: Hi, First of all, thanks for the great work on R in general, and MASS in particular. It's been a life saver for me many times. However, I think I've discovered a bug. It seems that, when I use weights during an initial least-squares regression fit, and later try to add terms using stepAIC(), it uses the weights when looking to remove terms, but not when looking to add them: hills.lm - lm(time ~ dist + climb, data = hills, weights = 1/dist2) Presumably dist^2? small.hills.lm - stepAIC(hills.lm) stepAIC(small.hills.lm, time ~ dist + climb) In the first stepAIC(), it says that the AIC for the full time ~ dist + climb is 94.41. Yet, during the second stepAIC, it says adding climb would produce an AIC of 212.1 (and an RSS of 12633.3). Is this a bug? Yes, but not in stepAIC. Consider drop1(hills.lm) Single term deletions Model: time ~ dist + climb Df Sum of SqRSSAIC none 437.64 94.41 dist1164.05 601.68 103.55 climb 1 8.66 446.29 93.10 add1(small.hills.lm, time ~ dist + climb) Single term additions Model: time ~ dist Df Sum of Sq RSS AIC none 15787.2 217.9 climb 13153.8 12633.3 212.1 stats:::add1.default(small.hills.lm, time ~ dist + climb) Single term additions Model: time ~ dist DfAIC none93.097 climb 1 94.411 so the bug is in add1.lm, part of R itself. Other code has been altered which then broke add1.lm and 'z' needs to be given class lm. Now fixed in r-devel and r-patched. -- 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in lowess
Prof Brian Ripley wrote: On Thu, 12 Oct 2006, Gavin Simpson wrote: On Wed, 2006-10-11 at 22:29 -0500, Frank E Harrell Jr wrote: x - c(0,7,8,14,15,120,242) y - c(122,128,130,158,110,110,92) lowess(x,y) $x [1] 0 7 8 14 15 120 242 $y [1] 122. 128. 132.2857 158. 110. -4930. 110. Same behaviour here on a more recent R (below), and I recall a posting for a year or so back that reported similar behaviour in the then current version of R. Actually, it is system-dependent as I get (on x86_64) lowess(x,y, iter=3) lowess(): ns = 4 cmad = 0.25589 cmad =0 cmad = 0.00583385 $x [1] 0 7 8 14 15 120 242 $y [1] 128. 128. 132.2857 158. 110. 109.9990 110. having turned DEBUG_lowess on. So the issue is finite-precision arithmetic, once again. It seems rather a moot point as to what the right answer actually is here, and even if that found by Frank is indeed wrong, as lowess() is defined by an algorithm. Perhaps the best one can hope for is a good approximation to what the algorithm would give in infinite-precision arithmetic (having defined what should happen if cmod is zero). Thank you Brian. It seems that no matter what is the right answer, the answer currently returned on my system is clearly wrong. lowess()$y should be constrained to be within range(y). lowess(x,y,iter=0) provides a reasonable solution in this case; I just don't know how to automatically force iter=0. Frank -- Frank E Harrell Jr Professor and Chair School of Medicine Department of Biostatistics Vanderbilt University __ R-help@stat.math.ethz.ch 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.
Re: [R] Bug in stepAIC?
Prof Brian Ripley wrote: You sent this earlier to R-devel. Please do see the posting guide! Since you (incorrectly) thought this was a bug in MASS, you should have contacted the maintainer. Thanks, but I did try emailing both you and Prof. Venables directly a month ago. After not receiving a response, I emailed R-devel last week. After not receiving a response there, I thought perhaps the code was correct after all, and I misunderstood how to call it - a perfect question for R-help. There can be a fine line between R-help and R-devel, which is even harder to find when you're new to R and you don't really know where the problem is. On Wed, 11 Oct 2006, Martin C. Martin wrote: Hi, First of all, thanks for the great work on R in general, and MASS in particular. It's been a life saver for me many times. However, I think I've discovered a bug. It seems that, when I use weights during an initial least-squares regression fit, and later try to add terms using stepAIC(), it uses the weights when looking to remove terms, but not when looking to add them: hills.lm - lm(time ~ dist + climb, data = hills, weights = 1/dist2) Presumably dist^2? Yes, sorry, a problem with Thunderbird being a little too smart for it's own good. :) small.hills.lm - stepAIC(hills.lm) stepAIC(small.hills.lm, time ~ dist + climb) In the first stepAIC(), it says that the AIC for the full time ~ dist + climb is 94.41. Yet, during the second stepAIC, it says adding climb would produce an AIC of 212.1 (and an RSS of 12633.3). Is this a bug? Yes, but not in stepAIC. Consider drop1(hills.lm) Single term deletions Model: time ~ dist + climb Df Sum of SqRSSAIC none 437.64 94.41 dist1164.05 601.68 103.55 climb 1 8.66 446.29 93.10 add1(small.hills.lm, time ~ dist + climb) Single term additions Model: time ~ dist Df Sum of Sq RSS AIC none 15787.2 217.9 climb 13153.8 12633.3 212.1 stats:::add1.default(small.hills.lm, time ~ dist + climb) Single term additions Model: time ~ dist DfAIC none93.097 climb 1 94.411 so the bug is in add1.lm, part of R itself. Other code has been altered which then broke add1.lm and 'z' needs to be given class lm. Now fixed in r-devel and r-patched. Great; thanks! Best, Martin __ R-help@stat.math.ethz.ch 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] Bug in stepAIC?
Hi, First of all, thanks for the great work on R in general, and MASS in particular. It's been a life saver for me many times. However, I think I've discovered a bug. It seems that, when I use weights during an initial least-squares regression fit, and later try to add terms using stepAIC(), it uses the weights when looking to remove terms, but not when looking to add them: hills.lm - lm(time ~ dist + climb, data = hills, weights = 1/dist2) small.hills.lm - stepAIC(hills.lm) stepAIC(small.hills.lm, time ~ dist + climb) In the first stepAIC(), it says that the AIC for the full time ~ dist + climb is 94.41. Yet, during the second stepAIC, it says adding climb would produce an AIC of 212.1 (and an RSS of 12633.3). Is this a bug? Best, Martin __ R-help@stat.math.ethz.ch 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] Bug in lowess
x - c(0,7,8,14,15,120,242) y - c(122,128,130,158,110,110,92) lowess(x,y) $x [1] 0 7 8 14 15 120 242 $y [1] 122. 128. 132.2857 158. 110. -4930. 110. R version 2.2.1, 2005-12-20, i486-pc-linux-gnu attached base packages: [1] methods stats graphics grDevices utils datasets [7] base other attached packages: lattice Hmisc chron 0.12-11 3.1-1 2.3-8 -- Frank E Harrell Jr Professor and Chair School of Medicine Department of Biostatistics Vanderbilt University __ R-help@stat.math.ethz.ch 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] Bug in 2.4.0 Windows menu setup
I've tracked down where this is occurring, but I don't know how to fix it. Here's a summary: If the language in Windows is set to simplified Chinese (i.e. Chinese (PRC)) and message translations are installed, then on startup Rgui crashes when it tries to install the console popup menu. The crash comes when it gets an error trying to do a conversion using mbrtowc, and tries to report it using error(); but the R symbol table is needed for that, and it hasn't been set up yet. I'm not sure which menu entry causes the crash, but I think it's not the first, so conceivably this is caused by an error in one of the translation files. Indeed, setting the language to Chinese (Taiwan) works. I don't know how to debug the translation files, so I'm going to have to leave this one for now. I think Brian Ripley is the only one who understands all the details of what goes on in the translations, and he's away until Oct 9. Duncan Murdoch On 10/3/2006 9:00 PM, ronggui wrote: This morning I downloaded R-2.4.0 and install in under Windows. I customized the installation and choose Message translations,but I could not launch Rgui.exe successfully( Rterm.exe worked fine). If I did't choose Message translations, Rgui.exe worked fine. Message translations is Simplified Chinese. version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 4.0 year 2006 month 10 day03 svn rev39566 language R version.string R version 2.4.0 (2006-10-03) __ R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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.
Re: [R] Bug in formals-
Frank E Harrell Jr [EMAIL PROTECTED] writes:
Deepayan Sarkar wrote:
On 9/26/06, Frank E Harrell Jr [EMAIL PROTECTED] wrote:
I think this is new since a previous version of R:
h - function(x, trantab) trantab[x]
w - 6:4
names(w) - c('cat','dog','giraffe')
w
cat dog giraffe
6 5 4
formals(h) - list(x=numeric(0), trantab=w)
h
function (x = numeric(0), trantab = c(6, 5, 4))
trantab[x]
You can see that the names have been dropped from trantab's default
values.
Are you sure? I get
formals(h)
$x
numeric(0)
$trantab
cat dog giraffe
6 5 4
h(1)
cat
6
R version 2.4.0 beta (2006-09-21 r39463)
x86_64-unknown-linux-gnu
-Deepayan
Deepayan -
You are correct. h('cat') is 6 as intended. I just looked at the
function definition - the names attribute doesn't show for some reason.
I was expecting function(..., trantab=c(cat=6, ..).
It's a generic deparsing issue. Also:
substitute(f(w),list(w=w))
f(c(6, 5, 4))
We should probably fix it at some point. Notice though that you can't
parse your way into such situations, only get there by computing on
the language.
--
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-help@stat.math.ethz.ch 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] Bug in formals-
I think this is new since a previous version of R:
h - function(x, trantab) trantab[x]
w - 6:4
names(w) - c('cat','dog','giraffe')
w
cat dog giraffe
6 5 4
formals(h) - list(x=numeric(0), trantab=w)
h
function (x = numeric(0), trantab = c(6, 5, 4))
trantab[x]
You can see that the names have been dropped from trantab's default
values. I don't see a workaround but it seems to need fixing.
Version 2.3.1 (2006-06-01)
i486-pc-linux-gnu
attached base packages:
[1] grid methods stats graphics grDevices utils
[7] datasets base
other attached packages:
lattice acepack Hmisc
0.13-10 1.3-2.2 3.0-12
--
Frank E Harrell Jr Professor and Chair School of Medicine
Department of Biostatistics Vanderbilt University
__
R-help@stat.math.ethz.ch 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.
Re: [R] Bug in formals-
On 9/26/06, Frank E Harrell Jr [EMAIL PROTECTED] wrote:
I think this is new since a previous version of R:
h - function(x, trantab) trantab[x]
w - 6:4
names(w) - c('cat','dog','giraffe')
w
cat dog giraffe
6 5 4
formals(h) - list(x=numeric(0), trantab=w)
h
function (x = numeric(0), trantab = c(6, 5, 4))
trantab[x]
You can see that the names have been dropped from trantab's default
values.
Are you sure? I get
formals(h)
$x
numeric(0)
$trantab
cat dog giraffe
6 5 4
h(1)
cat
6
R version 2.4.0 beta (2006-09-21 r39463)
x86_64-unknown-linux-gnu
-Deepayan
Version 2.3.1 (2006-06-01)
i486-pc-linux-gnu
attached base packages:
[1] grid methods stats graphics grDevices utils
[7] datasets base
other attached packages:
lattice acepack Hmisc
0.13-10 1.3-2.2 3.0-12
--
Frank E Harrell Jr Professor and Chair School of Medicine
Department of Biostatistics Vanderbilt University
__
R-help@stat.math.ethz.ch 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.
Re: [R] Bug in formals-
This seems to be related to using c to define transtab.
If we use list in place of c then it displays ok:
h - function(x, trantab) transtab[x]
formals(h) - list(x = numeric(0), transtab = c(cat = 6, dog = 5))
print(h) # bad display
function (x = numeric(0), transtab = c(6, 5))
transtab[x]
h(cat) # runs ok
cat
6
formals(h) - list(x = numeric(0), transtab = list(cat = 6, dog = 5))
print(h) # now display is ok
function (x = numeric(0), transtab = list(cat = 6, dog = 5))
transtab[x]
h(cat) # runs ok
$cat
[1] 6
On 9/26/06, Frank E Harrell Jr [EMAIL PROTECTED] wrote:
Deepayan Sarkar wrote:
On 9/26/06, Frank E Harrell Jr [EMAIL PROTECTED] wrote:
I think this is new since a previous version of R:
h - function(x, trantab) trantab[x]
w - 6:4
names(w) - c('cat','dog','giraffe')
w
cat dog giraffe
6 5 4
formals(h) - list(x=numeric(0), trantab=w)
h
function (x = numeric(0), trantab = c(6, 5, 4))
trantab[x]
You can see that the names have been dropped from trantab's default
values.
Are you sure? I get
formals(h)
$x
numeric(0)
$trantab
cat dog giraffe
6 5 4
h(1)
cat
6
R version 2.4.0 beta (2006-09-21 r39463)
x86_64-unknown-linux-gnu
-Deepayan
Deepayan -
You are correct. h('cat') is 6 as intended. I just looked at the
function definition - the names attribute doesn't show for some reason.
I was expecting function(..., trantab=c(cat=6, ..).
Thanks
Frank
Version 2.3.1 (2006-06-01)
i486-pc-linux-gnu
attached base packages:
[1] grid methods stats graphics grDevices utils
[7] datasets base
other attached packages:
lattice acepack Hmisc
0.13-10 1.3-2.2 3.0-12
__
R-help@stat.math.ethz.ch 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-help@stat.math.ethz.ch 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] Bug/problem reporting: Possible to modify posting guide FAQ?
If users post a bug or problem issue to an R-based news group (R-devel, R-help, BioC - though BioC is far more forgiving) they get yelled at for not reading the posting guide and FAQ. Please *_do_* read the FAQ, the posting guide, ... the yellers do say. So I read the BioC FAQ and it says... http://www.bioconductor.org/docs/faq/ Bug reports on packages should perhaps be sent to the package maintainer rather than to r-bugs. So I send email to a maintainer, who I believe rightly points out best to send this kind of questions to the bioc mailing list, rather than to myself privately, because other people might (a) also have answers or (b) benefit from the questions answers. Could the FAQ possibly be revised to some sensible combination that generates less finger pointing, such as Bug reports on packages should be sent to the Bioconductor mailing list, and sent or copied to the package maintainer, rather than to r-bugs. or Bug reports on packages should be sent to the package maintainer, and copied to the Bioconductor mailing list, rather than to r-bugs. Could the posting guides to R-help and R-devel do something similar? Sign me Tired of all the finger pointing http://www.r-project.org/posting-guide.html If the question relates to a contributed package , e.g., one downloaded from CRAN, try contacting the package maintainer first. You can also use find(functionname) and packageDescription(packagename) to find this information. Only send such questions to R-help or R-devel if you get no reply or need further assistance. This applies to both requests for help and to bug reports. How about If the question relates to a contributed package , e.g., one downloaded from CRAN, email the list and be sure to additionally send to or copy to the package maintainer as well. You can use find(functionname) and packageDescription(packagename) to find this information. Only send such questions to one of R-help or R-devel. This applies to both requests for help and to bug reports. __ R-help@stat.math.ethz.ch 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.
Re: [R] Bug/problem reporting: Possible to modify posting guide FAQ?
Hi, I guess the question often comes down to whether it is a bug report, or a question. If you know it is a bug, and have a complete and correct example where the obviously incorrect behavior occurs and you are positive that the problem is the package then sending it to the maintainer is appropriate. When I get these I try to deal with them. Real bug reports that go to the mailing list may be missed so in my opinion it would be best to cc the maintainer and we will amend the FAQ in that direction. If instead you are asking a question, of the form, is this a bug, or why is this happening, then for BioC at least, it is better to post directly to the list, as there are many folks who can help and you are more likely to get an answer. When I get one of these emails I always refer the person to the mailing lists. I see little problem with being redirected by a maintainer to the mailing list if they feel that the question is better asked there. Bioconductor is different from R, clearly our mailing list has to be more about the constituent packages, since we will direct questions about R to the appropriate R mailing lists. R mailing lists tend to be about R, so asking about a specific package there (among the 1000 or so) often does not get you very far, but sometimes it does. best wishes Robert Steven McKinney wrote: If users post a bug or problem issue to an R-based news group (R-devel, R-help, BioC - though BioC is far more forgiving) they get yelled at for not reading the posting guide and FAQ. Please *_do_* read the FAQ, the posting guide, ... the yellers do say. So I read the BioC FAQ and it says... http://www.bioconductor.org/docs/faq/ Bug reports on packages should perhaps be sent to the package maintainer rather than to r-bugs. So I send email to a maintainer, who I believe rightly points out best to send this kind of questions to the bioc mailing list, rather than to myself privately, because other people might (a) also have answers or (b) benefit from the questions answers. Could the FAQ possibly be revised to some sensible combination that generates less finger pointing, such as Bug reports on packages should be sent to the Bioconductor mailing list, and sent or copied to the package maintainer, rather than to r-bugs. or Bug reports on packages should be sent to the package maintainer, and copied to the Bioconductor mailing list, rather than to r-bugs. Could the posting guides to R-help and R-devel do something similar? Sign me Tired of all the finger pointing http://www.r-project.org/posting-guide.html If the question relates to a contributed package , e.g., one downloaded from CRAN, try contacting the package maintainer first. You can also use find(functionname) and packageDescription(packagename) to find this information. Only send such questions to R-help or R-devel if you get no reply or need further assistance. This applies to both requests for help and to bug reports. How about If the question relates to a contributed package , e.g., one downloaded from CRAN, email the list and be sure to additionally send to or copy to the package maintainer as well. You can use find(functionname) and packageDescription(packagename) to find this information. Only send such questions to one of R-help or R-devel. This applies to both requests for help and to bug reports. __ R-help@stat.math.ethz.ch 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. -- 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-help@stat.math.ethz.ch 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.
Re: [R] bug in interaction order when using drop?
On Thu, 10 Aug 2006, Petr Pikal wrote:
Ooops, my first suggestion reorders factor itself but
if (drop) factor(ans) else ans
instead of whole drop construction shall preserve levels order
without changing order of factor
Even easier would be to return ans[,drop=drop]. It seems to me that there
is an argument for expecting interaction(..., drop=TRUE) to give the same
result as interaction(...)[,drop=TRUE], but little argument that any
ordering is a *bug*.
The order of the levels of a factor are arbitrary, and in fact they seem
to me to be in a strange order, with the levels of the first factor
varying fastest (reverse lexiographic order).
levels(interaction(c(A, A, B), letters[1:3]))
[1] A.a B.a A.b B.b A.c B.c
so the existing
levels(interaction(c(A, A, B), letters[1:3], drop=T))
[1] A.a A.b B.c
looks more sensible in this case.
Petr
On 10 Aug 2006 at 16:32, Petr Pikal wrote:
From: Petr Pikal [EMAIL PROTECTED]
To: r-help@stat.math.ethz.ch
Date sent:Thu, 10 Aug 2006 16:32:54 +0200
Priority: normal
Subject: [R] bug in interaction order when using drop?
Hallo all
version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status beta
major 2
minor 3.1
year 2006
month 05
day23
svn rev38179
language R
version.string Version 2.3.1 beta (2006-05-23 r38179)
When I use interaction() without drop=T parameters I will get
neatly organized factor with protiproud and souproud aligned.
levels(interaction(vykon, teplota, proudeni))
[1] 3.750.protiproud 12.750.protiproud 3.775.protiproud
12.775.protiproud 3.800.protiproud 12.800.protiproud
[7] 3.825.protiproud 12.825.protiproud 3.850.protiproud
12.850.protiproud 3.750.souproud12.750.souproud [13]
3.775.souproud12.775.souproud 3.800.souproud
12.800.souproud 3.825.souproud12.825.souproud [19]
3.850.souproud12.850.souproud
However when I use
levels(interaction(vykon, teplota, proudeni, drop=T))
[1] 3.775.protiproud 3.800.souproud3.750.souproud
12.850.souproud 12.825.protiproud
everything is out of order. I know I can reorder any factor according
to my wish but it would be good to have it ordered same way as without
using drop.
Everything comes from unique in
if (drop) {
f - unique(ans[!is.na(ans)])
ans - match(ans, f)
lvs - lvs[f]
}
maybe it can be modified.
if (drop) {
f - unique(ans[!is.na(ans)])
ord - order(f)
ans - match(ans, f)
lvs - lvs[f[ord]]
}
which seems to work but I am not sure if it does not makes problems
having NA in data.
Here is my data frame.
Thank you
Petr Pikal
dump(df, file=stdout())
df -
structure(list(proudeni = structure(as.integer(c(1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1,
1, 1, 1)), .Label = c(protiproud, souproud), class = factor),
vykon = as.integer(c(3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12,
12, 12, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 12, 12, 12,
12, 12, 12, 12, 12, 12, 12, 12, 12, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 12, 12, 12, 12, 12, 12,
12, 12, 12, 12, 12, 12)), teplota = as.integer(c(775, 775,
775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775
Re: [R] bug in interaction order when using drop?
On 11 Aug 2006 at 12:31, Prof Brian Ripley wrote: Date sent: Fri, 11 Aug 2006 12:31:55 +0100 (BST) From: Prof Brian Ripley [EMAIL PROTECTED] To: Petr Pikal [EMAIL PROTECTED] Copies to: r-help@stat.math.ethz.ch Subject:Re: [R] bug in interaction order when using drop? On Thu, 10 Aug 2006, Petr Pikal wrote: Ooops, my first suggestion reorders factor itself but if (drop) factor(ans) else ans instead of whole drop construction shall preserve levels order without changing order of factor Even easier would be to return ans[,drop=drop]. It seems to me that there is an argument for expecting interaction(..., drop=TRUE) to give the same result as interaction(...)[,drop=TRUE], but little argument that any ordering is a *bug*. Maybe bug was an *exaggeration*, but what surprised me was different order in using interaction with and without drop. Well, I would call it not consistent behaviour as omitting unused levels silently change an order of factor levels. set.seed(1) DF-data.frame(x=sample(LETTERS[1:3],10, replace=T), y=sample(letters[1:3],10, replace=T)) interaction(DF$x,DF$y) [1] A.a B.a B.c C.b A.c C.b C.c B.c B.b A.c Levels: A.a B.a C.a A.b B.b C.b A.c B.c C.c Here is neat ordering, however as you said first level varying fastest. interaction(DF$x,DF$y, drop=T) [1] A.a B.a B.c C.b A.c C.b C.c B.c B.b A.c Levels: A.a B.a B.c C.b A.c C.c B.b This seems to me chaotic, but I will be glad if you explain to me some rational pattern in it. my.int(DF$x,DF$y,drop=T) # changed as suggested [1] A.a B.a B.c C.b A.c C.b C.c B.c B.b A.c Levels: A.a B.a B.b C.b A.c B.c C.c Same ordering as without drop, with unused levels omitted. Best regards. Petr Pikal The order of the levels of a factor are arbitrary, and in fact they seem to me to be in a strange order, with the levels of the first factor varying fastest (reverse lexiographic order). levels(interaction(c(A, A, B), letters[1:3])) [1] A.a B.a A.b B.b A.c B.c so the existing levels(interaction(c(A, A, B), letters[1:3], drop=T)) [1] A.a A.b B.c looks more sensible in this case. Petr On 10 Aug 2006 at 16:32, Petr Pikal wrote: From: Petr Pikal [EMAIL PROTECTED] To: r-help@stat.math.ethz.ch Date sent: Thu, 10 Aug 2006 16:32:54 +0200 Priority: normal Subject:[R] bug in interaction order when using drop? snip __ R-help@stat.math.ethz.ch 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, [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 Petr Pikal [EMAIL PROTECTED] __ R-help@stat.math.ethz.ch 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] bug in interaction order when using drop?
Hallo all
version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status beta
major 2
minor 3.1
year 2006
month 05
day23
svn rev38179
language R
version.string Version 2.3.1 beta (2006-05-23 r38179)
When I use interaction() without drop=T parameters I will get
neatly organized factor with protiproud and souproud aligned.
levels(interaction(vykon, teplota, proudeni))
[1] 3.750.protiproud 12.750.protiproud 3.775.protiproud
12.775.protiproud 3.800.protiproud 12.800.protiproud
[7] 3.825.protiproud 12.825.protiproud 3.850.protiproud
12.850.protiproud 3.750.souproud12.750.souproud
[13] 3.775.souproud12.775.souproud 3.800.souproud
12.800.souproud 3.825.souproud12.825.souproud
[19] 3.850.souproud12.850.souproud
However when I use
levels(interaction(vykon, teplota, proudeni, drop=T))
[1] 3.775.protiproud 3.800.souproud3.750.souproud
12.850.souproud 12.825.protiproud
everything is out of order. I know I can reorder any factor according
to my wish but it would be good to have it ordered same way as
without using drop.
Everything comes from unique in
if (drop) {
f - unique(ans[!is.na(ans)])
ans - match(ans, f)
lvs - lvs[f]
}
maybe it can be modified.
if (drop) {
f - unique(ans[!is.na(ans)])
ord - order(f)
ans - match(ans, f)
lvs - lvs[f[ord]]
}
which seems to work but I am not sure if it does not makes problems
having NA in data.
Here is my data frame.
Thank you
Petr Pikal
dump(df, file=stdout())
df -
structure(list(proudeni = structure(as.integer(c(1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1,
1, 1, 1)), .Label = c(protiproud, souproud), class = factor),
vykon = as.integer(c(3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12,
12, 12, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 12, 12, 12,
12, 12, 12, 12, 12, 12, 12, 12, 12, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 12, 12, 12, 12, 12, 12,
12, 12, 12, 12, 12, 12)), teplota = as.integer(c(775, 775,
775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775,
775, 775, 775, 775, 800, 800, 800, 800, 800, 800, 800, 800,
800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 750, 850,
850, 850, 850, 850, 850, 825, 825, 825, 825, 825, 825, 775,
775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775,
775, 775, 775, 775, 775, 800, 800, 800, 800, 800, 800, 800,
800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 750,
850, 850, 850, 850, 850, 850, 825, 825, 825, 825, 825, 825,
775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775,
775, 775, 775, 775, 775, 775, 800, 800, 800, 800, 800, 800,
800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 800,
750, 850, 850, 850, 850, 850, 850, 825, 825, 825, 825, 825,
825, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775,
775, 775, 775, 775, 775, 775, 775, 800, 800, 800, 800, 800,
800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 800,
800, 750, 850, 850, 850, 850, 850, 850, 825, 825, 825, 825,
825, 825))), .Names = c(proudeni, vykon, teplota),
row.names = c(1,
2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35,
36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,
47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57,
58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68,
69, 70, 71, 72, 73, 74, 75, 76,
Re: [R] bug in interaction order when using drop?
Ooops, my first suggestion reorders factor itself but
if (drop) factor(ans) else ans
instead of whole drop construction shall preserve levels order
without changing order of factor
Petr
On 10 Aug 2006 at 16:32, Petr Pikal wrote:
From: Petr Pikal [EMAIL PROTECTED]
To: r-help@stat.math.ethz.ch
Date sent: Thu, 10 Aug 2006 16:32:54 +0200
Priority: normal
Subject:[R] bug in interaction order when using drop?
Hallo all
version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status beta
major 2
minor 3.1
year 2006
month 05
day23
svn rev38179
language R
version.string Version 2.3.1 beta (2006-05-23 r38179)
When I use interaction() without drop=T parameters I will get
neatly organized factor with protiproud and souproud aligned.
levels(interaction(vykon, teplota, proudeni))
[1] 3.750.protiproud 12.750.protiproud 3.775.protiproud
12.775.protiproud 3.800.protiproud 12.800.protiproud
[7] 3.825.protiproud 12.825.protiproud 3.850.protiproud
12.850.protiproud 3.750.souproud12.750.souproud [13]
3.775.souproud12.775.souproud 3.800.souproud
12.800.souproud 3.825.souproud12.825.souproud [19]
3.850.souproud12.850.souproud
However when I use
levels(interaction(vykon, teplota, proudeni, drop=T))
[1] 3.775.protiproud 3.800.souproud3.750.souproud
12.850.souproud 12.825.protiproud
everything is out of order. I know I can reorder any factor according
to my wish but it would be good to have it ordered same way as without
using drop.
Everything comes from unique in
if (drop) {
f - unique(ans[!is.na(ans)])
ans - match(ans, f)
lvs - lvs[f]
}
maybe it can be modified.
if (drop) {
f - unique(ans[!is.na(ans)])
ord - order(f)
ans - match(ans, f)
lvs - lvs[f[ord]]
}
which seems to work but I am not sure if it does not makes problems
having NA in data.
Here is my data frame.
Thank you
Petr Pikal
dump(df, file=stdout())
df -
structure(list(proudeni = structure(as.integer(c(1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1,
1, 1, 1)), .Label = c(protiproud, souproud), class = factor),
vykon = as.integer(c(3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12,
12, 12, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 12, 12, 12,
12, 12, 12, 12, 12, 12, 12, 12, 12, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 12, 12, 12, 12, 12, 12,
12, 12, 12, 12, 12, 12)), teplota = as.integer(c(775, 775,
775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775,
775, 775, 775, 775, 800, 800, 800, 800, 800, 800, 800, 800,
800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 750, 850,
850, 850, 850, 850, 850, 825, 825, 825, 825, 825, 825, 775,
775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775,
775, 775, 775, 775, 775, 800, 800, 800, 800, 800, 800, 800,
800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 750,
850, 850, 850, 850, 850, 850, 825, 825, 825, 825, 825, 825,
775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775, 775,
775, 775, 775, 775, 775, 775, 800, 800, 800, 800, 800, 800,
800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 800, 800,
750, 850, 850, 850, 850, 850, 850, 825, 825, 825, 825, 825,
825, 775, 775, 775, 775, 775, 775, 775, 775
[R] bug?
Dear All,
if you generate a sequence with small latitude like:
x-seq(0,1,0.005)
and you ask for all points of this lattice how many points are in a
neighbourhood with radius 0.01
of each point:
v - rep( 0 , length( x ) ) ;
for (i in 1:length(x) )
{ v[i] - length(x[ abs(x-x[i]) 0.01 ] ) ; };
then the answer should be: v = (2, 3, 3, 3, 3,...,3, 3, 3, 3, 2), because
every point instead
of the borders has 3 points in a 0.01-neighbourhood.
but v contains also many 4 and also 5:
v
[1] 2 4 3 4 4 3 4 4 3 4 4 3 4 4 4 4 5 4 4 5 4 4 5 4 4 4 3 4 4 4 4 3 3 3 4 4 4
[38] 4 3 3 4 4 4 4 3 3 4 4 4 4 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 3 4 4 4 4 3
[75] 3 3 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 3 3
[112] 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3
[149] 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
[186] 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 2
Could anyone explain this fact and help me to compute exactly on general data.
Thank you very much,
Patrick Jahn
__
R-help@stat.math.ethz.ch 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.
Re: [R] bug?
On Wed, 26 Jul 2006, Patrick Jahn wrote:
Dear All,
if you generate a sequence with small latitude like:
x-seq(0,1,0.005)
and you ask for all points of this lattice how many points are in a
neighbourhood with radius 0.01
of each point:
v - rep( 0 , length( x ) ) ;
for (i in 1:length(x) )
{ v[i] - length(x[ abs(x-x[i]) 0.01 ] ) ; };
then the answer should be: v = (2, 3, 3, 3, 3,...,3, 3, 3, 3, 2),
because every point instead
of the borders has 3 points in a 0.01-neighbourhood.
but v contains also many 4 and also 5:
v
[1] 2 4 3 4 4 3 4 4 3 4 4 3 4 4 4 4 5 4 4 5 4 4 5 4 4 4 3 4 4 4 4 3 3 3 4 4 4
[38] 4 3 3 4 4 4 4 3 3 4 4 4 4 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 3 4 4 4 4 3
[75] 3 3 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 3 3
[112] 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 3 3 3 3
3
[149] 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
3
[186] 3 3 3 3 3 4 4 4 4 3 3 3 3 3 3 2
Could anyone explain this fact and help me to compute exactly on general
data.
Yes and no.
The fact is easily explained: 0.005 and 0.01 are not exactly representable
in floating point, and so it will not be true for all x that x+0.005+0.005
= x+0.01. This is a FAQ.
For this problem an easy solution is to multiply by 200 (or 1000) and work
with integers, which can be exactly represented. There is no solution for
general data, although software for arbitrary precision floating point may
come close (there was a message yesterday from someone trying to interface
pari/gp, which does this, with R).
-thomas
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle
__
R-help@stat.math.ethz.ch 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.
Re: [R] Bug of pmvnorm?
On Sat, 27 May 2006, P Ehlers wrote: Looks like a bug (in mvt()?). Note that pmvnorm(lower = c(-Inf, -Inf), upper = c(Inf, 10)) works as expected, as does replacing any of the 4 Infs with a finite value. Function sadmvn() in pkg:mnormt does give 1 with Inf lower/uppers. yes, looks like a bug. Thanks for reporting, will fix it *asap* Best, Torsten Peter Ehlers Daniel Yang wrote: Dear R-help, Is the following a bug of pmvnorm? R-matrix(c(1,.5,.5,1),2,2) pmvnorm(lower=c(-Inf,-Inf),upper=c(Inf,Inf),corr=R) It returns, [1] 0 attr(,error) [1] 0 attr(,msg) [1] Normal Completion But I think it should return 1. Yung-jui __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] Bug of pmvnorm?
Dear R-help, Is the following a bug of pmvnorm? R-matrix(c(1,.5,.5,1),2,2) pmvnorm(lower=c(-Inf,-Inf),upper=c(Inf,Inf),corr=R) It returns, [1] 0 attr(,error) [1] 0 attr(,msg) [1] Normal Completion But I think it should return 1. Yung-jui __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug of pmvnorm?
Looks like a bug (in mvt()?). Note that pmvnorm(lower = c(-Inf, -Inf), upper = c(Inf, 10)) works as expected, as does replacing any of the 4 Infs with a finite value. Function sadmvn() in pkg:mnormt does give 1 with Inf lower/uppers. Peter Ehlers Daniel Yang wrote: Dear R-help, Is the following a bug of pmvnorm? R-matrix(c(1,.5,.5,1),2,2) pmvnorm(lower=c(-Inf,-Inf),upper=c(Inf,Inf),corr=R) It returns, [1] 0 attr(,error) [1] 0 attr(,msg) [1] Normal Completion But I think it should return 1. Yung-jui __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] bug in pictex() (package:grDevices)
running
pictex()
plot(1:11,(-5:5)^2, type='b', main=Simple_Example_Plot)
dev.off()
(as in the pictex example, but with underscores instead of spaces).
the TeX file contains
\put {Simple_Example_Plot} [lB] 0.00pt,0.00pt at 124.00 275.33
the underscores have a special meaning in TeX, so they should be quoted
or converted to dashes.
--
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 4 (Stentz)
http://www.iris.org.il http://www.openvotingconsortium.org
http://pmw.org.il http://www.palestinefacts.org http://www.memri.org
Just because you're paranoid doesn't mean they AREN'T after you.
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug in map('world') ?
From: Joerg van den Hoff [EMAIL PROTECTED]
hi,
did'nt see anything in the archive:
map('world',pro='rectangular',para=0)
yields a strange artifact (horizontal bar) extending over the whole map
at a certain latitude range (approx 65 deg. north), whereas
map('world',pro='rectangular',para=180)
(which should be the same) does not show the artifact.
the artifact shows up in other projections as well, e.g.
map('world',pro='bonne',para=45)
which seems to show that the problem might be in the data base of the
map (i.e. polygon definition)??
any ideas?
The short answer is RTFM, and now that I have again :-), I note that
there is a wrap= option. Setting that to TRUE seems to have the
desired effect.
Ray
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] bug in map('world') ?
hi,
did'nt see anything in the archive:
map('world',pro='rectangular',para=0)
yields a strange artifact (horizontal bar) extending over the whole map
at a certain latitude range (approx 65 deg. north), whereas
map('world',pro='rectangular',para=180)
(which should be the same) does not show the artifact.
the artifact shows up in other projections as well, e.g.
map('world',pro='bonne',para=45)
which seems to show that the problem might be in the data base of the
map (i.e. polygon definition)??
any ideas?
regards,
joerg
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug in map('world') ?
I seem to recall I came across something similar recently (well,
relatively recently, perhaps a couple of years ago). The problem is
related to how the code handles polygons that are split across the map
boundaries. As I recall, the fix was to modify the polygons that
straddle the date line. I'll have to delve into this again, but don't
hold your breath, sorry.
Ray Brownrigg
From: Joerg van den Hoff [EMAIL PROTECTED]
hi,
did'nt see anything in the archive:
map('world',pro='rectangular',para=0)
yields a strange artifact (horizontal bar) extending over the whole map
at a certain latitude range (approx 65 deg. north), whereas
map('world',pro='rectangular',para=180)
(which should be the same) does not show the artifact.
the artifact shows up in other projections as well, e.g.
map('world',pro='bonne',para=45)
which seems to show that the problem might be in the data base of the
map (i.e. polygon definition)??
any ideas?
regards,
joerg
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug in map('world') ?
There is a function recenter.Map in the TeachingDemos package that can
be used with the maptools packages (rather than the maps package) to
move polygons around for better looking maps. The original idea was to
put the Alaskan islands on the left of the map rather than having some
of them on the far right, but it also works to creat a pacific centric
map or other things. It is still pretty basic as a function, if anyone
wants to improve it (it could probably use a lot of improvement) they
are more than welcome.
Hope this helps,
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ray Brownrigg
Sent: Wednesday, March 08, 2006 12:40 PM
To: [EMAIL PROTECTED]; r-help@stat.math.ethz.ch
Subject: Re: [R] bug in map('world') ?
I seem to recall I came across something similar recently
(well, relatively recently, perhaps a couple of years ago).
The problem is related to how the code handles polygons that
are split across the map boundaries. As I recall, the fix
was to modify the polygons that straddle the date line. I'll
have to delve into this again, but don't hold your breath, sorry.
Ray Brownrigg
From: Joerg van den Hoff [EMAIL PROTECTED]
hi,
did'nt see anything in the archive:
map('world',pro='rectangular',para=0)
yields a strange artifact (horizontal bar) extending over the whole
map at a certain latitude range (approx 65 deg. north), whereas
map('world',pro='rectangular',para=180)
(which should be the same) does not show the artifact.
the artifact shows up in other projections as well, e.g.
map('world',pro='bonne',para=45)
which seems to show that the problem might be in the data
base of the
map (i.e. polygon definition)??
any ideas?
regards,
joerg
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] Bug in setting GUI to SDI mode?
Hi I did a google search on this and came up with nothing. OK, in the latest release of R for windows, I want to change the gui to SDI mode. Edit - GUI preferences Choose SDI Apply I get the message about properties not being able to be changed on a running console, and that I need to save. So I click Save, and am met with a Save As dialogue box with the default file called Rconsole, the file type as All files. I have no idea where I actually have to save this. I saved it in C:\Program File\R\2.2.1 anyway, restarted the console, and SDI mode was not set. I realiuse I can use the --sdi option on the command line, but I want to know how to make this work through the GUI Any help? Thanks Mick __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in setting GUI to SDI mode?
You should save it to C:\Program File\R\2.2.1\etc Best, Ales Ziberna michael watson (IAH-C) pravi: Hi I did a google search on this and came up with nothing. OK, in the latest release of R for windows, I want to change the gui to SDI mode. Edit - GUI preferences Choose SDI Apply I get the message about properties not being able to be changed on a running console, and that I need to save. So I click Save, and am met with a Save As dialogue box with the default file called Rconsole, the file type as All files. I have no idea where I actually have to save this. I saved it in C:\Program File\R\2.2.1 anyway, restarted the console, and SDI mode was not set. I realiuse I can use the --sdi option on the command line, but I want to know how to make this work through the GUI Any help? Thanks Mick __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in setting GUI to SDI mode?
On 2/23/2006 8:33 AM, michael watson (IAH-C) wrote: Hi I did a google search on this and came up with nothing. OK, in the latest release of R for windows, I want to change the gui to SDI mode. Edit - GUI preferences Choose SDI Apply I get the message about properties not being able to be changed on a running console, and that I need to save. So I click Save, and am met with a Save As dialogue box with the default file called Rconsole, the file type as All files. I have no idea where I actually have to save this. I saved it in C:\Program File\R\2.2.1 anyway, restarted the console, and SDI mode was not set. I realiuse I can use the --sdi option on the command line, but I want to know how to make this work through the GUI Any help? See the ?Rconsole man page. The search is somewhat complicated; it's up to you to decide whether you want the setting to apply just to your user (it should be in the R_USER directory), or be the default for all users (it should be in the R_HOME/etc directory). For me, the default location for saving is the R_USER directory; I suspect it's the same default for you, but I haven't actually checked the code. Duncan Murdoch __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in setting GUI to SDI mode?
michael watson (IAH-C) wrote: Hi I did a google search on this and came up with nothing. OK, in the latest release of R for windows, I want to change the gui to SDI mode. Edit - GUI preferences Choose SDI Apply I get the message about properties not being able to be changed on a running console, and that I need to save. So I click Save, and am met with a Save As dialogue box with the default file called Rconsole, the file type as All files. I have no idea where I actually have to save this. See ?Rconsole and the R for Windows FAQs Uwe Ligges I saved it in C:\Program File\R\2.2.1 anyway, restarted the console, and SDI mode was not set. I realiuse I can use the --sdi option on the command line, but I want to know how to make this work through the GUI Any help? Thanks Mick __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in setting GUI to SDI mode?
michael watson (IAH-C) wrote: Hi I did a google search on this and came up with nothing. OK, in the latest release of R for windows, I want to change the gui to SDI mode. Edit - GUI preferences Choose SDI Apply I get the message about properties not being able to be changed on a running console, and that I need to save. So I click Save, and am met with a Save As dialogue box with the default file called Rconsole, the file type as All files. I have no idea where I actually have to save this. I saved it in C:\Program File\R\2.2.1 anyway, restarted the console, and SDI mode was not set. I realiuse I can use the --sdi option on the command line, but I want to know how to make this work through the GUI Any help? Thanks Mick So, what's the bug? You need to save in $R_HOME\etc where $R_HOME is the directory where you have R installed. (Your example directory above seems odd - is it a typo?). BTW, this is in the rw-FAQ 5.2. Or you can read ?Rconsole. HTH, --sundar __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in setting GUI to SDI mode?
The file needs to be in R_HOME\etc. See ?Rconsole. Andy From: michael watson (IAH-C) Hi I did a google search on this and came up with nothing. OK, in the latest release of R for windows, I want to change the gui to SDI mode. Edit - GUI preferences Choose SDI Apply I get the message about properties not being able to be changed on a running console, and that I need to save. So I click Save, and am met with a Save As dialogue box with the default file called Rconsole, the file type as All files. I have no idea where I actually have to save this. I saved it in C:\Program File\R\2.2.1 anyway, restarted the console, and SDI mode was not set. I realiuse I can use the --sdi option on the command line, but I want to know how to make this work through the GUI Any help? Thanks Mick __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in setting GUI to SDI mode?
Woops!
RTFM for me :(
Thanks everyone for your help.
Mick
-Original Message-
From: Liaw, Andy [mailto:[EMAIL PROTECTED]
Sent: 23 February 2006 13:57
To: michael watson (IAH-C); r-help@stat.math.ethz.ch
Subject: RE: [R] Bug in setting GUI to SDI mode?
The file needs to be in R_HOME\etc. See ?Rconsole.
Andy
From: michael watson (IAH-C)
Hi
I did a google search on this and came up with nothing.
OK, in the latest release of R for windows, I want to change the gui
to SDI mode.
Edit - GUI preferences
Choose SDI
Apply
I get the message about properties not being able to be changed on a
running console, and that I need to save.
So I click Save, and am met with a Save As dialogue box with the
default file called Rconsole, the file type as All files. I have no
idea where I actually have to save this.
I saved it in C:\Program File\R\2.2.1 anyway, restarted the console,
and SDI mode was not set.
I realiuse I can use the --sdi option on the command line, but I want
to know how to make this work through the GUI
Any help?
Thanks
Mick
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html
--
Notice: This e-mail message, together with any attachments,...{{dropped}}
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] ?bug? strange factors produced by chron
Hallo all Please help me. I am lost and do not know what is the problem. I have a factor called kvartaly. attributes(kvartaly) $levels [1] 1Q.04 2Q.04 3Q.04 4Q.04 1Q.05 2Q.05 3Q.05 4Q.05 $class [1] factor mode(kvartaly) [1] numeric str(kvartaly) Factor w/ 8 levels 1Q.04,2Q.04,..: 1 1 1 1 1 1 1 1 1 1 ... but if I call split it throws an error split(rnorm(731),kvartaly) Error in split(x, f) : second argument must be a factor so I tried to make a test example which works if I try to construct factor manually but fails if I use chron vec-c(1Q.04, 1Q.05, 1Q.06) fac-as.factor(rep(vec,c(5,5,5))) split(rnorm(15),fac) $1Q.04 [1] 1.9803999 -0.3672215 -1.0441346 0.5697196 -0.1350546 $1Q.05 [1] 2.40161776 -0.03924000 0.68973936 0.02800216 -0.74327321 $1Q.06 [1] 0.1887923 -1.8049586 1.4655549 0.1532533 2.1726117 vec1-as.Date(Sys.time()) vec1-c(vec1, vec1-100, vec1-300) vec1-rep(vec1,c(5,5,5)) fac1-interaction(quarters(as.chron(as.POSIXct(vec1))), format(vec1,%y)) split(rnorm(15),fac1) Error in split(x, f) : second argument must be a factor Why split does not accept fac1 if according to all tests it **is** a factor? Thank you Petr Petr Pikal [EMAIL PROTECTED] __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] ?bug? strange factors produced by chron
1) The obvious test is via is.factor(), and you have not used that. 2) Your example works for me, so what versions of R and chron is this? 3) Here's my guess. split is using the C-level test isFactor. That tests that the factor is of type integer, so please try typeof(kvartaly) I suspect you will get double and not integer, and if so you can fix this by storage.mode(kvartaly) - integer So here's an example which will fail fac2 - rep(c(1,2,3), each=5) attr(fac2, levels) - as.character(1:3) oldClass(fac2) - factor is.factor(fac2) [1] TRUE split(rnorm(15), fac2) Error in split(x, f) : second argument must be a factor I think it is an error that the R-level and C-level tests for is.factor() are different. On Mon, 13 Feb 2006, Petr Pikal wrote: Hallo all Please help me. I am lost and do not know what is the problem. I have a factor called kvartaly. attributes(kvartaly) $levels [1] 1Q.04 2Q.04 3Q.04 4Q.04 1Q.05 2Q.05 3Q.05 4Q.05 $class [1] factor mode(kvartaly) [1] numeric str(kvartaly) Factor w/ 8 levels 1Q.04,2Q.04,..: 1 1 1 1 1 1 1 1 1 1 ... but if I call split it throws an error split(rnorm(731),kvartaly) Error in split(x, f) : second argument must be a factor so I tried to make a test example which works if I try to construct factor manually but fails if I use chron vec-c(1Q.04, 1Q.05, 1Q.06) fac-as.factor(rep(vec,c(5,5,5))) split(rnorm(15),fac) $1Q.04 [1] 1.9803999 -0.3672215 -1.0441346 0.5697196 -0.1350546 $1Q.05 [1] 2.40161776 -0.03924000 0.68973936 0.02800216 -0.74327321 $1Q.06 [1] 0.1887923 -1.8049586 1.4655549 0.1532533 2.1726117 vec1-as.Date(Sys.time()) Why not Sys.Date() ? vec1-c(vec1, vec1-100, vec1-300) vec1-rep(vec1,c(5,5,5)) fac1-interaction(quarters(as.chron(as.POSIXct(vec1))), format(vec1,%y)) split(rnorm(15),fac1) Error in split(x, f) : second argument must be a factor Why split does not accept fac1 if according to all tests it **is** a factor? Thank you Petr Petr Pikal [EMAIL PROTECTED] -- 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-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] ?bug? strange factors produced by chron
Thank you very much. On 13 Feb 2006 at 10:54, Prof Brian Ripley wrote: Date sent: Mon, 13 Feb 2006 10:54:21 + (GMT) From: Prof Brian Ripley [EMAIL PROTECTED] To: Petr Pikal [EMAIL PROTECTED] Copies to: r-help@stat.math.ethz.ch Subject:Re: [R] ?bug? strange factors produced by chron 1) The obvious test is via is.factor(), and you have not used that. I used it with TRUE result but did not use in my post (mea culpa) is.factor(kvartaly) [1] TRUE 2) Your example works for me, so what versions of R and chron is this? Package: chron Version: 2.3-1 R 2.2.1 and W2000 but problem is probably in interaction (see below) 3) Here's my guess. split is using the C-level test isFactor. That tests that the factor is of type integer, so please try typeof(kvartaly) typeof(kvartaly) [1] double Problem is probably not in chron but in interaction, which silently transfers factor type to double typeof(factor(letters[1:2])) [1] integer typeof(interaction(factor(letters[1:2]), factor(letters[3:4]))) [1] double I suspect you will get double and not integer, and if so you can fix this by storage.mode(kvartaly) - integer Thanks, it works. So here's an example which will fail fac2 - rep(c(1,2,3), each=5) attr(fac2, levels) - as.character(1:3) oldClass(fac2) - factor is.factor(fac2) [1] TRUE split(rnorm(15), fac2) Error in split(x, f) : second argument must be a factor I think it is an error that the R-level and C-level tests for is.factor() are different. snip vec1-as.Date(Sys.time()) Why not Sys.Date() ? I remembered only Sys.time when writing my mail. snip Thank you again. Best regards. PetrPetr Pikal [EMAIL PROTECTED] __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] ?bug? strange factors produced by chron
On Mon, 13 Feb 2006, Petr Pikal wrote: Thank you very much. On 13 Feb 2006 at 10:54, Prof Brian Ripley wrote: Date sent:Mon, 13 Feb 2006 10:54:21 + (GMT) From: Prof Brian Ripley [EMAIL PROTECTED] To: Petr Pikal [EMAIL PROTECTED] Copies to:r-help@stat.math.ethz.ch Subject: Re: [R] ?bug? strange factors produced by chron 1) The obvious test is via is.factor(), and you have not used that. I used it with TRUE result but did not use in my post (mea culpa) is.factor(kvartaly) [1] TRUE 2) Your example works for me, so what versions of R and chron is this? Package: chron Version: 2.3-1 R 2.2.1 and W2000 but problem is probably in interaction (see below) 3) Here's my guess. split is using the C-level test isFactor. That tests that the factor is of type integer, so please try typeof(kvartaly) typeof(kvartaly) [1] double Problem is probably not in chron but in interaction, which silently transfers factor type to double typeof(factor(letters[1:2])) [1] integer typeof(interaction(factor(letters[1:2]), factor(letters[3:4]))) [1] double 2.2.1 does not do that for me (and contains ans - as.integer(ans), and has since Sept 2001). Do you have a private copy? -- 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-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] ?bug? strange factors produced by chron
Hi On 13 Feb 2006 at 12:04, Prof Brian Ripley wrote: Date sent: Mon, 13 Feb 2006 12:04:49 + (GMT) From: Prof Brian Ripley [EMAIL PROTECTED] To: Petr Pikal [EMAIL PROTECTED] Copies to: r-help@stat.math.ethz.ch Subject:Re: [R] ?bug? strange factors produced by chron On Mon, 13 Feb 2006, Petr Pikal wrote: Thank you very much. On 13 Feb 2006 at 10:54, Prof Brian Ripley wrote: Date sent: Mon, 13 Feb 2006 10:54:21 + (GMT) From: Prof Brian Ripley [EMAIL PROTECTED] To: Petr Pikal [EMAIL PROTECTED] Copies to: r-help@stat.math.ethz.ch Subject:Re: [R] ?bug? strange factors produced by chron 1) The obvious test is via is.factor(), and you have not used that. I used it with TRUE result but did not use in my post (mea culpa) is.factor(kvartaly) [1] TRUE 2) Your example works for me, so what versions of R and chron is this? Package: chron Version: 2.3-1 R 2.2.1 and W2000 but problem is probably in interaction (see below) 3) Here's my guess. split is using the C-level test isFactor. That tests that the factor is of type integer, so please try typeof(kvartaly) typeof(kvartaly) [1] double Problem is probably not in chron but in interaction, which silently transfers factor type to double typeof(factor(letters[1:2])) [1] integer typeof(interaction(factor(letters[1:2]), factor(letters[3:4]))) [1] double 2.2.1 does not do that for me (and contains ans - as.integer(ans), and has since Sept 2001). Do you have a private copy? Yes, you have got it. I used (probably due to different handling of drop) a copy of interaction from Hmisc package from 2001, where there is no as.integer(ans). I'll switch to base version and see if there is no other problems with some of my code. As I noticed this behaviour only recently and use interaction from time to time so some other change had to sneaked around me without noticing. Thank you again. Best regards. Petr -- 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-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Petr Pikal [EMAIL PROTECTED] __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] bug with mai , pdf, and heatmap ?
Hi all, When using heatmap() with a pdf driver, and specifying parameters for mai in heatmap, I get a printout of the mai parameters at the top of the pdf...see attachment. This is on win2k pro with R2.2.1 Thanks, Ken __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug with mai , pdf, and heatmap ?
Ken Termiso wrote: Hi all, When using heatmap() with a pdf driver, and specifying parameters for mai in heatmap, I get a printout of the mai parameters at the top of the pdf...see attachment. This is on win2k pro with R2.2.1 Thanks, Ken Not a bug since ?heatmap has a main argument. Thus, heatmap(..., mai = c(1,2,3,4)) is actually interpretted as heatmap(..., main = c(1,2,3,4)) due to R's partial matching of the argument list. You should try: pdf() par(mai = c(1,2,3,4)) heatmap(...) dev.off() Hopefully I've assessed this correctly. HTH, --sundar P.S. See the posting guide regarding attachments to the list. __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] bug in either glmmPQL or lme/lmer
I know it's conventional to report bugs to the maintainer, but I'm not sure
which package actually contains this bug(s), so I apologize for sending this
to the list at large. I see the bug under both R 2.1.1, and R 2.2.1. (I sent
a related message a while ago, but this one has more detail.)
library(MASS)
library(nlme)
fit.model - function(il, model.family) {
cs - Initialize(corSymm(form=~1|id), data=il)
glmmPQL(score~test+coder, random=~1|id, family=model.family, data=il,
correlation=cs)
}
score -
c(1,8,1,3,4,4,2,5,3,6,0,3,1,5,0,5,1,11,1,2,4,5,2,4,1,6,1,2,8,16,5,16,3,15,3,12,4,9,2,4,1,8,2,6,4,11,2,9,3,17,2,6)
id - rep(1:13, rep(4, 13))
test - gl(2, 1, length(score), labels=c(pre, post))
coder - gl(2, 2, length(score), labels=c(two, three))
original - data.frame(id, score, test, coder)
sorted.ok - original[order(original$id, original$score, original$test,
original$coder),]
sorted2.ok - original[order(original$id, original$test, original$score,
original$coder),]
sorted3.not.ok - original[order(original$score, original$id, original$test,
original$coder),]
print(summary(fit.model(original, poisson)))
print(summary(fit.model(sorted.ok, poisson)))
print(summary(fit.model(sorted2.ok, poisson)))
print(summary(fit.model(sorted3.not.ok, poisson)))
That last line produces, under R version 2.1.1, 2005-06-20, i386-pc-mingw32
attached base packages:
[1] methods stats graphics grDevices utils datasets
[7] base
other attached packages:
MASS nlme
7.2-20 3.1-65
iteration 1
Error in logLik.reStruct(object, conLin) :
NA/NaN/Inf in foreign function call (arg 3)
That same last line produces, under R version 2.2.1, 2005-12-20,
i386-pc-mingw32
attached base packages:
[1] methods stats graphics grDevices utils datasets
[7] base
other attached packages:
MASS nlme
7.2-24 3.1-68.1
iteration 1
Error in lme.formula(fixed = zz ~ test + coder, random = ~1 | id, data =
list( :
false convergence (8)
Moreover, summary(fit.model(original, poisson)) produces a different output
than either
summary(fit.model(sorted.ok, poisson)) or summary(fit.model(sorted2.ok,
poisson)), but the latter two do equal each other.
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] Bug in bootcov; R 2.2
There's a bug in my version of bootcov. I'm not sure whether to report it here or in r-bugs, because it is in a contributed package. The bug is straightforward, so perhaps it has been reported, tho I found no reference in a search of the archive. Any attempt to run bootcov with both cluster and strata will throw an error indicating that jadd is not defined (Error: object jadd not found). The source of the error is the line: jadd - c(j, jadd) jadd does not appear elsewhere in the code, so it is undefined. I believe the correct line is: j - c(j, obs.gci) Information on my R version: R.Version() $platform [1] powerpc-apple-darwin7.9.0 $os [1] darwin7.9.0 $system [1] powerpc, darwin7.9.0 $status [1] $major [1] 2 $minor [1] 2.0 $svn rev [1] 35749 __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] Bug in bootcov; R 2.2
I see that I need to send my bug report to the package maintainer. Apologies for sending it to this list. There's a lot to absorb from various online pages when reporting a bug I missed the part about sending to the maintainer. Peter __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] bug?
library(foreign) da-read.dta(file.choose()) da startdat starttimenddate endtime days hoursmin secused 1 2005-01-112 2005-12-15 20.19 NA NA 9 attributes(da) $datalabel [1] Example of use of date and time functions $time.stamp [1] 15 十二月 2005 20 $names [1] startdat starttim enddate endtime days hoursmin secused $formats [1] %d%5.2f %d%5.2f %3.0f %5.2f %4.0f $types [1] 253 255 253 255 252 255 252 write.foreign(da,c:\\da.sps,da.txt,SPSS) then I try to run the da.sps,some errors come.I think the write.foreign function needs some improvement. It seems SPSS does not have such date/time data format as -mm-dd. Here is some information about the spss date/time format. Date/Time. Valid values include dates of the general format dd-mm-, mm/dd/, dd.mm., /mm/dd, hh:mm:ss, and a variety of other date and time formats. Months can be represented in digits, Roman numerals, or three-letter abbreviations, or they can be fully spelled out. Warning # 1102 An invalid numeric field has been found. The result has been set to the system-missing value. Command line: 7 Current case: 1 Current splitfile group: 1 Field contents: '2005-01-11' Record number: 1 Starting column: 1 Record length: 37 Warning # 1102 An invalid numeric field has been found. The result has been set to the system-missing value. Command line: 7 Current case: 1 Current splitfile group: 1 Field contents: '2005-12-15' Record number: 1 Starting column: 14 Record length: 37 Warning # 1102 An invalid numeric field has been found. The result has been set to the system-missing value. Command line: 7 Current case: 1 Current splitfile group: 1 Field contents: 'NA' Record number: 1 Starting column: 31 Record length: 37 Warning # 1102 An invalid numeric field has been found. The result has been set to the system-missing value. Command line: 7 Current case: 1 Current splitfile group: 1 Field contents: 'NA' Record number: 1 Starting column: 34 Record length: 37 packageDescription(foreign) Package: foreign Priority: recommended Version: 0.8-11 Date: 2005-12-08 Title: Read Data Stored by Minitab, S, SAS, SPSS, Stata, Systat, dBase, ... Depends: R (= 2.2.0) Imports: stats, methods Maintainer: R-core [EMAIL PROTECTED] Author: R-core members, Saikat DebRoy [EMAIL PROTECTED], Roger Bivand [EMAIL PROTECTED] and others: see COPYRIGHTS file in the sources. Description: Functions for reading and writing data stored by statistical packages such as Minitab, S, SAS, SPSS, Stata, Systat, ..., and for reading and writing .dbf (dBase) files. License: GPL version 2 or later Packaged: Fri Dec 9 14:46:20 2005; ripley Built: R 2.2.0; i386-pc-mingw32; 2005-12-10 14:23:19; windows 2005-12-15 -- Deparment of Sociology Fudan University My new mail addres is [EMAIL PROTECTED] Blog:http://sociology.yculblog.com __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug?
I suppose it is a bug in the documentation that it doesn't say it doesn't work with dates (or Surv objects, or ) It works with factors and numbers. -thomas On Thu, 15 Dec 2005, ronggui wrote: library(foreign) da-read.dta(file.choose()) da startdat starttimenddate endtime days hoursmin secused 1 2005-01-112 2005-12-15 20.19 NA NA 9 attributes(da) $datalabel [1] Example of use of date and time functions $time.stamp [1] 15 ?? 2005 20 $names [1] startdat starttim enddate endtime days hoursmin secused $formats [1] %d%5.2f %d%5.2f %3.0f %5.2f %4.0f $types [1] 253 255 253 255 252 255 252 write.foreign(da,c:\\da.sps,da.txt,SPSS) then I try to run the da.sps,some errors come.I think the write.foreign function needs some improvement. It seems SPSS does not have such date/time data format as -mm-dd. Here is some information about the spss date/time format. Date/Time. Valid values include dates of the general format dd-mm-, mm/dd/, dd.mm., /mm/dd, hh:mm:ss, and a variety of other date and time formats. Months can be represented in digits, Roman numerals, or three-letter abbreviations, or they can be fully spelled out. Warning # 1102 An invalid numeric field has been found. The result has been set to the system-missing value. Command line: 7 Current case: 1 Current splitfile group: 1 Field contents: '2005-01-11' Record number: 1 Starting column: 1 Record length: 37 Warning # 1102 An invalid numeric field has been found. The result has been set to the system-missing value. Command line: 7 Current case: 1 Current splitfile group: 1 Field contents: '2005-12-15' Record number: 1 Starting column: 14 Record length: 37 Warning # 1102 An invalid numeric field has been found. The result has been set to the system-missing value. Command line: 7 Current case: 1 Current splitfile group: 1 Field contents: 'NA' Record number: 1 Starting column: 31 Record length: 37 Warning # 1102 An invalid numeric field has been found. The result has been set to the system-missing value. Command line: 7 Current case: 1 Current splitfile group: 1 Field contents: 'NA' Record number: 1 Starting column: 34 Record length: 37 packageDescription(foreign) Package: foreign Priority: recommended Version: 0.8-11 Date: 2005-12-08 Title: Read Data Stored by Minitab, S, SAS, SPSS, Stata, Systat, dBase, ... Depends: R (= 2.2.0) Imports: stats, methods Maintainer: R-core [EMAIL PROTECTED] Author: R-core members, Saikat DebRoy [EMAIL PROTECTED], Roger Bivand [EMAIL PROTECTED] and others: see COPYRIGHTS file in the sources. Description: Functions for reading and writing data stored by statistical packages such as Minitab, S, SAS, SPSS, Stata, Systat, ..., and for reading and writing .dbf (dBase) files. License: GPL version 2 or later Packaged: Fri Dec 9 14:46:20 2005; ripley Built: R 2.2.0; i386-pc-mingw32; 2005-12-10 14:23:19; windows 2005-12-15 -- Deparment of Sociology Fudan University My new mail addres is [EMAIL PROTECTED] Blog:http://sociology.yculblog.com Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle__ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] bug in geoR (?)
I've enconuntered this problem with the last cran version of geoR: library(geoR) day - rep(1:2, each=5) coords - matrix(rep(runif(10),2), 10, 2) data - rnorm(10) data[1] - NA as.geodata(cbind(coords, data, day), realisations=4) as.geodata: 1 points removed due to NA in the data Errore in as.geodata(cbind(coords, data, day), realisations = 4) : realisations and coords have incompatible dimensions The problem disappear if I remove the NA manually from the dataset before passing to as.geodata. I.e.: as.geodata(cbind(coords, data, day)[2:10,], realisations=4) works. Antonio, Fabio Di Narzo. [[alternative HTML version deleted]] __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug in geoR (?)
Dear Fabio PLease download the latest geoR from: www.est.ufpr.br/geoR and let me know in case the problem persists P.J. On Tue, 13 Dec 2005, Antonio, Fabio Di Narzo wrote: Date: Tue, 13 Dec 2005 17:18:14 +0100 From: Antonio, Fabio Di Narzo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: R-help@stat.math.ethz.ch Subject: [R] bug in geoR (?) I've enconuntered this problem with the last cran version of geoR: library(geoR) day - rep(1:2, each=5) coords - matrix(rep(runif(10),2), 10, 2) data - rnorm(10) data[1] - NA as.geodata(cbind(coords, data, day), realisations=4) as.geodata: 1 points removed due to NA in the data Errore in as.geodata(cbind(coords, data, day), realisations = 4) : realisations and coords have incompatible dimensions The problem disappear if I remove the NA manually from the dataset before passing to as.geodata. I.e.: as.geodata(cbind(coords, data, day)[2:10,], realisations=4) works. Antonio, Fabio Di Narzo. [[alternative HTML version deleted]] __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Paulo Justiniano Ribeiro Jr LEG (Laboratório de Estatística e Geoinformação) Departamento de Estatística Universidade Federal do Paraná Caixa Postal 19.081 CEP 81.531-990 Curitiba, PR - Brasil Tel: (+55) 41 3361 3573 Fax: (+55) 41 3361 3141 e-mail: [EMAIL PROTECTED] http://www.est.ufpr.br/~paulojus__ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] bug/feature with barplot?
I have found a bug/feature with barplot that at least to me shows undesireable behaviour. When using barplot and plotting fewer groups/levels/factors(I am unsure what they are called) than the number of colors stated in a col statement, the colors wrap around such that the colors are not fixed to one group. This is mostly problematic when I make R figures using scripts, since I sometimes have empty input groups. I have in these cases experienced labeling the empty group as red, and then seeing a bar being red when that bar is actually from a different group. Reproducible example (I hope): barplot(VADeaths, beside=TRUE, col=c(red, green, blue, yellow, black)) barplot(VADeaths[1:4,], beside=TRUE, col=c(red, green, blue, yellow, black)) Now, I don't know if this is a bug or a feature, but it sure bugged me...:) Karin -- Karin Lagesen, PhD student [EMAIL PROTECTED] http://www.cmbn.no/rognes/ __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug/feature with barplot?
On Mon, 2005-11-14 at 15:55 +0100, Karin Lagesen wrote: I have found a bug/feature with barplot that at least to me shows undesireable behaviour. When using barplot and plotting fewer groups/levels/factors(I am unsure what they are called) than the number of colors stated in a col statement, the colors wrap around such that the colors are not fixed to one group. This is mostly problematic when I make R figures using scripts, since I sometimes have empty input groups. I have in these cases experienced labeling the empty group as red, and then seeing a bar being red when that bar is actually from a different group. Reproducible example (I hope): barplot(VADeaths, beside=TRUE, col=c(red, green, blue, yellow, black)) barplot(VADeaths[1:4,], beside=TRUE, col=c(red, green, blue, yellow, black)) Now, I don't know if this is a bug or a feature, but it sure bugged me...:) Karin Most definitely not a bug. As with many vectorized function arguments, they will be recycled as required to match the length of other appropriate arguments. In this case, the number of colors (5) does not match the number of groups (4). Thus, they are out of synch with each other and you get the result you have. Not unexpected behavior. You should adjust your code and the function call so that the number of groups matches the number of colors. Something along the lines of the following: col - c(red, green, blue, yellow, black) no.groups - 4 barplot(VADeaths[1:no.groups, ], beside = TRUE, col = col[1:no.groups]) Now try: no.groups - 5 barplot(VADeaths[1:no.groups, ], beside = TRUE, col = col[1:no.groups]) no.groups - 3 barplot(VADeaths[1:no.groups, ], beside = TRUE, col = col[1:no.groups]) HTH, Marc Schwartz __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug report on get.hist.quote
get.hist.quote(instrument=INR/USD, provider=oanda, start=2005-10-20) trying URL 'http://www.oanda.com/convert/fxhistory?lang=endate1=10%2F20%2F2005date=11%2F01%2F2005date_fmt=usexch=INRexch2=expr=USDexpr2=margin_fixed=0SUBMIT=Get+Tableformat=ASCIIredirected=1' Content type 'text/html' length unknown opened URL .. ... downloaded 13Kb 2005-10-20 2005-10-21 2005-10-22 2005-10-23 2005-10-24 2005-10-25 2005-10-26 0.022200.022180.022240.022240.022240.022190.02226 2005-10-27 2005-10-28 2005-10-29 2005-10-30 2005-10-31 2005-11-01 0.022240.022250.022240.022240.022240.02221 The answer is wrong. What is shown here is USD/INR, not INR/USD. Ajay, This is not a bug! The answer is correct. *1 Indian Rupee = 0.02220 US Dollar on *2005-10-20 and this is also the standard way currencies are quoted. Pls read, e.g. http://fxtrade.oanda.com/currency_trading/fxbasics.shtml Best regards Adrian __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] Bug report on get.hist.quote
get.hist.quote(instrument=INR/USD, provider=oanda, start=2005-10-20) trying URL 'http://www.oanda.com/convert/fxhistory?lang=endate1=10%2F20%2F2005date=11%2F01%2F2005date_fmt=usexch=INRexch2=expr=USDexpr2=margin_fixed=0SUBMIT=Get+Tableformat=ASCIIredirected=1' Content type 'text/html' length unknown opened URL .. ... downloaded 13Kb 2005-10-20 2005-10-21 2005-10-22 2005-10-23 2005-10-24 2005-10-25 2005-10-26 0.022200.022180.022240.022240.022240.022190.02226 2005-10-27 2005-10-28 2005-10-29 2005-10-30 2005-10-31 2005-11-01 0.022240.022250.022240.022240.022240.02221 The answer is wrong. What is shown here is USD/INR, not INR/USD. __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug report on get.hist.quote
Perhaps you forgot that currency pairs are named upsidedown; e.g., USD/JPY is yen per dollar? (This is sometimes written USD-JPY to try to avoid the confusion. It is read dollar-yen.) David L. Reiner -Original Message- From: [EMAIL PROTECTED] [mailto:r-help- [EMAIL PROTECTED] On Behalf Of Ajay Shah Sent: Wednesday, November 02, 2005 5:09 AM To: r-help@stat.math.ethz.ch Subject: [R] Bug report on get.hist.quote get.hist.quote(instrument=INR/USD, provider=oanda, start=2005-10- 20) trying URL 'http://www.oanda.com/convert/fxhistory?lang=endate1=10%2F20%2F2005dat e= 11%2F01%2F2005date_fmt=usexch=INRexch2=expr=USDexpr2=margin_fixed= 0 SUBMIT=Get+Tableformat=ASCIIredirected=1' Content type 'text/html' length unknown opened URL .. ... downloaded 13Kb 2005-10-20 2005-10-21 2005-10-22 2005-10-23 2005-10-24 2005-10-25 2005-10- 26 0.022200.022180.022240.022240.022240.02219 0.02226 2005-10-27 2005-10-28 2005-10-29 2005-10-30 2005-10-31 2005-11-01 0.022240.022250.022240.022240.022240.02221 The answer is wrong. What is shown here is USD/INR, not INR/USD. __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting- guide.html __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug checking
Thanks all for following up. I'll consider the bug filed. I should note for the record that if 'col=red' is replaced in my code by 'col.main=red' the x axis is still made red. I'll use the workaround for now (for which thanks). Even with little things like this, plotting from the command line in R is orders better than dragging a bunch of frames around an Excel window. On Oct 11, 2005, at 6:34 PM, Marc Schwartz wrote: Thanks for the code and the clarifications, including the PDF file. Yes, I can replicate the behavior here (R 2.2.0 on FC4) and I am cc:ing Kurt Hornik, who ported chron to R and is the chron package maintainer. It appears that the culprit is the argument 'col = red', which towards the end of plot.times() is used as follows: ... else if (x.times) axis.times(1, x, simplify = simplify, labels = TRUE, adj = adj, col = col, cex = cex, font = font, las = las, lab = lab, mgp = mgp, tcl = tcl) ... Thus, if the 'x' data is of class 'times', the above code is used and the color of the axis line and tick marks are set to red as per the 'col' argument to axis(), which axis.times() ultimately calls. This results in the behavior that you are seeing, where both the plot symbols/lines and the axis are colored the same. This does sound like a bug and Kurt can comment better on this. HTH, Marc Schwartz On Tue, 2005-10-11 at 18:02 -1000, Parlamis Franklin wrote: ## Code was long, so I simplified it by creating vectors from scratch so it would run as is. Putative bug is still evidenced on the x axis discount.factors.dates - seq.dates(from=09/30/2005, to=09/30/2035) rates-seq(4.4, 5.2, by=0.0025); plot(discount.factors.dates[1:length(rates)], rates, pch=18, las=1, bty=n, col=red, col.main=red, xlab=Date, ylab=Rate, ylim=c(min(rates)-(max(rates)-min(rates))/10,max(rates)+(max (rates)-min(rates))/10)) ## This is the output: ## Hopefully you all see the red x axis. ## I am running R Cocoa GUI 1.1.2 with R 2.1.1 framework on a dual proc 2.7 Ghz Power Mac. A Quartz device is opened when 'plot' is called. X11User and X11SDK are installed on t he computer, as well as xCode 2.1 (in case that's relevant). On Oct 11, 2005, at 4:47 PM, Marc Schwartz wrote: On Tue, 2005-10-11 at 16:07 -1000, Parlamis Franklin wrote: I have observed the following behavior, wondering if it is a bug before I submit a report. I am using the plot function with call: plot(X, Y, col=red, . . . ) where X is an object that inherits from classes 'dates' and 'times' (created with the 'dates' function from package 'chron') and y is a numeric vector. The color red is applied to the area from the first to the last tick mark on the x axis (even if I don't set col=red and only set, say col.main=red). If instead of feeding the function X, I feed it unclass(X) or as.vector(X) the red color is not applied to the area between the first and last ticks on the x axis. Is this a bug, or just a consequence of there not being a plot method for the class I am trying to feed the function? Franklin Parlamis As per the Posting Guide, it would be immensely helpful in the attempt to help you, if you would provide the exact code you are using and some sample data here, so that we can exactly replicate what you are experiencing. Lacking that, it would be difficult to assist as we can only guess. It does sound like there is an _appropriate_ change in the plot method behavior as a direct consequence of your modifying the class of the argument(s), which is of course how methods are dispatched. Thus, if I were to guess, this is not a bug. I would however, certainly recommend that you submit an example here to confirm the behavior, before you post a bug report, as that would avoid a more energetic response. Marc Schwartz __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug checking
Three additional comments: 1. The same phenomena occurs on the y axis if the x and y values are reversed. 2. I neglected to mention this last night (my time), but given that chron is not part of the base R distribution, the proper procedure for actually filing a bug against the package would be to contact the author/maintainer (Kurt) and not to file a bug in the main R bug tracking system. 3. The problem with 'col.main' is I believe a result of this argument being passed as part of the ... arguments to plot.times(). Hence you end up with partial matching of the argument here, so col.main is operated upon in the same fashion as col. HTH, Marc Schwartz On Tue, 2005-10-11 at 21:06 -1000, Parlamis Franklin wrote: Thanks all for following up. I'll consider the bug filed. I should note for the record that if 'col=red' is replaced in my code by 'col.main=red' the x axis is still made red. I'll use the workaround for now (for which thanks). Even with little things like this, plotting from the command line in R is orders better than dragging a bunch of frames around an Excel window. On Oct 11, 2005, at 6:34 PM, Marc Schwartz wrote: Thanks for the code and the clarifications, including the PDF file. Yes, I can replicate the behavior here (R 2.2.0 on FC4) and I am cc:ing Kurt Hornik, who ported chron to R and is the chron package maintainer. It appears that the culprit is the argument 'col = red', which towards the end of plot.times() is used as follows: ... else if (x.times) axis.times(1, x, simplify = simplify, labels = TRUE, adj = adj, col = col, cex = cex, font = font, las = las, lab = lab, mgp = mgp, tcl = tcl) ... Thus, if the 'x' data is of class 'times', the above code is used and the color of the axis line and tick marks are set to red as per the 'col' argument to axis(), which axis.times() ultimately calls. This results in the behavior that you are seeing, where both the plot symbols/lines and the axis are colored the same. This does sound like a bug and Kurt can comment better on this. HTH, Marc Schwartz On Tue, 2005-10-11 at 18:02 -1000, Parlamis Franklin wrote: ## Code was long, so I simplified it by creating vectors from scratch so it would run as is. Putative bug is still evidenced on the x axis discount.factors.dates - seq.dates(from=09/30/2005, to=09/30/2035) rates-seq(4.4, 5.2, by=0.0025); plot(discount.factors.dates[1:length(rates)], rates, pch=18, las=1, bty=n, col=red, col.main=red, xlab=Date, ylab=Rate, ylim=c(min(rates)-(max(rates)-min(rates))/10,max(rates)+(max (rates)-min(rates))/10)) ## This is the output: ## Hopefully you all see the red x axis. ## I am running R Cocoa GUI 1.1.2 with R 2.1.1 framework on a dual proc 2.7 Ghz Power Mac. A Quartz device is opened when 'plot' is called. X11User and X11SDK are installed on t he computer, as well as xCode 2.1 (in case that's relevant). On Oct 11, 2005, at 4:47 PM, Marc Schwartz wrote: On Tue, 2005-10-11 at 16:07 -1000, Parlamis Franklin wrote: I have observed the following behavior, wondering if it is a bug before I submit a report. I am using the plot function with call: plot(X, Y, col=red, . . . ) where X is an object that inherits from classes 'dates' and 'times' (created with the 'dates' function from package 'chron') and y is a numeric vector. The color red is applied to the area from the first to the last tick mark on the x axis (even if I don't set col=red and only set, say col.main=red). If instead of feeding the function X, I feed it unclass(X) or as.vector(X) the red color is not applied to the area between the first and last ticks on the x axis. Is this a bug, or just a consequence of there not being a plot method for the class I am trying to feed the function? Franklin Parlamis As per the Posting Guide, it would be immensely helpful in the attempt to help you, if you would provide the exact code you are using and some sample data here, so that we can exactly replicate what you are experiencing. Lacking that, it would be difficult to assist as we can only guess. It does sound like there is an _appropriate_ change in the plot method behavior as a direct consequence of your modifying the class of the argument(s), which is of course how methods are dispatched. Thus, if I were to guess, this is not a bug. I would however, certainly recommend that you submit an example here to confirm the behavior, before you post a bug report, as that would avoid a more energetic response. Marc Schwartz __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug checking
Yes, its a bug. The calls to axis.times in plot.times use the same col variable as the points do. This shows it more compactly: library(chron) x - seq.dates(from=09/30/2005, len = 10) plot(x, 1:10, col = red) A workaround would be to plot the X axis separately: plot(x, 1:10, col = red, xaxt = n) axis.times(1, x) or use plot.Date: library(zoo) # needed for as.Date.numeric plot(as.Date(as.numeric(x)), 1:length(x), col = red) On 10/12/05, Parlamis Franklin [EMAIL PROTECTED] wrote: ## Code was long, so I simplified it by creating vectors from scratch so it would run as is. Putative bug is still evidenced on the x axis discount.factors.dates - seq.dates(from=09/30/2005, to=09/30/2035) rates-seq(4.4, 5.2, by=0.0025); plot(discount.factors.dates[1:length(rates)], rates, pch=18, las=1, bty=n, col=red, col.main=red, xlab=Date, ylab=Rate, ylim=c(min(rates)-(max(rates)-min(rates))/10,max(rates)+(max (rates)-min(rates))/10)) ## This is the output: ## Hopefully you all see the red x axis. ## I am running R Cocoa GUI 1.1.2 with R 2.1.1 framework on a dual proc 2.7 Ghz Power Mac. A Quartz device is opened when 'plot' is called. X11User and X11SDK are installed on t he computer, as well as xCode 2.1 (in case that's relevant). On Oct 11, 2005, at 4:47 PM, Marc Schwartz wrote: On Tue, 2005-10-11 at 16:07 -1000, Parlamis Franklin wrote: I have observed the following behavior, wondering if it is a bug before I submit a report. I am using the plot function with call: plot(X, Y, col=red, . . . ) where X is an object that inherits from classes 'dates' and 'times' (created with the 'dates' function from package 'chron') and y is a numeric vector. The color red is applied to the area from the first to the last tick mark on the x axis (even if I don't set col=red and only set, say col.main=red). If instead of feeding the function X, I feed it unclass(X) or as.vector(X) the red color is not applied to the area between the first and last ticks on the x axis. Is this a bug, or just a consequence of there not being a plot method for the class I am trying to feed the function? Franklin Parlamis As per the Posting Guide, it would be immensely helpful in the attempt to help you, if you would provide the exact code you are using and some sample data here, so that we can exactly replicate what you are experiencing. Lacking that, it would be difficult to assist as we can only guess. It does sound like there is an _appropriate_ change in the plot method behavior as a direct consequence of your modifying the class of the argument(s), which is of course how methods are dispatched. Thus, if I were to guess, this is not a bug. I would however, certainly recommend that you submit an example here to confirm the behavior, before you post a bug report, as that would avoid a more energetic response. Marc Schwartz __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] bug checking
I have observed the following behavior, wondering if it is a bug before I submit a report. I am using the plot function with call: plot(X, Y, col=red, . . . ) where X is an object that inherits from classes 'dates' and 'times' (created with the 'dates' function from package 'chron') and y is a numeric vector. The color red is applied to the area from the first to the last tick mark on the x axis (even if I don't set col=red and only set, say col.main=red). If instead of feeding the function X, I feed it unclass(X) or as.vector(X) the red color is not applied to the area between the first and last ticks on the x axis. Is this a bug, or just a consequence of there not being a plot method for the class I am trying to feed the function? Franklin Parlamis __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug checking
On Tue, 2005-10-11 at 16:07 -1000, Parlamis Franklin wrote: I have observed the following behavior, wondering if it is a bug before I submit a report. I am using the plot function with call: plot(X, Y, col=red, . . . ) where X is an object that inherits from classes 'dates' and 'times' (created with the 'dates' function from package 'chron') and y is a numeric vector. The color red is applied to the area from the first to the last tick mark on the x axis (even if I don't set col=red and only set, say col.main=red). If instead of feeding the function X, I feed it unclass(X) or as.vector(X) the red color is not applied to the area between the first and last ticks on the x axis. Is this a bug, or just a consequence of there not being a plot method for the class I am trying to feed the function? Franklin Parlamis As per the Posting Guide, it would be immensely helpful in the attempt to help you, if you would provide the exact code you are using and some sample data here, so that we can exactly replicate what you are experiencing. Lacking that, it would be difficult to assist as we can only guess. It does sound like there is an _appropriate_ change in the plot method behavior as a direct consequence of your modifying the class of the argument(s), which is of course how methods are dispatched. Thus, if I were to guess, this is not a bug. I would however, certainly recommend that you submit an example here to confirm the behavior, before you post a bug report, as that would avoid a more energetic response. Marc Schwartz __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug checking
## Code was long, so I simplified it by creating vectors from scratch so it would run as is. Putative bug is still evidenced on the x axis discount.factors.dates - seq.dates(from=09/30/2005, to=09/30/2035) rates-seq(4.4, 5.2, by=0.0025); plot(discount.factors.dates[1:length(rates)], rates, pch=18, las=1, bty=n, col=red, col.main=red, xlab=Date, ylab=Rate, ylim=c(min(rates)-(max(rates)-min(rates))/10,max(rates)+(max (rates)-min(rates))/10)) ## This is the output: plot.pdf Description: Adobe PDF document ## Hopefully you all see the red x axis. ## I am running R Cocoa GUI 1.1.2 with R 2.1.1 framework on a dual proc 2.7 Ghz Power Mac. A Quartz device is opened when 'plot' is called. X11User and X11SDK are installed on t he computer, as well as xCode 2.1 (in case that's relevant). On Oct 11, 2005, at 4:47 PM, Marc Schwartz wrote: On Tue, 2005-10-11 at 16:07 -1000, Parlamis Franklin wrote: I have observed the following behavior, wondering if it is a bug before I submit a report. I am using the plot function with call: plot(X, Y, col=red, . . . ) where X is an object that inherits from classes 'dates' and 'times' (created with the 'dates' function from package 'chron') and y is a numeric vector. The color red is applied to the area from the first to the last tick mark on the x axis (even if I don't set col=red and only set, say col.main=red). If instead of feeding the function X, I feed it unclass(X) or as.vector(X) the red color is not applied to the area between the first and last ticks on the x axis. Is this a bug, or just a consequence of there not being a plot method for the class I am trying to feed the function? Franklin Parlamis As per the Posting Guide, it would be immensely helpful in the attempt to help you, if you would provide the exact code you are using and some sample data here, so that we can exactly replicate what you are experiencing. Lacking that, it would be difficult to assist as we can only guess. It does sound like there is an _appropriate_ change in the plot method behavior as a direct consequence of your modifying the class of the argument(s), which is of course how methods are dispatched. Thus, if I were to guess, this is not a bug. I would however, certainly recommend that you submit an example here to confirm the behavior, before you post a bug report, as that would avoid a more energetic response. Marc Schwartz __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] bug checking
Thanks for the code and the clarifications, including the PDF file. Yes, I can replicate the behavior here (R 2.2.0 on FC4) and I am cc:ing Kurt Hornik, who ported chron to R and is the chron package maintainer. It appears that the culprit is the argument 'col = red', which towards the end of plot.times() is used as follows: ... else if (x.times) axis.times(1, x, simplify = simplify, labels = TRUE, adj = adj, col = col, cex = cex, font = font, las = las, lab = lab, mgp = mgp, tcl = tcl) ... Thus, if the 'x' data is of class 'times', the above code is used and the color of the axis line and tick marks are set to red as per the 'col' argument to axis(), which axis.times() ultimately calls. This results in the behavior that you are seeing, where both the plot symbols/lines and the axis are colored the same. This does sound like a bug and Kurt can comment better on this. HTH, Marc Schwartz On Tue, 2005-10-11 at 18:02 -1000, Parlamis Franklin wrote: ## Code was long, so I simplified it by creating vectors from scratch so it would run as is. Putative bug is still evidenced on the x axis discount.factors.dates - seq.dates(from=09/30/2005, to=09/30/2035) rates-seq(4.4, 5.2, by=0.0025); plot(discount.factors.dates[1:length(rates)], rates, pch=18, las=1, bty=n, col=red, col.main=red, xlab=Date, ylab=Rate, ylim=c(min(rates)-(max(rates)-min(rates))/10,max(rates)+(max (rates)-min(rates))/10)) ## This is the output: ## Hopefully you all see the red x axis. ## I am running R Cocoa GUI 1.1.2 with R 2.1.1 framework on a dual proc 2.7 Ghz Power Mac. A Quartz device is opened when 'plot' is called. X11User and X11SDK are installed on t he computer, as well as xCode 2.1 (in case that's relevant). On Oct 11, 2005, at 4:47 PM, Marc Schwartz wrote: On Tue, 2005-10-11 at 16:07 -1000, Parlamis Franklin wrote: I have observed the following behavior, wondering if it is a bug before I submit a report. I am using the plot function with call: plot(X, Y, col=red, . . . ) where X is an object that inherits from classes 'dates' and 'times' (created with the 'dates' function from package 'chron') and y is a numeric vector. The color red is applied to the area from the first to the last tick mark on the x axis (even if I don't set col=red and only set, say col.main=red). If instead of feeding the function X, I feed it unclass(X) or as.vector(X) the red color is not applied to the area between the first and last ticks on the x axis. Is this a bug, or just a consequence of there not being a plot method for the class I am trying to feed the function? Franklin Parlamis As per the Posting Guide, it would be immensely helpful in the attempt to help you, if you would provide the exact code you are using and some sample data here, so that we can exactly replicate what you are experiencing. Lacking that, it would be difficult to assist as we can only guess. It does sound like there is an _appropriate_ change in the plot method behavior as a direct consequence of your modifying the class of the argument(s), which is of course how methods are dispatched. Thus, if I were to guess, this is not a bug. I would however, certainly recommend that you submit an example here to confirm the behavior, before you post a bug report, as that would avoid a more energetic response. Marc Schwartz __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in lmer?
It is indeed a bug and I will address it. On 9/30/05, Horacio Montenegro [EMAIL PROTECTED] wrote: Just to add more info: I've got the same error with both lme4 0.95-10 Matrix 0.95-13 and lme4 0.98-1 Matrix 0.98-7, always running on Win98SE, R 2.1.1. So it seems to occur with any Windows version. cheers, Horacio I'm putting the data and an R script up for FTP, so that you or others can run this ``from anywhere'' via source(ftp://stat.ethz.ch/U/maechler/R/mltloc-ex.R;, echo = TRUE) Maybe this helps diagnosis, Martin Maechler __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in lmer?
Mark == Mark Lyman [EMAIL PROTECTED]
on Thu, 29 Sep 2005 14:44:38 -0600 writes:
Mark I am relatively new to R so I am not confident enough in what I am
doing
Mark to be certain this is a bug.
Mark I am running R 2.1.1 on a Windows XP
Mark machine and the lme4 package version 0.98-1.
lme4 nowadays is heavily based on Matrix which version are you
using there?
Mark The following code fits the model I want using the
Mark nlme package version 3.1-60.
.. {see a script at the end}
Mark The problem is that when I try fitting the model using
Mark the lmer function with the following code:
Mark lmer(adg~trt+(1|loc)+(1|block:loc)+(1|loc:trt),mltloc)
Mark I get this message from Windows and R closes.
Mark R for Windows GUI front-end has encountered a problem and needs to
Mark close. We are sorry for the inconvenience.
That definitely means there is a bug.
The question is *where* the bug is: lme4, Matrix, R, Windows.
One first thing coming to mind is a mismatch of lme4 and Matri
Mark This same code works on a Macintosh. So it doesn't
Mark seem that I have made an error in my code.
correct; I can also fit the model nice and quickly on Linux,
and summary() confirms the same fit {with the usual problem of
different estimates for the degrees of freedoms 'df'}.
So currently the bug only shows on the Windows platform.
Could it be that you have a mismatching package Matrix version
there, but not on the Mac?
Mark Also if anyone of the random effect terms is removed there is
Mark no problem. Is this something that is being looked at?
not yet, AFAIK.
Mark Or I have I made a mistake somewhere? I have included
Mark the data that I am using below.
I'm putting the data and an R script up for FTP,
so that you or others can run this ``from anywhere'' via
source(ftp://stat.ethz.ch/U/maechler/R/mltloc-ex.R;, echo = TRUE)
Maybe this helps diagnosis,
Martin Maechler
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in lmer?
To All: Mark and Martin's code ran fine on R : Version 2.1.1 (2005-06-20) on a Macintosh Dual 2 GHz G5 with 1.5 GB DDR SDRAM. Hank On Sep 30, 2005, at 3:21 AM, Martin Maechler wrote: source(ftp://stat.ethz.ch/U/maechler/R/mltloc-ex.R;, echo = TRUE) Dr. Martin Henry H. Stevens, Assistant Professor 338 Pearson Hall Botany Department Miami University Oxford, OH 45056 Office: (513) 529-4206 Lab: (513) 529-4262 FAX: (513) 529-4243 http://www.cas.muohio.edu/~stevenmh/ http://www.muohio.edu/ecology/ http://www.muohio.edu/botany/ E Pluribus Unum __ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in lmer?
I forgot to mention the OS - Mac OS 10.4.2 (Tiger with the latest
update). {:-)
Hank
On Sep 30, 2005, at 3:40 AM, Martin Henry H. Stevens wrote:
To All:
Mark and Martin's code ran fine on R : Version 2.1.1 (2005-06-20) on
a Macintosh Dual 2 GHz G5 with 1.5 GB DDR SDRAM.
Hank
On Sep 30, 2005, at 3:21 AM, Martin Maechler wrote:
source(ftp://stat.ethz.ch/U/maechler/R/mltloc-ex.R;, echo = TRUE)
Dr. Martin Henry H. Stevens, Assistant Professor
338 Pearson Hall
Botany Department
Miami University
Oxford, OH 45056
Office: (513) 529-4206
Lab: (513) 529-4262
FAX: (513) 529-4243
http://www.cas.muohio.edu/~stevenmh/
http://www.muohio.edu/ecology/
http://www.muohio.edu/botany/
E Pluribus Unum
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-
guide.html
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Bug in lmer?
I got a crash too with my Win XP config running:
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status beta
major2
minor2.0
year 2005
month09
day 24
svn rev 35666
language R
Package: Matrix
Version: 0.98-7
Date: 2005-09-09
Package: lme4
Version: 0.98-1
Date: 2005-07-27
The monitoring of the crash with Dr.MingW provided the following information:
Rgui.exe caused an Access Violation at location 1001ed89 in module
R.dll Writing to location 0008.
Registers:
eax= ebx=0040 ecx=011c8a18 edx=011c8058 esi=011c8a40 edi=0018
eip=1001ed89 esp=0022dc20 ebp=0022dc48 iopl=0 nv up ei pl nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0212
Call stack:
1001ED89 R.dll:1001ED89 malloc_usable_size
1001FC2A R.dll:1001FC2A Rm_malloc
1009EF69 R.dll:1009EF69 Rf_allocVector
100389D8 R.dll:100389D8 do_makevector
100A6141 R.dll:100A6141 do_internal
10081FBF R.dll:10081FBF Rf_eval
10084C2B R.dll:10084C2B Rf_applyClosure
10081D50 R.dll:10081D50 Rf_eval
10084C2B R.dll:10084C2B Rf_applyClosure
10081D50 R.dll:10081D50 Rf_eval
10083985 R.dll:10083985 do_set
10081FBF R.dll:10081FBF Rf_eval
10083A55 R.dll:10083A55 do_begin
10081FBF R.dll:10081FBF Rf_eval
10084C2B R.dll:10084C2B Rf_applyClosure
10081D50 R.dll:10081D50 Rf_eval
10081FBF R.dll:10081FBF Rf_eval
10083985 R.dll:10083985 do_set
10081FBF R.dll:10081FBF Rf_eval
10083A55 R.dll:10083A55 do_begin
10081FBF R.dll:10081FBF Rf_eval
1008457D R.dll:1008457D do_if
1008489B R.dll:1008489B R_execMethod
016A2907 methods.dll:016A2907 R_standardGeneric
100A9254 R.dll:100A9254 do_standardGeneric
10082094 R.dll:10082094 Rf_eval
10084C2B R.dll:10084C2B Rf_applyClosure
10081D50 R.dll:10081D50 Rf_eval
10083985 R.dll:10083985 do_set
10081FBF R.dll:10081FBF Rf_eval
10083716 R.dll:10083716 Rf_DispatchOrEval
10081FBF R.dll:10081FBF Rf_eval
10083A55 R.dll:10083A55 do_begin
10081FBF R.dll:10081FBF Rf_eval
10081FBF R.dll:10081FBF Rf_eval
10083A55 R.dll:10083A55 do_begin
10081FBF R.dll:10081FBF Rf_eval
1008457D R.dll:1008457D do_if
1008489B R.dll:1008489B R_execMethod
016A2907 methods.dll:016A2907 R_standardGeneric
100A9254 R.dll:100A9254 do_standardGeneric
10082094 R.dll:10082094 Rf_eval
10084C2B R.dll:10084C2B Rf_applyClosure
10081D50 R.dll:10081D50 Rf_eval
10083985 R.dll:10083985 do_set
10081FBF R.dll:10081FBF Rf_eval
1009AAF5 R.dll:1009AAF5 Rf_ReplIteration
1009AC27 R.dll:1009AC27 Rf_ReplIteration
1009AEB7 R.dll:1009AEB7 run_Rmainloop
004013AA Rgui.exe:004013AA
00401315 Rgui.exe:00401315
00401568 Rgui.exe:00401568
00401236 Rgui.exe:00401236
00401288 Rgui.exe:00401288
7C816D4F kernel32.dll:7C816D4F RegisterWaitForInputIdle
Best,
Renaud
2005/9/30, Martin Maechler [EMAIL PROTECTED]:
Mark == Mark Lyman [EMAIL PROTECTED]
on Thu, 29 Sep 2005 14:44:38 -0600 writes:
Mark I am relatively new to R so I am not confident enough in what I am
doing
Mark to be certain this is a bug.
Mark I am running R 2.1.1 on a Windows XP
Mark machine and the lme4 package version 0.98-1.
lme4 nowadays is heavily based on Matrix which version are you
using there?
Mark The following code fits the model I want using the
Mark nlme package version 3.1-60.
.. {see a script at the end}
Mark The problem is that when I try fitting the model using
Mark the lmer function with the following code:
Mark lmer(adg~trt+(1|loc)+(1|block:loc)+(1|loc:trt),mltloc)
Mark I get this message from Windows and R closes.
Mark R for Windows GUI front-end has encountered a problem and needs
to
Mark close. We are sorry for the inconvenience.
That definitely means there is a bug.
The question is *where* the bug is: lme4, Matrix, R, Windows.
One first thing coming to mind is a mismatch of lme4 and Matri
Mark This same code works on a Macintosh. So it doesn't
Mark seem that I have made an error in my code.
correct; I can also fit the model nice and quickly on Linux,
and summary() confirms the same fit {with the usual problem of
different estimates for the degrees of freedoms 'df'}.
So currently the bug only shows on the Windows platform.
Could it be that you have a mismatching package Matrix version
there, but not on the Mac?
Mark Also if anyone of the random effect terms is removed there is
Mark no problem. Is this something that is being looked at?
not yet, AFAIK.
Mark Or I have I made a mistake somewhere? I have included
Mark the data that I am using below.
I'm putting the data and an R script up for FTP,
so that you or others can run this ``from anywhere'' via
source(ftp://stat.ethz.ch/U/maechler/R/mltloc-ex.R;, echo = TRUE)
Maybe this helps diagnosis,
Martin Maechler
__
