[Rd] Typo in x11.Rd
Hi, There is a double "the" in x11.Rd: "...which is faster will depend on the the X11 connection" Thank you, Stephen -- Rochester, Minn. USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] weird behavior of drop1() for polr models (MASS)
Dear Jeroen,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Jeroen Ooms
> Sent: September-30-08 3:10 PM
> To: r-devel@r-project.org
> Subject: Re: [Rd] weird behavior of drop1() for polr models (MASS)
>
>
> Sorry for posting in -dev; I assumed a technical issue. Thanks very much
for
> the responses, I've realized that interaction effects of categorical
> predictors are more complicated than I thought. I've read the contrasts
help
> file and paragraph in the R manual about contrast, however I'm not quite
> sure I fully understand it yet.
>
> I tried Peter's suggestion of fitting "~Infl + Type + Infl:Type" and "Type
+
> Infl:Type", and indeed these result in identical models. For the first
> model, the main effects have 5 parameters and the interaction effect
> contains 6 parameters, for the second model the main effects have 3
> parameters and the interaction has 8 parameters. Do I understand it
> correctly that when the interaction effect is included in the model, R
just
> fits a parameter for every possible combination of the predictor
categories
> minus 1 for the reference group (so 3*4-1 parameters in this case)? And
that
> therefore the attribution of parameters to main or interaction predictors
is
> kind of arbitrary?
>
> I am aware that there are several ways of encoding the contrasts of
> categorical predictors, e.g. contr.sum(4); contr.treatment(4), however I
do
> not understand how the interaction effects are then coded (just products
for
> every combination?), and how this influences the SS type III values, when
it
> does in fact result in the same model.
If by type-III SS, you mean dropping particular columns of the model matrix
and noting the increase in the residual sum of squares, this can indeed be
affected by contrast coding, because when you drop columns corresponding to
a term that's marginal to an included term, the resulting model is not
variant with respect to changes in contrast coding. More fundamentally, the
hypotheses that you're testing can change with the contrasts, and if you're
using a set of contrasts that are not orthogonal in the row basis of the
model matrix, the tests for "main effects" will not test what are reasonably
interpreted as main effects.
>
> And does this same issue then also arise for all other anova models? For
> example, if I fit a normal model in glm (I have done the same thing
numerous
> times in SPSS glm univariate), am I then allowed to interpret the main
> effects SS3 values as genuine main effects? For example:
>
> options(contrasts = c("contr.sum", "contr.poly"));
> mymodel <- glm(Freq~Infl*Type,data=housing);
> drop1(mymodel,attributes(mymodel$terms)$term.labels,test="Chisq");
Why a chi-square test? Why use glm() for a linear model? contr.sum and
contr.poly do indeed create contrasts that are orthogonal in the row basis
of the model matrix, so you could interpret tests of main effects, though
these imply averaging over the levels of the other factor. In the presence
of an interaction, that might not be of much interest. What is the
attraction of "type-III" tests as opposed to "type-II" tests?
These questions are sufficiently complicated that they're hard to address in
an email. They are addressed in Sec. 8.2 and 10.4 of my Applied Regression
text (either edition).
Regards,
John
>
> Thanks again, all comments are very much appreciated!
>
> Jeroen.
>
>
>
>
>
>
>
> John Fox-6 wrote:
> >
> > Dear Jeroen,
> >
> > drop1() respects relationships of marginality among the terms in a model
> > and
> > won't drop a lower-order term (e.g., a main effect) when a higher-order
> > relative (e.g., an interaction to which the main effect is marginal) is
in
> > the model. If you want a complete "type-III" ANOVA table and are careful
> > with contrast coding (which you were not, since contr.treatment produces
> > contrasts that are not orthogonal in the row basis of the model matrix
--
> > you could use, e.g., contr.sum), then you can use the Anova() function
in
> > the car package, specifying type="III".
> >
> > Note: I'm responding to this message on the r-devel list where it was
> > posted, but this is really a question for r-help.
> >
> > I hope this helps,
> > John
> >
> > --
> > John Fox, Professor
> > Department of Sociology
> > McMaster University
> > Hamilton, Ontario, Canada
> > web: socserv.mcmaster.ca/jfox
> >
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED]
> > On
> >> Behalf Of Jeroen Ooms
> >> Sent: September-30-08 9:28 AM
> >> To: r-devel@r-project.org
> >> Subject: [Rd] weird behavior of drop1() for polr models (MASS)
> >>
> >>
> >> I would like to do a SS type III analysis on a proportional odds
logistic
> >> regression model. I use drop1(), but dropterm() shows the same
behaviour.
> > It
> >> works as expected for regular main effects models, however when the
model
> >> includes an interaction effect it se
Re: [Rd] weird behavior of drop1() for polr models (MASS)
Sorry for posting in -dev; I assumed a technical issue. Thanks very much for
the responses, I've realized that interaction effects of categorical
predictors are more complicated than I thought. I've read the contrasts help
file and paragraph in the R manual about contrast, however I'm not quite
sure I fully understand it yet.
I tried Peter's suggestion of fitting "~Infl + Type + Infl:Type" and "Type +
Infl:Type", and indeed these result in identical models. For the first
model, the main effects have 5 parameters and the interaction effect
contains 6 parameters, for the second model the main effects have 3
parameters and the interaction has 8 parameters. Do I understand it
correctly that when the interaction effect is included in the model, R just
fits a parameter for every possible combination of the predictor categories
minus 1 for the reference group (so 3*4-1 parameters in this case)? And that
therefore the attribution of parameters to main or interaction predictors is
kind of arbitrary?
I am aware that there are several ways of encoding the contrasts of
categorical predictors, e.g. contr.sum(4); contr.treatment(4), however I do
not understand how the interaction effects are then coded (just products for
every combination?), and how this influences the SS type III values, when it
does in fact result in the same model.
And does this same issue then also arise for all other anova models? For
example, if I fit a normal model in glm (I have done the same thing numerous
times in SPSS glm univariate), am I then allowed to interpret the main
effects SS3 values as genuine main effects? For example:
options(contrasts = c("contr.sum", "contr.poly"));
mymodel <- glm(Freq~Infl*Type,data=housing);
drop1(mymodel,attributes(mymodel$terms)$term.labels,test="Chisq");
Thanks again, all comments are very much appreciated!
Jeroen.
John Fox-6 wrote:
>
> Dear Jeroen,
>
> drop1() respects relationships of marginality among the terms in a model
> and
> won't drop a lower-order term (e.g., a main effect) when a higher-order
> relative (e.g., an interaction to which the main effect is marginal) is in
> the model. If you want a complete "type-III" ANOVA table and are careful
> with contrast coding (which you were not, since contr.treatment produces
> contrasts that are not orthogonal in the row basis of the model matrix --
> you could use, e.g., contr.sum), then you can use the Anova() function in
> the car package, specifying type="III".
>
> Note: I'm responding to this message on the r-devel list where it was
> posted, but this is really a question for r-help.
>
> I hope this helps,
> John
>
> --
> John Fox, Professor
> Department of Sociology
> McMaster University
> Hamilton, Ontario, Canada
> web: socserv.mcmaster.ca/jfox
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]
> On
>> Behalf Of Jeroen Ooms
>> Sent: September-30-08 9:28 AM
>> To: r-devel@r-project.org
>> Subject: [Rd] weird behavior of drop1() for polr models (MASS)
>>
>>
>> I would like to do a SS type III analysis on a proportional odds logistic
>> regression model. I use drop1(), but dropterm() shows the same behaviour.
> It
>> works as expected for regular main effects models, however when the model
>> includes an interaction effect it seems to have problems with matching
>> the
>> parameters to the predictor terms. An example:
>>
>> library("MASS");
>> options(contrasts = c("contr.treatment", "contr.poly"));
>>
>> house.plr1 <- polr(Sat ~ Infl + Type + Cont, weights = Freq, data =
>> housing);
>> drop1(house.plr1,attributes(house.plr1$terms)$term.labels,test="Chisq");
>>
>> house.plr2 <- polr(Sat ~ Infl * Type + Cont, weights = Freq, data =
>> housing);
>> drop1(house.plr2,attributes(house.plr2$terms)$term.labels,test="Chisq");
>>
>> Notice that model 2 has a * instead of a + between predictors Infl and
> Type.
>> In model 1, estimated parameters are nicely attributed to the right term,
>> however in house.plr2, only 2 of the 4 terms are evaluated.
>>
>> I am using R version 2.7.2 (2008-08-25) i386-pc-mingw32, and MASS_7.2-44.
>>
>> --
>> View this message in context: http://www.nabble.com/weird-behavior-of-
>> drop1%28%29-for-polr-models-%28MASS%29-tp19742120p19742120.html
>> Sent from the R devel mailing list archive at Nabble.com.
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
View this message in context:
http://www.nabble.com/weird-behavior-of-drop1%28%29-for-polr-models-%28MASS%29-tp19742120p19748496.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Planned mailing list "timeout" of several hours
There will be upcoming maintenance work on one of main network's server which will affect the MAIL server for all mailing lists [EMAIL PROTECTED] (or [EMAIL PROTECTED]). This change will take place on Wednesday October 1, from 9 p.m. (UTC+2) 3 p.m. (US East) 12 p.m. (US West) Thursday October 2. 7 a.m. (NZ) 5 a.m. (Oz time east ?) and will last 2 to 6 hours (worst case; expected is 3 hrs). You should not get any e-mails rejected, so go ahead with your postings as normal. The mails should be kept in a secondary/substitute mail server and be forwarded to ours as soon as that "gets up" again. But you will notice that your message is not posted to the lists for several hours. We are sorry for the inconvenience to the R community. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] weird behavior of drop1() for polr models (MASS)
Jeroen Ooms wrote:
> I would like to do a SS type III analysis on a proportional odds logistic
> regression model. I use drop1(), but dropterm() shows the same behaviour. It
> works as expected for regular main effects models, however when the model
> includes an interaction effect it seems to have problems with matching the
> parameters to the predictor terms. An example:
>
> library("MASS");
> options(contrasts = c("contr.treatment", "contr.poly"));
>
> house.plr1 <- polr(Sat ~ Infl + Type + Cont, weights = Freq, data =
> housing);
> drop1(house.plr1,attributes(house.plr1$terms)$term.labels,test="Chisq");
>
> house.plr2 <- polr(Sat ~ Infl * Type + Cont, weights = Freq, data =
> housing);
> drop1(house.plr2,attributes(house.plr2$terms)$term.labels,test="Chisq");
>
> Notice that model 2 has a * instead of a + between predictors Infl and Type.
> In model 1, estimated parameters are nicely attributed to the right term,
> however in house.plr2, only 2 of the 4 terms are evaluated.
>
> I am using R version 2.7.2 (2008-08-25) i386-pc-mingw32, and MASS_7.2-44.
>
(It would have been better form to actually print the result so that
people can see what you're on about:
> drop1(house.plr2,attributes(house.plr2$terms)$term.labels,test="Chisq");
Single term deletions
Model:
Sat ~ Infl * Type + Cont
DfAICLRT Pr(Chi)
3484.6
Infl 0 3484.6 2.086e-08
Type 0 3484.6 -1.301e-10
Cont 1 3497.8 15.1 0.0001009 ***
Infl:Type 6 3495.1 22.5 0.0009786 ***
I take it that the perceived problem is the two 0-Df lines.)
This is slightly peculiar, yes, but notice that in lm() or glm() you'd
normally just not get entries for main effects in the presence of their
interaction. This is deliberate -- type III tests can be seriously
misleading and/or uninterpretable in that case, so you really are better
off without them.
The direct cause of the behaviour above is that in R,
Infl+Type+Infl:Type
and
Type+Infl:Type
are just two parametrizations of the same model. Try
summary(house.plr2)
summary(update(house.plr2,~.-Type))
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] weird behavior of drop1() for polr models (MASS)
Dear Jeroen,
drop1() respects relationships of marginality among the terms in a model and
won't drop a lower-order term (e.g., a main effect) when a higher-order
relative (e.g., an interaction to which the main effect is marginal) is in
the model. If you want a complete "type-III" ANOVA table and are careful
with contrast coding (which you were not, since contr.treatment produces
contrasts that are not orthogonal in the row basis of the model matrix --
you could use, e.g., contr.sum), then you can use the Anova() function in
the car package, specifying type="III".
Note: I'm responding to this message on the r-devel list where it was
posted, but this is really a question for r-help.
I hope this helps,
John
--
John Fox, Professor
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Jeroen Ooms
> Sent: September-30-08 9:28 AM
> To: r-devel@r-project.org
> Subject: [Rd] weird behavior of drop1() for polr models (MASS)
>
>
> I would like to do a SS type III analysis on a proportional odds logistic
> regression model. I use drop1(), but dropterm() shows the same behaviour.
It
> works as expected for regular main effects models, however when the model
> includes an interaction effect it seems to have problems with matching the
> parameters to the predictor terms. An example:
>
> library("MASS");
> options(contrasts = c("contr.treatment", "contr.poly"));
>
> house.plr1 <- polr(Sat ~ Infl + Type + Cont, weights = Freq, data =
> housing);
> drop1(house.plr1,attributes(house.plr1$terms)$term.labels,test="Chisq");
>
> house.plr2 <- polr(Sat ~ Infl * Type + Cont, weights = Freq, data =
> housing);
> drop1(house.plr2,attributes(house.plr2$terms)$term.labels,test="Chisq");
>
> Notice that model 2 has a * instead of a + between predictors Infl and
Type.
> In model 1, estimated parameters are nicely attributed to the right term,
> however in house.plr2, only 2 of the 4 terms are evaluated.
>
> I am using R version 2.7.2 (2008-08-25) i386-pc-mingw32, and MASS_7.2-44.
>
> --
> View this message in context: http://www.nabble.com/weird-behavior-of-
> drop1%28%29-for-polr-models-%28MASS%29-tp19742120p19742120.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] weird behavior of drop1() for polr models (MASS)
I would like to do a SS type III analysis on a proportional odds logistic
regression model. I use drop1(), but dropterm() shows the same behaviour. It
works as expected for regular main effects models, however when the model
includes an interaction effect it seems to have problems with matching the
parameters to the predictor terms. An example:
library("MASS");
options(contrasts = c("contr.treatment", "contr.poly"));
house.plr1 <- polr(Sat ~ Infl + Type + Cont, weights = Freq, data =
housing);
drop1(house.plr1,attributes(house.plr1$terms)$term.labels,test="Chisq");
house.plr2 <- polr(Sat ~ Infl * Type + Cont, weights = Freq, data =
housing);
drop1(house.plr2,attributes(house.plr2$terms)$term.labels,test="Chisq");
Notice that model 2 has a * instead of a + between predictors Infl and Type.
In model 1, estimated parameters are nicely attributed to the right term,
however in house.plr2, only 2 of the 4 terms are evaluated.
I am using R version 2.7.2 (2008-08-25) i386-pc-mingw32, and MASS_7.2-44.
--
View this message in context:
http://www.nabble.com/weird-behavior-of-drop1%28%29-for-polr-models-%28MASS%29-tp19742120p19742120.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] describe function in package Hmisc and function format.dates in chron (PR#13087)
This is because format.dates has become non-callable from outside the chron package. Until the next release of Hmisc you can download a fixed version of the describe function at http://biostat.mc.vanderbilt.edu/svn/R/Hmisc/trunk/R/describe.s Charles [EMAIL PROTECTED] wrote: Full_Name: Kem Phillips Version: 2.7.1 (2008-06-23) OS: Windows Xp professional Submission from: (NULL) (98.221.200.108) The Hmisc function describe fails, giving the error message: Error in formatDateTime(dd, atx, !timeUsed) : could not find function "format.dates" Loading the chron package, where function dates apparently resides, does not fix the problem. Note also that loading chron gives a warning. Earlier versions of chron from the archive failed to load properly. Please see the entire session below, with the error message at the bottom. Thanks. R version 2.7.1 (2008-06-23) Copyright (C) 2008 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. [Previously saved workspace restored] library(Hdisc) Error in library(Hdisc) : there is no package called 'Hdisc' library(Hmisc) Attaching package: 'Hmisc' The following object(s) are masked from package:base : format.pval, round.POSIXt, trunc.POSIXt, units Warning message: package 'Hmisc' was built under R version 2.7.2 library(Design) Loading required package: survival Loading required package: splines Attaching package: 'survival' The following object(s) are masked from package:Hmisc : untangle.specials Design library by Frank E Harrell Jr Type library(help='Design'), ?Overview, or ?Design.Overview') to see overall documentation. Attaching package: 'Design' The following object(s) are masked from package:survival : Surv, survfit The following object(s) are masked from package:Hmisc : .R., .SV4. Warning message: package 'Design' was built under R version 2.7.2 prostate NOTE THAT DATA SET prostate exists patno stage rx dtime status age wt pf hx sbp dbp ekghg sz 1 1 3 0.2 mg estrogen72alive 75 76 normal activity 0 15 9 heart strain 13.798828 2 ….. 505 13 8.39843750 0 3311 506 NA 22.19921880 1 3428 describe(prostate) Error in formatDateTime(dd, atx, !timeUsed) : could not find function "format.dates" library(chron) Warning message: package 'chron' was built under R version 2.7.2 describe(prostate) Error in formatDateTime(dd, atx, !timeUsed) : could not find function "format.dates" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Charles Dupont Computer System Analyst School of Medicine Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rterm.exe, windows event loop running in multiple threads?
> Michael Lawrence writes: > On Thu, Sep 18, 2008 at 7:04 AM, Simon Anders <[EMAIL PROTECTED]> wrote: >> Hi Michael, >> >> Michael Lawrence wrote: >> >>> For processing events, RGtk2 has moved away from using the old tcl_do >> hack >> >>> and now synchronizes on the Windows event loop. In Rgui.exe this works >> >>> fine >> >>> (well mostly), but in Rterm.exe, users report the following warning >> from >> >>> GLib: "main loop already active in another thread". The most obvious >> way >> >>> this could occur is if the Windows event loop were iterating in >> multiple >> >>> threads. This does not seem to be the case from my casual inspection of >> >>> the >> >>> R source. >> >> Following your advice, I have changed my HilbertCurveDisplay package from >> the tcl_do hack to your threading technique. >> >> IIRC, you start this second thread whose event handler gets called >> periodically by a timer. It checks whether there are any pending Gtk >> events, and if so, sends a message to the R main thread in order to cause >> one GTK event loop iteration. >> >> I have writen my gtkmm code the same way and got the same error message, >> repeated many times. However, after I removed the check for pending events >> from the handler of the timer event, the error message vanishes. It seems >> that GTK does not like it if gtk_events_pending() is called from two >> threads even if both threads refer to the same main loop. (Actually, it >> does not mind, as the error is just a warning, and fucntionality ois not >> disrupted. I guess that Rgui.exe gets the same warning but fails to >> display it.) >> >> Could this be the problem for you as well? >> >> [Thinking a bout this again: Why, actually, do we need a second thread. >> Could we not set up a Windows timer that dispatches a message to the main >> thread's event handler peridoically to trigger a polling of the Gtk event >> loop?] >> > Thanks a lot for this tip. I have changed from using a thread to a > timer, and uploaded it as RGtk2 2.12.7 to CRAN. If anyone wants to > test, thanks! Thanks, on CRAN now. Best -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
