R-beta: R0.62.3 problems

Prof Brian Ripley ripley at stats.ox.ac.uk
Tue Sep 1 19:13:13 CEST 1998

From: Jim Lindsey <jlindsey at alpha.luc.ac.be>

> 2. Binary factor variables no longer have the category label stuck on
> the end of the variable name in output from glm(). This is very
> misleading for at least two reasons: (i) there is no way to tell if a
> variable is factor or not just by looking at the output, (ii) in
> various contexts, the level printed out may be the first or the
> second, and it is essential to know which.

That is a `very misleading' statement over a small point!  I was
responsible for that change, which was made a while ago (prior to
0.62.2) in contrasts() as part of a tidying up for compatibility with
S.  If this is `essential', why has no one found it necessary to change
S in the decade (to my knowledge) that it has had no such suffix? (By
`category label stuck on the end of the variable name in output from
glm()' I assume you meant to write that the level of a factor is
appended to the factor name in forming contrast names for treatment
contrasts. Which is not so `misleading'.)  Further:

(i) there never was: how could _you_ tell if sexF was level F of sex or a 
variable?  Why should a 0-1 level factor and a 0-1 variable be treated
differently?  In either case _I_ need to know the coding used. 

(ii) what is printed out is never a level but a coefficient
representing a _difference_ between levels under treatment contrasts,
and other things under others. I think you are falling into the trap of
interpreting coded coefficients of factor variables: if you want to see the
full set of coefficients you need to use dummy.coef() (which is
currently missing from R but coming soon, guess who wrote it).  I
would advocate the use of suffices 1,2,3,...  even for treatment
contrasts to avoid precisely this trap. Think of the suffix (`bit stuck
on') as just indicating which coefficient: if there is only one the
label is redundant.

If despite this you really want the old, incompatible, behaviour, remove
          if (ncol(ctr) == 1) dimnames(ctr) <- list(dimnames(ctr)[[1]], "")
from contrasts(). 

> 4. Is there no way to convince core that the default option for signif
> stars should be FALSE??? At a minimum, modern software should be
> printing out profile likelihood intervals (even SAS does for logistic

Set options(show.signif.stars=F) in your or your site's .Rprofile and
you will never see them again.  I had forgotten they were there ...
except a member of R-core does add the facility to my code from time to

R gives z-ratios for glm fits: S sensibly does not.

The V&R S library MASS does have profile.glm, if not yet for R, so you
might like to make it work and contribute back the needed changes.
(The reason this needs doing is that glm in R is not very like the glm
documented in Chambers & Hastie. Some of you do not like S
compatibility, but the benefits of tapping the S contributors' work is
easily underestimated. This contributor has trouble remembering all the 
foibles of S3, S4 and R.)

I am only interested in inference for subject-matter significant
quantities, and for glms those are often not parameters. They are
usually predictions, though.

> way it behaves) and to vector(). I cannot recheck all of the 100 or
> more functions in my libraries with every new release so that these

Um, why not?  I do check the more than 200 functions in the V&R suite
for each release of R (and more frequently).  (I even release enhanced
versions to make use of new features in new releases.)  Having a test
suite is part of writing statistical software, and R _is_ beta
software.  However, I would be surprised if correct code (that is
adhering to the S described in the Blue Book less changes described in
the R FAQ) was so fragile; my corroborating evidence is that my code
and almost all of the other _public_ packages I have tried survives.

BTW, as I get picked up on this frequently, S has libraries but R has

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 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch

More information about the R-help mailing list