On 6/23/05, RenE J.V. Bertin <rjvbertin at gmail.com> wrote:> Hello, > > I was just having a look at the aov function source code, and see that when the model used does not have an Error term, Helmert contrasts are imposed: > > if (is.null(indError)) { > ... > } > else { > opcons <- options("contrasts") > options(contrasts = c("contr.helmert", "contr.poly")) > on.exit(options(opcons)) > ... > > > My reading of several contributed user guides' sections on ANOVA is that Helmert contrasts are not intuitive at all and best avoided by non-expert users. This explains why I didn't see any influence of the various contrast settings on my results, and I wonder why this local shadowing of global settings is done?An aov model is intended to produce just the analysis of variance table for which the choice of contrasts is irrelevant. If you do want to examine individual coefficients then fit the model using lm().
"RenE J.V. Bertin" <rjvbertin at gmail.com> writes:> Hello, > > I was just having a look at the aov function source code, and see that when the model used does not have an Error term, Helmert contrasts are imposed: > > if (is.null(indError)) { > ... > } > else { > opcons <- options("contrasts") > options(contrasts = c("contr.helmert", "contr.poly")) > on.exit(options(opcons)) > ... > > > My reading of several contributed user guides' sections on ANOVA is > that Helmert contrasts are not intuitive at all and best avoided by > non-expert users. This explains why I didn't see any influence of > the various contrast settings on my results, and I wonder why this > local shadowing of global settings is done?I believe the reason is that you get in trouble further down the line if the contrast matrices do not sum to zero over rows, which basically implies contr.helmert or contr.sum. There is some disagreement over whether this is a natural requirement for contrast matrices (Brian and I have discussed this previously, on this list I believe), but this is technical: the code assumes it and gives wrong results if it isn't true. -- O__ ---- Peter Dalgaard ??ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
The source code actually says
## helmert contrasts can be helpful: do we want to force them?
## this version does for the Error model.
opcons <- options("contrasts")
....
and do note it is unset again a few lines later. (Listing a function
inside R is not giving you the `source code'.)
So Helmert contrasts are only used for computing the strata, nothing to do
with your comment as the user never gets to see anything other than the
projections onto strata. Having a nearly orthogonal parametrization helps
numerical stability in e.g. establishing if projections are orthogonal.
On Thu, 23 Jun 2005, RenE J.V. Bertin wrote:
> Hello,
>
> I was just having a look at the aov function source code, and see that
> when the model used does not have an Error term, Helmert contrasts are
> imposed:
If this is really the `source code' as you claim, why did you remove the
very helpful comment?
> if (is.null(indError)) {
> ...
> }
> else {
> opcons <- options("contrasts")
> options(contrasts = c("contr.helmert",
"contr.poly"))
> on.exit(options(opcons))
> ...
>
>
> My reading of several contributed user guides' sections on ANOVA is
that
> Helmert contrasts are not intuitive at all and best avoided by
> non-expert users. This explains why I didn't see any influence of the
> various contrast settings on my results, and I wonder why this local
> shadowing of global settings is done?
As others have noted:
1) The AoV itself does not depend on the coding used.
2) Some other things you can do with an aov fit do, and there you want an
orthogonal parametrization if possible, both for ease of interpretation
and numerical stability.
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
On Thu, 23 Jun 2005, RenE J.V. Bertin wrote:> On Thu, 23 Jun 2005 15:40:25 +0100 (BST), Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote regarding > "Re: [R] contrats hardcoded in aov()?" > > Thanks to all the others who replied. > > 8-) and do note it is unset again a few lines later. (Listing a function > 8-) inside R is not giving you the `source code'.) > > Indeed. Ahem. So Yuelin was right (even if his example didn't use > an Error term). I was misled by the onexit statement, I suppose. Stupid.The on.exit (sic) is needed in case you interrupt R at that point.> > 8-) > 8-) If this is really the `source code' as you claim, why did you remove the > 8-) very helpful comment? > > Trust me, I didn't, at least not on a purpose that I'm aware of. I did a fix(aov), and this is what I got. I did run an update of my installed packages last week (via the Mac GUI's R Package Installer interface). Maybe that stripped comments? I do not appear to unset something like keep.source in my startup files.Let me say it again: Listing a function inside R is not giving you the `source code' You need to look in the *sources* to get the source code.> > 8-) 2) Some other things you can do with an aov fit do, and there you want an > 8-) orthogonal parametrization if possible, both for ease of interpretation > 8-) and numerical stability. > > In other words, you are advising against changing this setting, if > I understand correctly?If you are trying to do expert things with aov() you will know all this, and if not perhaps you should read up some of the expert accounts. There are things for which contr.helmert() is a good choice, and some for which contr.treatment does not meet the traditional definition of `contrast' used in this area and so will be misleading.
>>>>> "RenE" == RenE J V Bertin <rjvbertin at gmail.com> >>>>> on Thu, 23 Jun 2005 17:37:14 +0200 writes:RenE> Thanks to all the others who replied. BDR> and do note it is unset again a few lines later. BDR> (Listing a function inside R is not giving you the BDR> `source code'.) nor does RenE's fix(aov) {mentioned later in his post}. We have been on this topic many times: The source code is in *files*, publicly available from CRAN (and even with your web browser from https://svn.R-project.org/R/ where e.g. tags/R-2-1-1/ contains the source of R 2.1.1). And this applies to CRAN (or Bioconductor) packages as well as the "base R" code: The real source is in files. Looking at the object {via "typing its name" or e.g. fix() or an "object browser"} basically (not quite!) provides the result of source() {+ save() and load() in some cases} of the original source files; and this should be about the same as what you'd get from print( parse(...) ) of the source text. What's the difference? At least these: 1a) All the comments inside functions are lost. 1b) all other comments between object {typically function} definitions, and the grouping {into files; sections inside files, ...} and logical sequence of the definitions is lost. 2) The author's formatting is lost. 3) only " ... " are used for strings (even when the original had '...') 4) numerical constants are shown in a uniform way, not as entered { .1 |-> 0.1 1e1 |-> 10 etc } where "1)" and "2)" can be important and I consider a drawback; 3 and 4 are less important and typically an advantage, and '2)' is an advantage for some people's R code because it makes it prettier. (! ;-) Martin Maechler, ETH Zurich