Re: [R] possible bug in vars package (predict.varest) ???
Hello Spencer,
which version of vars are you using? This has been fixed a while ago
(see ChangeLog). Incidentally, the data in Canada is quarterly data, as
stated in ?Canada. Aside of this, your code snippet works fine.
Best,
Bernhard
ps: There is no need to download the tarball as suggested by Mark,
instead you can do: vars:::predict.varest
>hello,
>
>I have been trying to use the predict function in the vars package to
>forecast from a seasonal VAR model. The following code sample
>illustrates
>what I am trying to do and the error that I get when trying to do it.
>
>I run the following code, that results in the following error:
>
>data(Canada)
>
>endoC <- Canada[1:72,1:3]
>exoC <- Canada[1:72,4]
>var.2c <- VAR(endoC, p = 2, season=12,exogen=exoC,type = "const")
>exoC_2 <- as.matrix(Canada[73:84,4])
>
>predict(var.2c, n.ahead = 12,dumvar=exoC_2)
>
>Error:
>
>Error in as.matrix(cycle, nrow = season, ncol = season - 1) :
>unused argument(s) (nrow = 12, ncol = 11)
>
>from what I can guess, the predict.varest function is using
>as.matrix() and
>passing nrow and ncol, as.matrix() does not take those two
>parameters but
>matrix() does.
>
>Does anyone have a suggestion of how to get around it? Is
>there a way I can
>get to the predict.varest() function and alter it myself?
>
>Thanks,
>
>Spencer
>
> [[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.
>
*
Confidentiality Note: The information contained in this mess...{{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.
Re: [R] possible bug in vars package (predict.varest) ???
yes, you can just pulldown the tar.gz file and tar -xvf it and that
will give you many directories one of which will
contain the source. I've done that with the vars package in the past (
bernhard's code is very nice to read ) and I would just send
you the code to predict.varest but I don't think predict was there when
I pulled down the code. I think it's a fairly new function.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of sj
Sent: Thursday, August 30, 2007 5:44 PM
To: r-help
Subject: [R] possible bug in vars package (predict.varest) ???
hello,
I have been trying to use the predict function in the vars package to
forecast from a seasonal VAR model. The following code sample
illustrates what I am trying to do and the error that I get when trying
to do it.
I run the following code, that results in the following error:
data(Canada)
endoC <- Canada[1:72,1:3]
exoC <- Canada[1:72,4]
var.2c <- VAR(endoC, p = 2, season=12,exogen=exoC,type = "const")
exoC_2 <- as.matrix(Canada[73:84,4])
predict(var.2c, n.ahead = 12,dumvar=exoC_2)
Error:
Error in as.matrix(cycle, nrow = season, ncol = season - 1) :
unused argument(s) (nrow = 12, ncol = 11)
from what I can guess, the predict.varest function is using as.matrix()
and passing nrow and ncol, as.matrix() does not take those two
parameters but
matrix() does.
Does anyone have a suggestion of how to get around it? Is there a way I
can get to the predict.varest() function and alter it myself?
Thanks,
Spencer
[[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.
This is not an offer (or solicitation of an offer) to buy/se...{{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] possible bug in vars package (predict.varest) ???
hello, I have been trying to use the predict function in the vars package to forecast from a seasonal VAR model. The following code sample illustrates what I am trying to do and the error that I get when trying to do it. I run the following code, that results in the following error: data(Canada) endoC <- Canada[1:72,1:3] exoC <- Canada[1:72,4] var.2c <- VAR(endoC, p = 2, season=12,exogen=exoC,type = "const") exoC_2 <- as.matrix(Canada[73:84,4]) predict(var.2c, n.ahead = 12,dumvar=exoC_2) Error: Error in as.matrix(cycle, nrow = season, ncol = season - 1) : unused argument(s) (nrow = 12, ncol = 11) from what I can guess, the predict.varest function is using as.matrix() and passing nrow and ncol, as.matrix() does not take those two parameters but matrix() does. Does anyone have a suggestion of how to get around it? Is there a way I can get to the predict.varest() function and alter it myself? Thanks, Spencer [[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] possible bug in ggplot2 v0.5.2???
On 7/6/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Wed, 4 Jul 2007, hadley wickham wrote: > > > On 7/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > >> On Tue, 3 Jul 2007, hadley wickham wrote: > >> > >> > Hi Stephane, > >> > > >> > The problem is that the windows graphics device doesn't support > >> > transparent colours. You can get around this in two ways: > >> > >> It certainly does! Try col="transparent" (and perhaps consult your > >> dictionary). It was news to me that the windows() graphics device worked > >> on > >> Linux i586. > > > > Well my dictionary defines transparent as "allowing light to pass > > through so that objects behind can be distinctly seen" which I believe > > applies here (ie. stained glass windows and blue points with alpha 0.5 > > are both transparent). What does your dictionary say? > > Not quite the same, but even by your definition col="transparent" is > transparent. In this context > > http://en.wikipedia.org/wiki/Transparency_%28graphic%29 > > seems more pertinent. col="transparent" is transparent by any reasonable definition, but does it make sense to claim that a graphics device "supports" transparency? How can you tell the difference between a transparent object and nothing? > >> What it does not support as yet is translucent colours, and that is a > >> restriction imposed by Windows (translucency support was introduced for > >> Windows XP, and we still try to support older versions of Windows, unlike > >> the MacOS people). I have been working on a workaround, so translucency > >> support is likely to be implemented in R 2.6.0 for users of XP or later. > > > > I am confused by your implication that windows (prior to XP) does not > > support translucency. Perhaps it is not supported at the operating > > system level, but it has certainly been available at the application > > level for a very long time. > > Really? It's hard to reply to unspecific assertions. But remember XP has > been out since 2001, almost as long as PDF has supported translucency. Yes, I agree, and thank you for providing some support to your statements. Java has supported transparency since 1.2 (with the Graphics2D class), and was released on Dec 4, 1998, so certainly some applications were drawing transparent graphics on windows. > >> Given that neither of the two main screen devices and neither of the > >> standard print devices support translucency, the subject line looks > >> correct to me: the problem surely lies in the assumptions made in ggplot2. > > > > The features of the windows and X11 devices clearly lag behind the > > quartz and pdf devices. I can program for the lowest common > > denominator or I can use modern features that support the tasks I am > > working on. I choose the later, and it is certainly your prerogative > > to declare that a bug in me. > > I think to make undocumented assumptions about the environment is unkind > to your would-be users. Ideally the graphics devices would detect and I have tried to point that out in most places where I used alpha-blending in the documentation, but I did miss a few. I think part of my job is to educate users about what is possible with R, even though it might be currently available for their default set up. > report that, but that is not how support for semi-transparency was added. > As a by-product of adding limited translucency support on the windows() > family of devices, they do now warn. That's great news. > You also need to check that the extra features work correctly. I found > some problems with all the devices I tried that support translucency (or > at least with device+viewer combinations for pdf and svg). Issues include > whether translucent fills are rendered at all, blending translucent > colours with transparent backgrounds, and the model used (is it the light > intensity or the perceptual colours that are being blended?). Could you provide more details about these bugs so that I can look into the implications for my code? I haven't seen any problems with preview or acrobat on the mac. Regards, 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] possible bug in ggplot2 v0.5.2???
On Wed, 4 Jul 2007, hadley wickham wrote: > On 7/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: >> On Tue, 3 Jul 2007, hadley wickham wrote: >> >> > Hi Stephane, >> > >> > The problem is that the windows graphics device doesn't support >> > transparent colours. You can get around this in two ways: >> >> It certainly does! Try col="transparent" (and perhaps consult your >> dictionary). It was news to me that the windows() graphics device worked >> on >> Linux i586. > > Well my dictionary defines transparent as "allowing light to pass > through so that objects behind can be distinctly seen" which I believe > applies here (ie. stained glass windows and blue points with alpha 0.5 > are both transparent). What does your dictionary say? Not quite the same, but even by your definition col="transparent" is transparent. In this context http://en.wikipedia.org/wiki/Transparency_%28graphic%29 seems more pertinent. >> What it does not support as yet is translucent colours, and that is a >> restriction imposed by Windows (translucency support was introduced for >> Windows XP, and we still try to support older versions of Windows, unlike >> the MacOS people). I have been working on a workaround, so translucency >> support is likely to be implemented in R 2.6.0 for users of XP or later. > > I am confused by your implication that windows (prior to XP) does not > support translucency. Perhaps it is not supported at the operating > system level, but it has certainly been available at the application > level for a very long time. Really? It's hard to reply to unspecific assertions. But remember XP has been out since 2001, almost as long as PDF has supported translucency. One possibility is that you are talking about game-type applications, which have had alpha-blending for a long time via DirectX. However, that was an add-on for a long time, is a function of the graphics card and is normally done on the GPU. The standard Windows way of plotting is GDI, which is a vector painting language like postscript. Like postscript, it also supports bitmaps but using them loses a lot of the flexibility. Alpha blending of bitmaps was added for Windows 98, 2000 and later, but not for all devices: in particular not for metafiles and optionally for printers (and none of the printer drivers I have support it). GDI+ (introduced with XP) adds translucency, but how widely it is supported is unclear to me. For example, Cairo internally uses alpha-blending of bitmaps, but excludes Windows 98 as too buggy. I've chosen to support Win2000 and later in windows(). >> Given that neither of the two main screen devices and neither of the >> standard print devices support translucency, the subject line looks >> correct to me: the problem surely lies in the assumptions made in ggplot2. > > The features of the windows and X11 devices clearly lag behind the > quartz and pdf devices. I can program for the lowest common > denominator or I can use modern features that support the tasks I am > working on. I choose the later, and it is certainly your prerogative > to declare that a bug in me. I think to make undocumented assumptions about the environment is unkind to your would-be users. Ideally the graphics devices would detect and report that, but that is not how support for semi-transparency was added. As a by-product of adding limited translucency support on the windows() family of devices, they do now warn. You also need to check that the extra features work correctly. I found some problems with all the devices I tried that support translucency (or at least with device+viewer combinations for pdf and svg). Issues include whether translucent fills are rendered at all, blending translucent colours with transparent backgrounds, and the model used (is it the light intensity or the perceptual colours that are being blended?). -- 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] possible bug in ggplot2 v0.5.2???
On 7/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Tue, 3 Jul 2007, hadley wickham wrote: > > > Hi Stephane, > > > > The problem is that the windows graphics device doesn't support > > transparent colours. You can get around this in two ways: > > It certainly does! Try col="transparent" (and perhaps consult your > dictionary). It was news to me that the windows() graphics device worked > on > Linux i586. Well my dictionary defines transparent as "allowing light to pass through so that objects behind can be distinctly seen" which I believe applies here (ie. stained glass windows and blue points with alpha 0.5 are both transparent). What does your dictionary say? > What it does not support as yet is translucent colours, and that is a > restriction imposed by Windows (translucency support was introduced for > Windows XP, and we still try to support older versions of Windows, unlike > the MacOS people). I have been working on a workaround, so translucency > support is likely to be implemented in R 2.6.0 for users of XP or later. I am confused by your implication that windows (prior to XP) does not support translucency. Perhaps it is not supported at the operating system level, but it has certainly been available at the application level for a very long time. > Given that neither of the two main screen devices and neither of the > standard print devices support translucency, the subject line looks > correct to me: the problem surely lies in the assumptions made in ggplot2. The features of the windows and X11 devices clearly lag behind the quartz and pdf devices. I can program for the lowest common denominator or I can use modern features that support the tasks I am working on. I choose the later, and it is certainly your prerogative to declare that a bug in me. 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] possible bug in ggplot2 v0.5.2???
On Tue, 3 Jul 2007, hadley wickham wrote: > Hi Stephane, > > The problem is that the windows graphics device doesn't support > transparent colours. You can get around this in two ways: It certainly does! Try col="transparent" (and perhaps consult your dictionary). It was news to me that the windows() graphics device worked on Linux i586. What it does not support as yet is translucent colours, and that is a restriction imposed by Windows (translucency support was introduced for Windows XP, and we still try to support older versions of Windows, unlike the MacOS people). I have been working on a workaround, so translucency support is likely to be implemented in R 2.6.0 for users of XP or later. Given that neither of the two main screen devices and neither of the standard print devices support translucency, the subject line looks correct to me: the problem surely lies in the assumptions made in ggplot2. > * export to a device that does support transparency (eg. pdf) > * use a solid fill colour : + stat_smooth(method="lm", fill="grey50") > > Hadley > > On 7/3/07, Stephane Cruveiller <[EMAIL PROTECTED]> wrote: >> Dear R-Users, >> >> I recently gave a try to the nice package ggplot2. Everything went >> well until I tried to add a smoother (using lm method for instance). >> On the graphic device the regression line is displayed but not confidence >> intervals as it should be (at least on ggplot website). I tried to do >> the job on >> both MS winXP and Linux i586: same result. Did anyone encountered this >> problem? Did I miss something? >> >> >> My R version is 2.4.1. -- 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] possible bug in ggplot2 v0.5.2???
Hi Stephane, The problem is that the windows graphics device doesn't support transparent colours. You can get around this in two ways: * export to a device that does support transparency (eg. pdf) * use a solid fill colour : + stat_smooth(method="lm", fill="grey50") Hadley On 7/3/07, Stephane Cruveiller <[EMAIL PROTECTED]> wrote: > Dear R-Users, > > I recently gave a try to the nice package ggplot2. Everything went > well until I tried to add a smoother (using lm method for instance). > On the graphic device the regression line is displayed but not confidence > intervals as it should be (at least on ggplot website). I tried to do > the job on > both MS winXP and Linux i586: same result. Did anyone encountered this > problem? Did I miss something? > > > My R version is 2.4.1. > > > > Thanks, > > Stéphane. > > > -- > == > Stephane CRUVEILLER Ph. D. > Genoscope - Centre National de Sequencage > Atelier de Genomique Comparative > 2, Rue Gaston Cremieux CP 5706 > 91057 Evry Cedex - France > Phone: +33 (0)1 60 87 84 58 > Fax: +33 (0)1 60 87 25 14 > EMails: [EMAIL PROTECTED] ,[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-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] possible bug in ggplot2 v0.5.2???
Dear R-Users, I recently gave a try to the nice package ggplot2. Everything went well until I tried to add a smoother (using lm method for instance). On the graphic device the regression line is displayed but not confidence intervals as it should be (at least on ggplot website). I tried to do the job on both MS winXP and Linux i586: same result. Did anyone encountered this problem? Did I miss something? My R version is 2.4.1. Thanks, Stéphane. -- == Stephane CRUVEILLER Ph. D. Genoscope - Centre National de Sequencage Atelier de Genomique Comparative 2, Rue Gaston Cremieux CP 5706 91057 Evry Cedex - France Phone: +33 (0)1 60 87 84 58 Fax: +33 (0)1 60 87 25 14 EMails: [EMAIL PROTECTED] ,[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] possible bug in xYplot and smean.cl.normal
I'm using R (2.4.1) and Hmisc (3.3-1), and I'd like to plot confidence
intervals using xYplot and smean.cl.normal (or smean.cl.boot) from Hmisc.
You can do that using the summarize() to produce a new data.frame and then
plot with xYplot, or by specifying method=smean.cl.normal in the xYplot.
Both produce very similar graphs in all trivial examples I've tried, but not
in the attached dataset, where the "method=smean.cl.normal in the xYplot"
produces much smaller Cis! This happens only with smean.cl.boot and
smean.cl.normal, but not with quantile!
Please help
###
##
## plot CIs : compare summarize and xYplot(method= fun)
##
# this is a part of a larger set, but the issue is the same
dat.fss <- read.csv("JMF2_141-dbdemo-FSS-FSS.csv")
summary(dat.fss$Colony_Cnt)
# fix factors
dat.fss$WellCol <- ordered(dat.fss$WellCol)
# define common scale for the y
ylim1 <- c(0,600)
require(Hmisc)
#
# smean.cl.normal
#
conf.int.1 <- 0.95
attach(dat.fss)
ci <- summarize(Colony_Cnt, llist(WellRow, WellCol, WellName, Treatment,
Scan), smean.cl.normal, conf.int=conf.int.1, na.rm=T)
detach("dat.fss")
# using summarize
xYplot(Cbind(Colony_Cnt, Lower, Upper) ~ Scan | WellCol * WellRow, groups=
Treatment, data= ci,
cex=0.1, lwd=2, lty.bands=rep("solid", 2), col.bands=rep("black",
2), lwd.bands=rep(1,2),
method="bands", type="l", ylim= ylim1, na.rm=T
)
# using method=
xYplot(Colony_Cnt ~ Scan | WellCol * WellRow , groups= Treatment, data=
dat.fss,
cex=0.1, lwd=2, lty.bands=rep("solid", 2), col.bands=rep("black",
2), lwd.bands=rep(1,2),
method= smean.cl.normal, methodArgs= list(conf.int=conf.int.1),
type="l", ylim= ylim1, na.rm=T
)
# VERY different CIs
#
# quantile
#
attach(dat.fss)
probs1 <- c(0.5, 0.25, 0.75)
ci <- summarize(Colony_Cnt, llist(WellRow, WellCol, WellName, Treatment,
Scan), quantile, probs= probs1, na.rm=T)
detach("dat.fss")
n1 <- length(colnames(ci))
colnames(ci)[(n1-1):n1] <- c("Lower", "Upper") # rename cols to match
# using summarize
xYplot(Cbind(Colony_Cnt, Lower, Upper) ~ Scan | WellCol * WellRow, groups=
Treatment, data= ci,
cex=0.1, lwd=2, lty.bands=rep("solid", 2), col.bands=rep("black",
2), lwd.bands=rep(1,2),
method="bands", type="l", ylim= ylim1, na.rm=T
)
# using method=
xYplot(Colony_Cnt ~ Scan | WellCol * WellRow , groups= Treatment, data=
dat.fss,
cex=0.1, lwd=2, lty.bands=rep("solid", 2), col.bands=rep("black",
2), lwd.bands=rep(1,2),
method= "quantile", methodArgs= list(probs= probs1),
type="l", ylim= ylim1, na.rm=T
)
# VERY close with quantile
###
__
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] Possible bug?
On Thursday 05 October 2006 00:14, ronggui wrote: > Yes, the installer missed some file(s) in RHOME/bin. > When I choose "Message translations", the /bin directory contains the > following files. > -- snip -- I meant to mention that when I used the installer I didn't have to choose "Message translations", it was ticked by default. HTH, Ray Brownrigg __ 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] Possible bug?
On 10/4/2006 7:14 AM, ronggui wrote: > Yes, the installer missed some file(s) in RHOME/bin. > When I choose "Message translations", the /bin directory contains the > following files. > > R.dll > R.exe > RSetReg.exe > Rblas.dll > Rcmd.exe > Rgui.exe > Rlapack.dll > Rproxy.dll > Rterm.exe > Stangle.sh > Sweave.sh > helpPRINT.bat > md5check.exe > > When I install without choosing "Message translations", the /bin directory > contains the following files. > > INSTALL > R.dll > R.exe > REMOVE > RSetReg.exe > Rblas.dll > Rcmd.exe > Rd2dvi.sh > Rd2txt > Rdconv > Rdiff.sh > Rgui.exe > Rlapack.dll > Rprof > Rproxy.dll > Rterm.exe > SHLIB > Sd2Rd > Stangle.sh > Sweave.sh > build > check > helpPRINT.bat > massage-Examples > md5check.exe That makes it look as though the installer aborted partway through. Could you try to re-install, but run with the command line option "/LOG"? This will create a log file in your TEMP directory (pointed to by your TEMP environment variable, or perhaps in Local Settings/Temp in your Windows home directory), named something like Setup Log 2006-10-04 #001.txt It might give some hint as to what went wrong, e.g. some file was in use and couldn't be replaced, etc. Duncan Murdoch > > > > On 10/4/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On 10/4/2006 12:02 AM, Ray Brownrigg wrote: >>> On Wednesday 04 October 2006 14:17, Duncan Murdoch wrote: 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. Did you test any of the betas or release candidates? I run an English language version of Windows, and I don't even get offered the chance to install in Simplified Chinese, so I certainly didn't test this. Duncan Murdoch 7*runif(1) >>> [1] 2.897160 >>> >>> Well, I have a (self compiled) R-2.4.0 beta (2006-09-24 r39497) which >> doesn't >>> exhibit the behaviour in the same environment (Windows XP Professional >>> English version but with Simplified Chinese set as the locale) that the >>> released R-2.4.0-win32.exe does. [Perhaps my version didn't set up the >>> equivalent of "Message translations" so this may be a red herring, but >> it >>> does output the startup message in Chinese, and error messages are also >>> output in Chinese.] >>> >>> What happens with the release version is an error message: >>> "R for Windows GUI front-end has encountered a problem and needs to >> close. We >>> are sorry for the inconvenience." Then it offers to "Please tell >> Microsoft >>> about the problem", and if you "click here" the error signature has: >>> AppName: rgui.exe AppVer: 2.40.39566.0ModName: r.dll >>> ModVer: 2.40.39566.0 Offset: 000f22b3 >>> >>> There is a lot more information as well, but I don't know how much is >>> relevant. >>> >>> By "Simplified Chinese set as the locale" I mean 'Control Panel/Regional >> and >>> Language Options' with Chinese (PRC) set in 'Regional Options/Standards >> and >>> Formats' and 'Advanced/Language for non-Unicode Programs'. >>> >>> [I don't rely on the Chinese environment, so this doesn't materially >> affect >>> me, but I may be able to help with diagnosis.] >> Could you take a look in RHOME/modules at the file iconv.dll? We >> upgraded it to version 1.11.0.0 relatively late in the cycle; it's >> possible that your successful install uses a different version. (The >> version should be available in the popup if you hover the mouse over it, >> or in the properties if you right click it.) >> >> If that's not it, then I'd guess the problem is that the installer >> missed some file(s); could you compare the installed file lists from the >> beta and the release, and send me a list of files that occur only in the >> beta? It's normal for that list to be fairly long, because when you >> build yourself a lot of unnecessary files are left behind. >> >> 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.
Re: [R] Possible bug?
Yes, the installer missed some file(s) in RHOME/bin. When I choose "Message translations", the /bin directory contains the following files. R.dll R.exe RSetReg.exe Rblas.dll Rcmd.exe Rgui.exe Rlapack.dll Rproxy.dll Rterm.exe Stangle.sh Sweave.sh helpPRINT.bat md5check.exe When I install without choosing "Message translations", the /bin directory contains the following files. INSTALL R.dll R.exe REMOVE RSetReg.exe Rblas.dll Rcmd.exe Rd2dvi.sh Rd2txt Rdconv Rdiff.sh Rgui.exe Rlapack.dll Rprof Rproxy.dll Rterm.exe SHLIB Sd2Rd Stangle.sh Sweave.sh build check helpPRINT.bat massage-Examples md5check.exe On 10/4/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > On 10/4/2006 12:02 AM, Ray Brownrigg wrote: > > On Wednesday 04 October 2006 14:17, Duncan Murdoch wrote: > >> 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. > >> Did you test any of the betas or release candidates? I run an English > >> language version of Windows, and I don't even get offered the chance to > >> install in Simplified Chinese, so I certainly didn't test this. > >> > >> Duncan Murdoch > >> > > > >> 7*runif(1) > > [1] 2.897160 > > > > Well, I have a (self compiled) R-2.4.0 beta (2006-09-24 r39497) which > doesn't > > exhibit the behaviour in the same environment (Windows XP Professional > > English version but with Simplified Chinese set as the locale) that the > > released R-2.4.0-win32.exe does. [Perhaps my version didn't set up the > > equivalent of "Message translations" so this may be a red herring, but > it > > does output the startup message in Chinese, and error messages are also > > output in Chinese.] > > > > What happens with the release version is an error message: > > "R for Windows GUI front-end has encountered a problem and needs to > close. We > > are sorry for the inconvenience." Then it offers to "Please tell > Microsoft > > about the problem", and if you "click here" the error signature has: > > AppName: rgui.exe AppVer: 2.40.39566.0ModName: r.dll > > ModVer: 2.40.39566.0 Offset: 000f22b3 > > > > There is a lot more information as well, but I don't know how much is > > relevant. > > > > By "Simplified Chinese set as the locale" I mean 'Control Panel/Regional > and > > Language Options' with Chinese (PRC) set in 'Regional Options/Standards > and > > Formats' and 'Advanced/Language for non-Unicode Programs'. > > > > [I don't rely on the Chinese environment, so this doesn't materially > affect > > me, but I may be able to help with diagnosis.] > > Could you take a look in RHOME/modules at the file iconv.dll? We > upgraded it to version 1.11.0.0 relatively late in the cycle; it's > possible that your successful install uses a different version. (The > version should be available in the popup if you hover the mouse over it, > or in the properties if you right click it.) > > If that's not it, then I'd guess the problem is that the installer > missed some file(s); could you compare the installed file lists from the > beta and the release, and send me a list of files that occur only in the > beta? It's normal for that list to be fairly long, because when you > build yourself a lot of unnecessary files are left behind. > > Duncan Murdoch > -- »ÆÈÙ¹ó Department of Sociology Fudan University [[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] Possible bug?
On 10/4/2006 12:02 AM, Ray Brownrigg wrote: > On Wednesday 04 October 2006 14:17, Duncan Murdoch wrote: >> 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. >> Did you test any of the betas or release candidates? I run an English >> language version of Windows, and I don't even get offered the chance to >> install in Simplified Chinese, so I certainly didn't test this. >> >> Duncan Murdoch >> > >> 7*runif(1) > [1] 2.897160 > > Well, I have a (self compiled) R-2.4.0 beta (2006-09-24 r39497) which doesn't > exhibit the behaviour in the same environment (Windows XP Professional > English version but with Simplified Chinese set as the locale) that the > released R-2.4.0-win32.exe does. [Perhaps my version didn't set up the > equivalent of "Message translations" so this may be a red herring, but it > does output the startup message in Chinese, and error messages are also > output in Chinese.] > > What happens with the release version is an error message: > "R for Windows GUI front-end has encountered a problem and needs to close. > We > are sorry for the inconvenience." Then it offers to "Please tell Microsoft > about the problem", and if you "click here" the error signature has: > AppName: rgui.exe AppVer: 2.40.39566.0ModName: r.dll > ModVer: 2.40.39566.0 Offset: 000f22b3 > > There is a lot more information as well, but I don't know how much is > relevant. > > By "Simplified Chinese set as the locale" I mean 'Control Panel/Regional and > Language Options' with Chinese (PRC) set in 'Regional Options/Standards and > Formats' and 'Advanced/Language for non-Unicode Programs'. > > [I don't rely on the Chinese environment, so this doesn't materially affect > me, but I may be able to help with diagnosis.] Could you take a look in RHOME/modules at the file iconv.dll? We upgraded it to version 1.11.0.0 relatively late in the cycle; it's possible that your successful install uses a different version. (The version should be available in the popup if you hover the mouse over it, or in the properties if you right click it.) If that's not it, then I'd guess the problem is that the installer missed some file(s); could you compare the installed file lists from the beta and the release, and send me a list of files that occur only in the beta? It's normal for that list to be fairly long, because when you build yourself a lot of unnecessary files are left behind. 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.
Re: [R] Possible bug?
On Wednesday 04 October 2006 14:17, Duncan Murdoch wrote: > 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. > > Did you test any of the betas or release candidates? I run an English > language version of Windows, and I don't even get offered the chance to > install in Simplified Chinese, so I certainly didn't test this. > > Duncan Murdoch > > 7*runif(1) [1] 2.897160 Well, I have a (self compiled) R-2.4.0 beta (2006-09-24 r39497) which doesn't exhibit the behaviour in the same environment (Windows XP Professional English version but with Simplified Chinese set as the locale) that the released R-2.4.0-win32.exe does. [Perhaps my version didn't set up the equivalent of "Message translations" so this may be a red herring, but it does output the startup message in Chinese, and error messages are also output in Chinese.] What happens with the release version is an error message: "R for Windows GUI front-end has encountered a problem and needs to close. We are sorry for the inconvenience." Then it offers to "Please tell Microsoft about the problem", and if you "click here" the error signature has: AppName: rgui.exe AppVer: 2.40.39566.0ModName: r.dll ModVer: 2.40.39566.0Offset: 000f22b3 There is a lot more information as well, but I don't know how much is relevant. By "Simplified Chinese set as the locale" I mean 'Control Panel/Regional and Language Options' with Chinese (PRC) set in 'Regional Options/Standards and Formats' and 'Advanced/Language for non-Unicode Programs'. [I don't rely on the Chinese environment, so this doesn't materially affect me, but I may be able to help with diagnosis.] Hope this helps, Ray Brownrigg __ 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] Possible bug?
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. Did you test any of the betas or release candidates? I run an English language version of Windows, and I don't even get offered the chance to install in Simplified Chinese, so I certainly didn't test this. 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] Possible bug?
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) -- »ÆÈÙ¹ó Department of Sociology Fudan University [[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] possible bug in image() ??
I guess what you see is the limited resolution of your screen rather
than a bug in R.
Try to produce a reliably image, e.g. some pdf file:
pdf("test.pdf")
cc=runif(n=1500,min=0.1,max=1.2)
ccc=ceiling(cc-1)
dd=runif(n=1500,min=0.1,max=1.2)
ddd=ceiling(dd-1)
ee=runif(n=1500,min=0.1,max=1.2)
eee=ceiling(ee-1)
x=matrix(data=c(ccc,ddd,eee),nrow=1500)
image(x)
points(seq(0,1,1/(1500-1)),(ccc)^-1*0, pch=".")
points(seq(0,1,1/(1500-1)),(ddd)^-1*0.5, pch=".")
points(seq(0,1,1/(1500-1)),(eee)^-1*1, pch=".")
dev.off()
and zoom in now
Uwe Ligges
Gareth Davies wrote:
> Hi everyone.
> The function image() seems not to be correctly plotting some
> matrices that I give it. (I’m using R 2.1.1)
> The following code creates a matrix (denoted x) with 1500
> rows and 3 columns, with all entries 0 or 1, and then plots
> the image of this matrix.
>
> cc=runif(n=1500,min=0.1,max=1.2)
> ccc=ceiling(cc-1)
> dd=runif(n=1500,min=0.1,max=1.2)
> ddd=ceiling(dd-1)
> ee=runif(n=1500,min=0.1,max=1.2)
> eee=ceiling(ee-1)
> x=matrix(data=c(ccc,ddd,eee),nrow=1500)
> image(x)
>
> ..where the first column in x (vector ccc) is depicted
> horizontally along the bottom of the image. However, when I
> overplot the non-zero elements of the vectors ccc, ddd and
> eee onto their respective horizontal positions on the
> image,..
>
> points(seq(0,1,1/(1500-1)),(ccc)^-1*0)
> points(seq(0,1,1/(1500-1)),(ddd)^-1*0.5)
> points(seq(0,1,1/(1500-1)),(eee)^-1*1)
>
>
> …the locations of the 1’s in image do not always match the
> locations of the 1’s in ccc,ddd, and eee (although they are
> mostly correct). Do other people find this problem?? I've
> tried with other matrices, and the results only seem in
> error when the matrix is large, say with more than 1000
> rows.
>
> Cheers, Gareth Davies
>
> __
> 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] possible bug in image() ??
Gareth Davies a écrit :
> Hi everyone.
> The function image() seems not to be correctly plotting some
> matrices that I give it. (I’m using R 2.1.1)
> ..where the first column in x (vector ccc) is depicted
> horizontally along the bottom of the image.
Hello,
here's a way to have an image according the usual view.
timage = function(M)
{
M1 = M;
for (i in 1:nrow(M)) M1[i,] = M[nrow(M)-i+1,];
image(t(M1));
}
hih
__
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] possible bug in image() ??
Hi everyone. The function image() seems not to be correctly plotting some matrices that I give it. (I’m using R 2.1.1) The following code creates a matrix (denoted x) with 1500 rows and 3 columns, with all entries 0 or 1, and then plots the image of this matrix. cc=runif(n=1500,min=0.1,max=1.2) ccc=ceiling(cc-1) dd=runif(n=1500,min=0.1,max=1.2) ddd=ceiling(dd-1) ee=runif(n=1500,min=0.1,max=1.2) eee=ceiling(ee-1) x=matrix(data=c(ccc,ddd,eee),nrow=1500) image(x) ..where the first column in x (vector ccc) is depicted horizontally along the bottom of the image. However, when I overplot the non-zero elements of the vectors ccc, ddd and eee onto their respective horizontal positions on the image,.. points(seq(0,1,1/(1500-1)),(ccc)^-1*0) points(seq(0,1,1/(1500-1)),(ddd)^-1*0.5) points(seq(0,1,1/(1500-1)),(eee)^-1*1) …the locations of the 1’s in image do not always match the locations of the 1’s in ccc,ddd, and eee (although they are mostly correct). Do other people find this problem?? I've tried with other matrices, and the results only seem in error when the matrix is large, say with more than 1000 rows. Cheers, Gareth Davies __ 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] Possible bug in lmer nested analysis with factors
On 18 Sep 2005, at 16:27, Douglas Bates wrote: > I have a couple of other comments. You can write the nested grouping > factors as Sundar did without having to explicitly evaluate the > interaction term and drop unused levels. The lmer function, like most > modeling functions in R, uses the optional argument drop.unused.levels > = TRUE when creating the model frame. In other words, the use of "b:c" in a model formula, where both b and c are factors, results in an internal call to evalq(b:c)[,drop=T] (or equivalent), which is treated as a factor in a temporary model data frame? I know little of the internals to R - that is new to me, but does make sense for factors. Thus I could use |a:b and |a:b:c as random terms in lme or lmer, even though 'a' is a fixed, unnested factor. Notation like this in the model formula does indeed aid clarity. By the way, I noticed that in your mlmRev vignette you recommended this as good practice for lea:school (page 3), but then omitted to do it on page 4. > John Maindonald has already suggested the use of > > (1|b/c) => (1|b:c) + (1|b) > > as "syntactic sugar" for the lmer formula and it is a reasonable > request. This is, indeed, the behaviour I was expecting. > Unfortunately, implementing this is not high on my priority > list at present. (We just made a massive change in the sparse matrix > implementation in the Matrix package and shaking the bugs out of that > will take a while.) All your efforts in these areas are, I'm sure, much appreciated. I'm certainly very interested in learning to use lmer, and welcome all the improvements that are being made. > In any case the general recommendation for nested grouping factors is > first to ensure that they are stored as factors and then to create the > sequence of interaction terms. As a brief aside, I know that some people assume that lme treats random effects as factors even if they are of a numeric type. It might be worth doing a check in lmer (and even lme) that random effects are factors, producing a warning if not. Again, this is a non-vital suggestion, and I don't wish to take up any more of your time! Thanks Yan __ 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] Possible bug in lmer nested analysis with factors
On 18 Sep 2005, at 16:04, Douglas Bates wrote: > You are correct that good documentation of the capabilities of lmer > does not currently exist. lmer is still under active development and > documentation is spread in several places. The vignette in the mlmRev > package explores some of the capabilities of lmer. Also see the > examples in that package. Yes. Thanks for this, and indeed for the development of the package. I'm currently trying to do GLMMs (binary response), so I thought that I should learn mixed modelling using a library with these capabilities. > You are correct that the denominator degrees of freedom associated > with terms in the fixed effects is different between lme and lmer. > ... > Some arguments on > degrees of freedom can be made for nested grouping factors but the > question of testing fixed effects terms for models with partially > crossed grouping factors is difficult. Would it not be possible to recognise when the model is fully nested, and make this a special case? I was imagining using lmer as a replacement for lme, so finding that they differ in this way came as some surprise. When learning to use a new, relatively undescribed routine, I usually try to see if I can reproduce known results. This is where I was coming unstuck when trying to reproduce lme results using lmer. I suspect that many people (I know of one other in my group) will use lmer as a drop-in replacement for lme specifically for its GLMM capabilities rather than for its partial nesting. I realise, however, that this might not be your priority. > This area could be a very fruitful research area for people with > strong mathematical and implementation skills. That's not me, I'm afraid. I am only just working through Chapter 1 of your (excellent) "mixed effects models in S" book. > There are already some facilities for lmer models such as mcmcsamp and > simulate which can be used for evaluating the posterior distribution > of a single coefficient or for a parametric bootstrap of the reference > distribution of a quantity like the likelihood ratio statistic for a > hypothesis test. This, again, is beyond me at the moment. But I do hope that someone else can respond to the call, especially for "textbook" as well as more complex examples of lmer usage. Best wishes Yan Wong __ 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] Possible bug in lmer nested analysis with factors
I have a couple of other comments. You can write the nested grouping
factors as Sundar did without having to explicitly evaluate the
interaction term and drop unused levels. The lmer function, like most
modeling functions in R, uses the optional argument drop.unused.levels
= TRUE when creating the model frame.
John Maindonald has already suggested the use of
(1|b/c) => (1|b:c) + (1|b)
as "syntactic sugar" for the lmer formula and it is a reasonable
request. Unfortunately, implementing this is not high on my priority
list at present. (We just made a massive change in the sparse matrix
implementation in the Matrix package and shaking the bugs out of that
will take a while.)
In any case the general recommendation for nested grouping factors is
first to ensure that they are stored as factors and then to create the
sequence of interaction terms.
On 9/18/05, Yan Wong <[EMAIL PROTECTED]> wrote:
>
> On 16 Sep 2005, at 17:21, Sundar Dorai-Raj wrote:
>
> > My guess is he wants this:
> >
> > c1 <- factor(c)
> > d1 <- factor(d)
> > m <- lmer(a ~ b + (1|c1:d1)+(1|c1))
> >
> > which assumes d1 is nested within c1.
> >
> > Take a look at Section 3 in the "MlmSoftRev" vignette:
> >
> > library(mlmRev)
> > vignette("MlmSoftRev")
>
> Ah, that vignette is extremely useful: it deserves to be more widely
> known.
> I mainly intended this reply to be a thank you to yourself and Harold.
>
> Unfortunately, there is (as always), one last thing that is still
> puzzling me:
> the df for fixed factors seems to vary between what I currently
> understand to
> be equivalent calls to lme and lmer, e.g:
>
> ---
>
> a<-rnorm(36);
> b<-factor(rep(1:3,each=12))
> c<-factor(rep(1:2,each=6,3))
> d<-factor(rep(1:3,each=2,6))
> c <- evalq(b:c)[,drop=T] #make unique factor levels
> d <- evalq(c:d)[,drop=T] #make unique factor levels
>
> summary(lme(a ~ b, random=~1|c/d))
> # output includes estimates for fixed effects such as
> #Value Std.Error DFt-value p-value
> # (Intercept) 0.06908901 0.3318330 18 0.2082041 0.8374
> # b2 0.13279084 0.4692828 3 0.2829655 0.7956
> # b3 -0.26146698 0.4692828 3 -0.5571630 0.6163
>
> # I understand the above lme model to be equivalent to
> summary(lmer(a ~ b + (1|c) +(1|c:d))
> #but this gives fixed effects estimates with differing DF:
> # Estimate Std. Error DF t value Pr(>|t|)
> # (Intercept) 0.069089 0.331724 33 0.2083 0.8363
> # b2 0.132791 0.469128 33 0.2831 0.7789
> # b3 -0.261467 0.469128 33 -0.5573 0.5811
>
> Again, many thanks for your help: even more so if you or anyone
> else can answer this last little niggle of mine.
__
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] Possible bug in lmer nested analysis with factors
On 9/18/05, Yan Wong <[EMAIL PROTECTED]> wrote:
>
> On 16 Sep 2005, at 17:21, Sundar Dorai-Raj wrote:
>
> > My guess is he wants this:
> >
> > c1 <- factor(c)
> > d1 <- factor(d)
> > m <- lmer(a ~ b + (1|c1:d1)+(1|c1))
> >
> > which assumes d1 is nested within c1.
> >
> > Take a look at Section 3 in the "MlmSoftRev" vignette:
> >
> > library(mlmRev)
> > vignette("MlmSoftRev")
>
> Ah, that vignette is extremely useful: it deserves to be more widely
> known.
> I mainly intended this reply to be a thank you to yourself and Harold.
>
> Unfortunately, there is (as always), one last thing that is still
> puzzling me:
> the df for fixed factors seems to vary between what I currently
> understand to
> be equivalent calls to lme and lmer, e.g:
>
> ---
>
> a<-rnorm(36);
> b<-factor(rep(1:3,each=12))
> c<-factor(rep(1:2,each=6,3))
> d<-factor(rep(1:3,each=2,6))
> c <- evalq(b:c)[,drop=T] #make unique factor levels
> d <- evalq(c:d)[,drop=T] #make unique factor levels
>
> summary(lme(a ~ b, random=~1|c/d))
> # output includes estimates for fixed effects such as
> #Value Std.Error DFt-value p-value
> # (Intercept) 0.06908901 0.3318330 18 0.2082041 0.8374
> # b2 0.13279084 0.4692828 3 0.2829655 0.7956
> # b3 -0.26146698 0.4692828 3 -0.5571630 0.6163
>
> # I understand the above lme model to be equivalent to
> summary(lmer(a ~ b + (1|c) +(1|c:d))
> #but this gives fixed effects estimates with differing DF:
> # Estimate Std. Error DF t value Pr(>|t|)
> # (Intercept) 0.069089 0.331724 33 0.2083 0.8363
> # b2 0.132791 0.469128 33 0.2831 0.7789
> # b3 -0.261467 0.469128 33 -0.5573 0.5811
>
> Again, many thanks for your help: even more so if you or anyone
> else can answer this last little niggle of mine.
I'm coming to the discussion late and would also like to thank Sundar
and Harold for their explanations.
You are correct that good documentation of the capabilities of lmer
does not currently exist. lmer is still under active development and
documentation is spread in several places. The vignette in the mlmRev
package explores some of the capabilities of lmer. Also see the
examples in that package.
You are correct that the denominator degrees of freedom associated
with terms in the fixed effects is different between lme and lmer.
Neither of them is "right" because there is no correct answer but the
values from lmer are definitely more wrong than the values from lme.
The problem is that lmer allows a wider range of models than does lme.
In lme the grouping factors can only be nested. You can fake crossed
grouping factors but you do need to fake them. Lmer allows nested or
crossed or partially crossed grouping factors. Most of the subtlety
in the design of lmer is to handle the case of partially crossed
grouping factors in large data sets (think of value-added models that
are applied to longitudinal data on students crossed with teachers in
schools within school districts within states ...). Some arguments on
degrees of freedom can be made for nested grouping factors but the
question of testing fixed effects terms for models with partially
crossed grouping factors is difficult. I am aware of the 1997
Biometrics paper by Kenward and Roger but I find it difficult to
translate their formulae into something I can evaluate. Their
representation of a linear mixed model is as a generalized least
squares problem whereas lmer uses a penalized least squares
representation. These are equivalent but sometimes the translations
back and forth are difficult to write down.
This area could be a very fruitful research area for people with
strong mathematical and implementation skills. I have a partially
completed writeup on the details of the lmer representation and
implementation (the description of the linear mixed model is done -
I'm still working on the description of the generalized linear mixed
model and the nonlinear mixed model) which I could forward to anyone
interested in such a challenge. There are two or three approaches
that could be used and I can provide some references. An extensive
comparison of the properties of these approaches across a range of
real problems would be a valuable contribution to the literature but
it would involve a lot of work in implementation.
There are already some facilities for lmer models such as mcmcsamp and
simulate which can be used for evaluating the posterior distribution
of a single coefficient or for a parametric bootstrap of the reference
distribution of a quantity like the likelihood ratio statistic for a
hypothesis test.
__
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] Possible bug in lmer nested analysis with factors
On 16 Sep 2005, at 17:21, Sundar Dorai-Raj wrote:
> My guess is he wants this:
>
> c1 <- factor(c)
> d1 <- factor(d)
> m <- lmer(a ~ b + (1|c1:d1)+(1|c1))
>
> which assumes d1 is nested within c1.
>
> Take a look at Section 3 in the "MlmSoftRev" vignette:
>
> library(mlmRev)
> vignette("MlmSoftRev")
Ah, that vignette is extremely useful: it deserves to be more widely
known.
I mainly intended this reply to be a thank you to yourself and Harold.
Unfortunately, there is (as always), one last thing that is still
puzzling me:
the df for fixed factors seems to vary between what I currently
understand to
be equivalent calls to lme and lmer, e.g:
---
a<-rnorm(36);
b<-factor(rep(1:3,each=12))
c<-factor(rep(1:2,each=6,3))
d<-factor(rep(1:3,each=2,6))
c <- evalq(b:c)[,drop=T] #make unique factor levels
d <- evalq(c:d)[,drop=T] #make unique factor levels
summary(lme(a ~ b, random=~1|c/d))
# output includes estimates for fixed effects such as
#Value Std.Error DFt-value p-value
# (Intercept) 0.06908901 0.3318330 18 0.2082041 0.8374
# b2 0.13279084 0.4692828 3 0.2829655 0.7956
# b3 -0.26146698 0.4692828 3 -0.5571630 0.6163
# I understand the above lme model to be equivalent to
summary(lmer(a ~ b + (1|c) +(1|c:d))
#but this gives fixed effects estimates with differing DF:
# Estimate Std. Error DF t value Pr(>|t|)
# (Intercept) 0.069089 0.331724 33 0.2083 0.8363
# b2 0.132791 0.469128 33 0.2831 0.7789
# b3 -0.261467 0.469128 33 -0.5573 0.5811
Again, many thanks for your help: even more so if you or anyone
else can answer this last little niggle of mine.
Yan
__
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] Possible bug in lmer nested analysis with factors
Doug Bates has the following article in R News. To date, it is the only
source I know of documenting the lmer function.
@Article{Rnews:Bates:2005,
author = {Douglas Bates},
title= {Fitting Linear Mixed Models in {R}},
journal = {R News},
year = 2005,
volume = 5,
number = 1,
pages= {27--30},
month= {May},
url = {http://CRAN.R-project.org/doc/Rnews/},
}
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yan Wong
Sent: Friday, September 16, 2005 1:58 PM
To: R-help
Subject: Re: [R] Possible bug in lmer nested analysis with factors
On 16 Sep 2005, at 17:12, Doran, Harold wrote:
> I think you might have confused lme code with lmer code. Why do you
> have c/d in the random portion?
Apologies. I obviously have done something of the sort. I assumed that
the 'random' assignment in lme could just be incorporated into an lmer
call by placing it in brackets and removing the ~, so that
lme(a ~ b, random= ~ 1|c/d)
would be equivalent to
lmer(a ~ b + (1|c/d))
Is there a good guide somewhere to lmer calling conventions? I obviously
don't understand them. As you can see, I would like to nest d within c,
(and actually, c is nested in b too).
Perhaps it would be better with some explanation of the Crawley data.
There are 3 fixed drug treatments ('b') given to 2 rats (6 rats in
all: 'c'), and 3 samples ('d') are taken from each of the rat's livers,
with some response variable recorded for each sample ('a':
here just allocated a Normal distribution for testing purposes). I.e.
c and d are random effects, with d %in% c and c %in% b.
He analyses it via
aov(a ~ b+c+d+Error(a/b/c))
I'm wondering what the lme and lmer equivalents are. I've been told that
a reasonable form of analysis using lme is
a<-rnorm(36);b<-rep(1:3,each=12);d<-rep(1:3,each=2,6)
c <- rep(1:6, each=6) #use unique labels for each rat ## I got this
wrong in my previous example
model1 <- lme(a ~ b, random= ~ 1|c/d)
Which gives what looks to be a reasonable output (but I'm new to all
this mixed modelling stuff). How would I code the same thing using lmer?
> I think what you want is
>
>> lmer(a ~ b + (1 | c)+(1|d))
>>
>
> Which gives the following using your data
I'm not sure this is what I wanted to do. But thanks for the all the
help.
Yan
__
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] Possible bug in lmer nested analysis with factors
On 16 Sep 2005, at 17:12, Doran, Harold wrote:
> I think you might have confused lme code with lmer code. Why do you
> have
> c/d in the random portion?
Apologies. I obviously have done something of the sort. I assumed
that the 'random' assignment in lme could just be incorporated into
an lmer call by placing it in brackets and removing the ~, so that
lme(a ~ b, random= ~ 1|c/d)
would be equivalent to
lmer(a ~ b + (1|c/d))
Is there a good guide somewhere to lmer calling conventions? I
obviously don't understand them. As you can see, I would like to nest
d within c, (and actually, c is nested in b too).
Perhaps it would be better with some explanation of the Crawley data.
There are 3 fixed drug treatments ('b') given to 2 rats (6 rats in
all: 'c'), and 3 samples ('d') are taken from each of the rat's
livers, with some response variable recorded for each sample ('a':
here just allocated a Normal distribution for testing purposes). I.e.
c and d are random effects, with d %in% c and c %in% b.
He analyses it via
aov(a ~ b+c+d+Error(a/b/c))
I'm wondering what the lme and lmer equivalents are. I've been told
that a reasonable form of analysis using lme is
a<-rnorm(36);b<-rep(1:3,each=12);d<-rep(1:3,each=2,6)
c <- rep(1:6, each=6) #use unique labels for each rat ## I got this
wrong in my previous example
model1 <- lme(a ~ b, random= ~ 1|c/d)
Which gives what looks to be a reasonable output (but I'm new to all
this mixed modelling stuff). How would I code the same thing using lmer?
> I think what you want is
>
>> lmer(a ~ b + (1 | c)+(1|d))
>>
>
> Which gives the following using your data
I'm not sure this is what I wanted to do. But thanks for the all the
help.
Yan
__
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] Possible bug in lmer nested analysis with factors
My guess is he wants this:
c1 <- factor(c)
d1 <- factor(d)
m <- lmer(a ~ b + (1|c1:d1)+(1|c1))
which assumes d1 is nested within c1.
Take a look at Section 3 in the "MlmSoftRev" vignette:
library(mlmRev)
vignette("MlmSoftRev")
HTH,
--sundar
Doran, Harold wrote:
> I think you might have confused lme code with lmer code. Why do you have
> c/d in the random portion?
>
> I think what you want is
>
>
>>lmer(a ~ b + (1 | c)+(1|d))
>
>
> Which gives the following using your data
>
>
> Linear mixed-effects model fit by REML
> Formula: a ~ b + (1 | c) + (1 | d)
> AIC BIClogLik MLdeviance REMLdeviance
> 108.0239 115.9415 -49.01193 94.57296 98.02386
> Random effects:
> Groups NameVariance Std.Dev.
> d(Intercept) 4.2877e-10 2.0707e-05
> c(Intercept) 4.2877e-10 2.0707e-05
> Residual 8.5754e-01 9.2603e-01
> # of obs: 36, groups: d, 3; c, 2
>
> Fixed effects:
> Estimate Std. Error DF t value Pr(>|t|)
> (Intercept) 0.829280.40834 34 2.0309 0.05015 .
> b -0.375630.18903 34 -1.9872 0.05500 .
> ---
> Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Yan Wong
> Sent: Friday, September 16, 2005 11:58 AM
> To: R-help
> Subject: [R] Possible bug in lmer nested analysis with factors
>
> Hello,
>
> Is this a bug in the lmer routine?
>
> > library(lme4)
> > ### test case based on rats data from Crawley >
> a<-rnorm(36);b<-rep(1:3,each=12);c<-rep(1:2,each=6,3);d<-rep
> (1:3,each=2,6)
> >
> > ### mixed model works when c & d are numeric, lmer assumes they are
> factors > m <- lmer(a ~ b + (1|c/d)) > > ### but bails out when they
> are actually specified as factors > c<-factor(c); d<-factor(d) > m <-
> lmer(a ~ b + (1| c / d))
>
> Error in lmer(a ~ b + (1 | c/d)) : entry 0 in matrix[0,0] has row
> 2147483647 and column 2147483647
> In addition: Warning message:
> / not meaningful for factors in: Ops.factor(c, d)
>
>
> Cheers
>
> Yan
>
> __
> 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-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] Possible bug in lmer nested analysis with factors
I think you might have confused lme code with lmer code. Why do you have c/d in the random portion? I think what you want is > lmer(a ~ b + (1 | c)+(1|d)) Which gives the following using your data Linear mixed-effects model fit by REML Formula: a ~ b + (1 | c) + (1 | d) AIC BIClogLik MLdeviance REMLdeviance 108.0239 115.9415 -49.01193 94.57296 98.02386 Random effects: Groups NameVariance Std.Dev. d(Intercept) 4.2877e-10 2.0707e-05 c(Intercept) 4.2877e-10 2.0707e-05 Residual 8.5754e-01 9.2603e-01 # of obs: 36, groups: d, 3; c, 2 Fixed effects: Estimate Std. Error DF t value Pr(>|t|) (Intercept) 0.829280.40834 34 2.0309 0.05015 . b -0.375630.18903 34 -1.9872 0.05500 . --- Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yan Wong Sent: Friday, September 16, 2005 11:58 AM To: R-help Subject: [R] Possible bug in lmer nested analysis with factors Hello, Is this a bug in the lmer routine? > library(lme4) > ### test case based on rats data from Crawley > a<-rnorm(36);b<-rep(1:3,each=12);c<-rep(1:2,each=6,3);d<-rep (1:3,each=2,6) > > ### mixed model works when c & d are numeric, lmer assumes they are factors > m <- lmer(a ~ b + (1|c/d)) > > ### but bails out when they are actually specified as factors > c<-factor(c); d<-factor(d) > m <- lmer(a ~ b + (1| c / d)) Error in lmer(a ~ b + (1 | c/d)) : entry 0 in matrix[0,0] has row 2147483647 and column 2147483647 In addition: Warning message: / not meaningful for factors in: Ops.factor(c, d) Cheers Yan __ 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] Possible bug in lmer nested analysis with factors
On 16 Sep 2005, at 16:57, Yan Wong wrote: > Hello, > > Is this a bug in the lmer routine? > > ... > Error in lmer(a ~ b + (1 | c/d)) : entry 0 in matrix[0,0] has row > 2147483647 and column 2147483647 > In addition: Warning message: > / not meaningful for factors in: Ops.factor(c, d) Sorry, I forgot to specify: R 2.1.1, Mac OS X 10.4.2, lme4 version 0.98-1, Matrix version 0.98-7. Yan __ 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] Possible bug in lmer nested analysis with factors
Hello, Is this a bug in the lmer routine? > library(lme4) > ### test case based on rats data from Crawley > a<-rnorm(36);b<-rep(1:3,each=12);c<-rep(1:2,each=6,3);d<-rep (1:3,each=2,6) > > ### mixed model works when c & d are numeric, lmer assumes they are factors > m <- lmer(a ~ b + (1|c/d)) > > ### but bails out when they are actually specified as factors > c<-factor(c); d<-factor(d) > m <- lmer(a ~ b + (1| c / d)) Error in lmer(a ~ b + (1 | c/d)) : entry 0 in matrix[0,0] has row 2147483647 and column 2147483647 In addition: Warning message: / not meaningful for factors in: Ops.factor(c, d) Cheers Yan __ 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] Possible bug in summary of residuals with lm and weights
On Tue, 28 Jun 2005, Frank E Harrell Jr wrote: > I sent this to r-devel the other day but didn't get any takers. This > may not be a bug but rather an inconsistency. > I'm not sure if this is intentional. summary.lm stores weighted > residuals whereas I think most users will want print.summary.lm to > summarize unweighted ones as if saying summary(resid(fit)). It seems no one agreed with you! I think most users will want S-compatibility here, and after that residuals that are in some sense on the same scale (that is taking the weights into account). In short, the status quo. I suspect no one wants the definition of the "summary.lm" class changed. There is a bug in the print method, which has cat(if (!is.null(x$w) && diff(range(x$w))) "Weighted ", "Residuals:\n", sep = "") so it is intended to say Weighted Residuals, but w is not in a "summary.lm" object. > >> set.seed(1) >> dat <- data.frame(y = rnorm(15), x = rnorm(15), w = 1:15) >> f <- lm(y ~ x, weights = w, data = dat) >> summary(f) > . . . . > Residuals: >Min 1Q Median 3QMax > -8.260 -1.565 0.117 2.105 4.666 > . . . . >> resid(f) > > 1 2 3 4 5 6 > -0.73429677 0.06818092 -1.20558034 1.25783256 0.05231879 -1.18383039 > 7 8 9 10 11 12 > 0.16034166 0.59880438 0.98337588 -0.58944957 1.40690588 0.31138819 > 13 14 15 > -0.35111933 -2.20770335 0.89438636 > >> version > platform i386-pc-linux-gnu > arch i386 > os linux-gnu > system i386, linux-gnu > status > major2 > minor1.0 > year 2005 > month04 > day 18 > language R > > -- > 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 > -- 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
[R] Possible bug in summary of residuals with lm and weights
I sent this to r-devel the other day but didn't get any takers. This may not be a bug but rather an inconsistency. I'm not sure if this is intentional. summary.lm stores weighted residuals whereas I think most users will want print.summary.lm to summarize unweighted ones as if saying summary(resid(fit)). > set.seed(1) > dat <- data.frame(y = rnorm(15), x = rnorm(15), w = 1:15) > f <- lm(y ~ x, weights = w, data = dat) > summary(f) . . . . Residuals: Min 1Q Median 3QMax -8.260 -1.565 0.117 2.105 4.666 . . . . > resid(f) 1 2 3 4 5 6 -0.73429677 0.06818092 -1.20558034 1.25783256 0.05231879 -1.18383039 7 8 9 10 11 12 0.16034166 0.59880438 0.98337588 -0.58944957 1.40690588 0.31138819 13 14 15 -0.35111933 -2.20770335 0.89438636 > version platform i386-pc-linux-gnu arch i386 os linux-gnu system i386, linux-gnu status major2 minor1.0 year 2005 month04 day 18 language R -- 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
Re: [R] possible bug in merge with duplicate blank names in 'by' field.
Thanks for your quick responses, Gabor and Brian. I'm currently running R version 1.9.1 on Linux. Actually, I have just tested this on R v.2.1.0 running under Windows XP, and indeed, as you both indicate, the problem does not exist on that version for that OS. So, at an appropriate time I'll upgrade my Linux installation to the most recent version (1.9.1 is a year old, I guess). -Frank At 03:26 AM 6/17/2005, Prof Brian Ripley wrote: >What version of R is this (please do see the posting guide)? > >In both 2.1.0 and 2.1.1 beta I get > >>all > Promoter ip.x ip.y ip >130 40 40 >240 40 40 >3a 10 NA NA >4c 20 20 20 >5b NA 15 15 >6d NA 30 30 > >so cannot reproduce your result. Are you sure that the `blanks' really are >empty and not some character that is printing as empty on your unstated OS? > >BTW ' ' is what is normally called `blank'. > >BTW, these are not `names' but character strings: `names' has other >meanings in R. PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons __ 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] possible bug in merge with duplicate blank names in 'by' field.
What version of R is this (please do see the posting guide)?
In both 2.1.0 and 2.1.1 beta I get
> all
Promoter ip.x ip.y ip
130 40 40
240 40 40
3a 10 NA NA
4c 20 20 20
5b NA 15 15
6d NA 30 30
so cannot reproduce your result. Are you sure that the `blanks' really are
empty and not some character that is printing as empty on your unstated
OS?
BTW ' ' is what is normally called `blank'.
BTW, these are not `names' but character strings: `names' has other
meanings in R.
On Thu, 16 Jun 2005, Frank Gibbons wrote:
> Run this:
>
>> p <- c('a', 'c', '', ''); a <- c(10, 20, 30, 40); d1 <-
>> data.frame(Promoter=p, ip=a) # Note duplicate empty names in p.
>> p <- c('b', 'c', 'd', ''); a <- c(15, 20, 30, 40); d2 <-
>> data.frame(Promoter=p, ip=a)
>> all <- merge(x=d1, y=d2, by="Promoter", all=T)
>> all <- merge(x=all, y=d2, by="Promoter", all=T)
>> all
>
> Data is this:
>
>> d1
>> Promoter ip
>> 1a 10
>> 2c 20
>> 3 30
>> 4 40
>>
>> d2
>> Promoter ip
>> 1b 15
>> 2c 20
>> 3d 30
>> 4 40
>
> Output looks like this:
>
>> Promoter ip.x ip.y ip
>> 140 30 30
>> 240 40 30
>> 340 30 40
>> 440 40 40
>> 5b 15 NA NA
>> 6c 20 20 20
>> 7d 30 NA NA
>> 8a NA 10 10
>
> The weird thing about this is (in my view) that each instance of '' is
> considered unique, so with each successive merge, all combinatorial
> possibilities are explored, like a SQL outer join (Cartesian product). For
> non-empty names, an inner join is performed.
>
> Dealing with genomic data (10^4 datapoints), it's easy to have a couple of
> blanks buried in the middle of things, and to combine several replicates
> with successive merges. I couldn't understand how my three replicates of
> 6000 points, in which I expected substantial overlap in the labels, were
> taking so long to merge and ultimately generating 57000 labels. The culprit
> turned out to be a few hundred blanks buried in the middle.
>
> Why does the empty ("null") name merit special treatment? Perhaps I'm
> missing something. I hesitate to submit this as a bug, since technically I
> guess you could say that blank names, especially duplicates, are not
> kosher. But on the other hand, this combinatorial behaviour seems to occur
> only for blanks.
>
> -Frank
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
> Tel: 617-432-3555 Fax:
> 617-432-3557 http://llama.med.harvard.edu/~fgibbons
>
> __
> 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
>
--
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] possible bug in merge with duplicate blank names in 'by' field.
What version of R are you using? I don't get the same
result on my system:
> R.version.string # Windows XP
[1] "R version 2.1.0, 2005-06-10"
> p <- c('a', 'c', '', ''); a <- c(10, 20, 30, 40); d1 <-
+ data.frame(Promoter=p, ip=a) # Note duplicate empty names in p.
> p <- c('b', 'c', 'd', ''); a <- c(15, 20, 30, 40); d2 <-
+ data.frame(Promoter=p, ip=a)
> all <- merge(x=d1, y=d2, by="Promoter", all=T)
> all <- merge(x=all, y=d2, by="Promoter", all=T)
> all
Promoter ip.x ip.y ip
130 40 40
240 40 40
3a 10 NA NA
4c 20 20 20
5b NA 15 15
6d NA 30 30
On 6/16/05, Frank Gibbons <[EMAIL PROTECTED]> wrote:
> Run this:
>
> >p <- c('a', 'c', '', ''); a <- c(10, 20, 30, 40); d1 <-
> >data.frame(Promoter=p, ip=a) # Note duplicate empty names in p.
> >p <- c('b', 'c', 'd', ''); a <- c(15, 20, 30, 40); d2 <-
> >data.frame(Promoter=p, ip=a)
> >all <- merge(x=d1, y=d2, by="Promoter", all=T)
> >all <- merge(x=all, y=d2, by="Promoter", all=T)
> >all
>
> Data is this:
>
> >d1
> > Promoter ip
> >1a 10
> >2c 20
> >3 30
> >4 40
> >
> >d2
> > Promoter ip
> >1b 15
> >2c 20
> >3d 30
> >4 40
>
> Output looks like this:
>
> > Promoter ip.x ip.y ip
> >140 30 30
> >240 40 30
> >340 30 40
> >440 40 40
> >5b 15 NA NA
> >6c 20 20 20
> >7d 30 NA NA
> >8a NA 10 10
>
> The weird thing about this is (in my view) that each instance of '' is
> considered unique, so with each successive merge, all combinatorial
> possibilities are explored, like a SQL outer join (Cartesian product). For
> non-empty names, an inner join is performed.
>
> Dealing with genomic data (10^4 datapoints), it's easy to have a couple of
> blanks buried in the middle of things, and to combine several replicates
> with successive merges. I couldn't understand how my three replicates of
> 6000 points, in which I expected substantial overlap in the labels, were
> taking so long to merge and ultimately generating 57000 labels. The culprit
> turned out to be a few hundred blanks buried in the middle.
>
> Why does the empty ("null") name merit special treatment? Perhaps I'm
> missing something. I hesitate to submit this as a bug, since technically I
> guess you could say that blank names, especially duplicates, are not
> kosher. But on the other hand, this combinatorial behaviour seems to occur
> only for blanks.
>
> -Frank
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
> Tel: 617-432-3555 Fax:
> 617-432-3557 http://llama.med.harvard.edu/~fgibbons
>
> __
> 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] possible bug in merge with duplicate blank names in 'by' field.
Run this:
>p <- c('a', 'c', '', ''); a <- c(10, 20, 30, 40); d1 <-
>data.frame(Promoter=p, ip=a) # Note duplicate empty names in p.
>p <- c('b', 'c', 'd', ''); a <- c(15, 20, 30, 40); d2 <-
>data.frame(Promoter=p, ip=a)
>all <- merge(x=d1, y=d2, by="Promoter", all=T)
>all <- merge(x=all, y=d2, by="Promoter", all=T)
>all
Data is this:
>d1
> Promoter ip
>1a 10
>2c 20
>3 30
>4 40
>
>d2
> Promoter ip
>1b 15
>2c 20
>3d 30
>4 40
Output looks like this:
> Promoter ip.x ip.y ip
>140 30 30
>240 40 30
>340 30 40
>440 40 40
>5b 15 NA NA
>6c 20 20 20
>7d 30 NA NA
>8a NA 10 10
The weird thing about this is (in my view) that each instance of '' is
considered unique, so with each successive merge, all combinatorial
possibilities are explored, like a SQL outer join (Cartesian product). For
non-empty names, an inner join is performed.
Dealing with genomic data (10^4 datapoints), it's easy to have a couple of
blanks buried in the middle of things, and to combine several replicates
with successive merges. I couldn't understand how my three replicates of
6000 points, in which I expected substantial overlap in the labels, were
taking so long to merge and ultimately generating 57000 labels. The culprit
turned out to be a few hundred blanks buried in the middle.
Why does the empty ("null") name merit special treatment? Perhaps I'm
missing something. I hesitate to submit this as a bug, since technically I
guess you could say that blank names, especially duplicates, are not
kosher. But on the other hand, this combinatorial behaviour seems to occur
only for blanks.
-Frank
PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555 Fax:
617-432-3557 http://llama.med.harvard.edu/~fgibbons
__
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] Possible bug in file.choose() - how to tell?
On Wed, 15 Jun 2005, Hans-Peter wrote: > 2005/6/15, Prof Brian Ripley <[EMAIL PROTECTED]>: >> OS? R version? Locale? > > Win2000, SP4 - 2.1.0 - > "LC_COLLATE=German_Switzerland.1252; > LC_CTYPE=German_Switzerland.1252; > LC_MONETARY=German_Switzerland.1252; > LC_NUMERIC=C;LC_TIME=German_Switzerland.1252" > >> This is a known problem with R 2.1.0 on Windows in some locales, solved >> long ago in R-patched. > > True. It works perfectly with 2.1.0 patched. Thanks. > >>> PLEASE do read the posting guide! >>> http://www.R-project.org/posting-guide.html >> Yes, that does apply to you! Please do supply the basic information it >> asks for. If you want to allege a bug, so read carefully the section on >> BUGS in the FAQ. > > Ok. - For the next time: could I have found out myself, that this was solved? > (I did search the mail archiv and the r-project website; and also had > a look at the NEWS) That section asks WIndows users to look at the CHANGES file: it is documented there. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-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] Possible bug in file.choose() - how to tell?
2005/6/15, Prof Brian Ripley <[EMAIL PROTECTED]>: > OS? R version? Locale? Win2000, SP4 - 2.1.0 - "LC_COLLATE=German_Switzerland.1252; LC_CTYPE=German_Switzerland.1252; LC_MONETARY=German_Switzerland.1252; LC_NUMERIC=C;LC_TIME=German_Switzerland.1252" > This is a known problem with R 2.1.0 on Windows in some locales, solved > long ago in R-patched. True. It works perfectly with 2.1.0 patched. Thanks. > > PLEASE do read the posting guide! > > http://www.R-project.org/posting-guide.html > Yes, that does apply to you! Please do supply the basic information it > asks for. If you want to allege a bug, so read carefully the section on > BUGS in the FAQ. Ok. - For the next time: could I have found out myself, that this was solved? (I did search the mail archiv and the r-project website; and also had a look at the NEWS) Thanks again and best regards, Hans-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
Re: [R] Possible bug in file.choose() - how to tell?
OS? R version? Locale? This is a known problem with R 2.1.0 on Windows in some locales, solved long ago in R-patched. On Wed, 15 Jun 2005, Hans-Peter wrote: > Hi, > > I run a script file by dropping it on a windows batch file that runs R > in --slave modus. In a subfunction there is the call to file.choose(). > The problem is, that the dialog does show only folders but no files at > all. It's quite strange: a) without --slave modus the files are shown, > b) when I copy the whole script file in a different file it was also > ok, but when I renamed the script, the dialog again only showed folder > names. > > Questions: > - Is it appreciated if I submit a bug report on this issue? How would > I do it and to whom? > - I would like to have a look at the source code. As the prompt gives me: > > file.choose > function (new = FALSE) > .Internal(file.choose(new)) > > I suppose I had to download the source code of the base package and it would > be C code. Is this right? No, it is R code. But internal functions are in C. > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Yes, that does apply to you! Please do supply the basic information it asks for. If you want to allege a bug, so read carefully the section on BUGS in the FAQ. -- 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
[R] Possible bug in file.choose() - how to tell?
Hi, I run a script file by dropping it on a windows batch file that runs R in --slave modus. In a subfunction there is the call to file.choose(). The problem is, that the dialog does show only folders but no files at all. It's quite strange: a) without --slave modus the files are shown, b) when I copy the whole script file in a different file it was also ok, but when I renamed the script, the dialog again only showed folder names. Questions: - Is it appreciated if I submit a bug report on this issue? How would I do it and to whom? - I would like to have a look at the source code. As the prompt gives me: > file.choose function (new = FALSE) .Internal(file.choose(new)) I suppose I had to download the source code of the base package and it would be C code. Is this right? -- Best regards, Hans-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
Re: [R] Possible bug in foreign library import of Stata datasets
On Wed, 28 Apr 2004, Paul Johnson wrote: > > The read.dta has translated the negative values as (256-deml). > > Is this the kind of thing that is a bug, or have I missed something in > the documentation about the handling of negative numbers? Should a > formal bug report be filed? A fixed version of the foreign package has been sent to CRAN. -thomas __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Possible bug in foreign library import of Stata datasets
On Wed, 28 Apr 2004, Peter Dalgaard wrote: > > Looks like a classic signed/unsigned confusion. Negative numbers > stored in ones-complement format in single bytes, but getting > interpreted as unsigned. A bug report could be a good idea if the > resident Stata expert (Thomas, I believe) is unavailable just now. > Yes, it's a simple signed/unsigned bug. We carefully read in the 2-byte and 4-byte types as unsigned int so we can use << and >> to do byte swapping, but of course this doesn't work for the 1-byte type. There's the additional problem that sometimes we want to read an unsigned byte of meta-data. -thomas __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] possible bug in aov?
Two errors of yours are apparent in your example:
1) df is a function, and sample.df is not used in your code. I presume
you actually used data=sample.df.
2) factor2 does not vary within subject so your model makes no sense.
It is the second that leads, correctly, to an error message (if an arcane
one).
On Tue, 2 Mar 2004, Arditi, Aries wrote:
> Hi, I'm interested in doing a repeated measures anova using aov. The procedure is
> nicely described in section 6.7.1, pp. 24-27 of Baron and Li's "Notes on the use of
> R for psychology experiments and
> questionnaires," and I've reproduced their example exactly.
>
> My own problem is almost identical to theirs:
>
> rawdat<-c(1.6530074e+001, 1.2124254e+001, 1.0040371e+001, 1.5317610e+001,
> 1.2332377e+001,
> 1.0102947e+001, 1.7087520e+001, 1.1692890e+001, 1.1809286e+001, 1.4748297e+001,
> 1.0717683e+001,
> 8.7908203e+000, 1.3140706e+001, 9.7947745e+000, 8.3588329e+000, 1.5623756e+001,
> 9.6382132e+000,
> 8.7209537e+000, 1.5321620e+001, 1.1347325e+001, 8.5177789e+000, 1.3271254e+001,
> 9.7376040e+000,
> 8.7803153e+000 , 1.3155236e+001, 1.0157526e+001, 8.4003486e+000, 1.3083896e+001,
> 9.6644615e+000,
> 8.1586026e+000, 1.2167609e+001 , 9.1319943e+000, 7.4251013e+000, 1.3284386e+001,
> 9.1596335e+000,
> 7.9175876e+000, 1.1876537e+002, 7.8831935e+001, 6.2203784e+001, 1.0729023e+002,
> 7.3790904e+001, 5.8588328e+001, 1.1890329e+002, 6.6345430e+001, 5.3117505e+001,
> 3.7261647e+002, 2.4538572e+002, 2.2372152e+002, 3.2602801e+002, 2.3267124e+002,
> 2.0944016e+002, 2.9755054e+002, 2.3970708e+002, 2.2379642e+002)
Where did those e+001 etc come from? Not from R, AFAIK.
> sample.df <- data.frame(dep.variable=rawdat,
> subject=factor(rep(paste("subj",1:6, sep=""),each=9)),
> factor1=factor(rep(rep(c("fac1level1","fac1level2","fac1level3"),each=6),3)),
> factor2=factor(rep(c("fac2level1","fac2level2","fac2level3"),each=18))
> )
> sample.aov <- aov(dep.variable ~ factor1 * factor2 +
> Error(subject/(factor1+factor2)), data=df)
>
> But the aov function returns an error:
>
> Error in "names<-.default"(`*tmp*`, value = nmstrata) :
> names attribute must be the same length as the vector
>
> I am using R1.8.1.
>
> Any help or insight on a workaround would be appreciated.
--
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
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
[R] possible bug in aov?
Hi, I'm interested in doing a repeated measures anova using aov. The procedure is
nicely described in section 6.7.1, pp. 24-27 of Baron and Li's "Notes on the use of R
for psychology experiments and
questionnaires," and I've reproduced their example exactly.
My own problem is almost identical to theirs:
rawdat<-c(1.6530074e+001, 1.2124254e+001, 1.0040371e+001, 1.5317610e+001,
1.2332377e+001,
1.0102947e+001, 1.7087520e+001, 1.1692890e+001, 1.1809286e+001, 1.4748297e+001,
1.0717683e+001,
8.7908203e+000, 1.3140706e+001, 9.7947745e+000, 8.3588329e+000, 1.5623756e+001,
9.6382132e+000,
8.7209537e+000, 1.5321620e+001, 1.1347325e+001, 8.5177789e+000, 1.3271254e+001,
9.7376040e+000,
8.7803153e+000 , 1.3155236e+001, 1.0157526e+001, 8.4003486e+000, 1.3083896e+001,
9.6644615e+000,
8.1586026e+000, 1.2167609e+001 , 9.1319943e+000, 7.4251013e+000, 1.3284386e+001,
9.1596335e+000,
7.9175876e+000, 1.1876537e+002, 7.8831935e+001, 6.2203784e+001, 1.0729023e+002,
7.3790904e+001, 5.8588328e+001, 1.1890329e+002, 6.6345430e+001, 5.3117505e+001,
3.7261647e+002, 2.4538572e+002, 2.2372152e+002, 3.2602801e+002, 2.3267124e+002,
2.0944016e+002, 2.9755054e+002, 2.3970708e+002, 2.2379642e+002)
sample.df <- data.frame(dep.variable=rawdat,
subject=factor(rep(paste("subj",1:6, sep=""),each=9)),
factor1=factor(rep(rep(c("fac1level1","fac1level2","fac1level3"),each=6),3)),
factor2=factor(rep(c("fac2level1","fac2level2","fac2level3"),each=18))
)
sample.aov <- aov(dep.variable ~ factor1 * factor2 + Error(subject/(factor1+factor2)),
data=df)
But the aov function returns an error:
Error in "names<-.default"(`*tmp*`, value = nmstrata) :
names attribute must be the same length as the vector
I am using R1.8.1.
Any help or insight on a workaround would be appreciated.
Aries Arditi
Senior Fellow
Arlene R. Gordon Research Institute
Lighthouse International
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
