R devel - Apr 2005 - predict.glm(..., type="response") loses names (was RE: [R] A sugg estion for predict function(s))

> From: Ross Darnell 
> 
> Liaw, Andy wrote:
> >>From: Liaw, Andy
> >>
> >>
> >>>From: Ross Darnell 
> >>>
> >>>A good point but what is the value of storing a large set of 
> >>>predicted 
> >>>values when the values of the explanatory variables are lost 
> >>>(predicted 
> >>>values of what?). I thought the purpose of objects was that 
> >>
> >>they were 
> >>
> >>>self explanatory (pardon the pun).
> >>>
> >>>Maybe we could make it optional.
> >>
> >>If what you are looking for is a way to track the 
> >>observations, I'd suggest
> >>simply adding rownames of newdata as names of the predicted 
> >>values.  Storing
> >>names is much cheaper than the entire data frame of 
> >>predictors.  (And in R,
> >>data frames _must_ have unique row names.)
> > 
> > 
> > And as a matter of fact, predict.lm() and predict.glm() 
> > (and probably most other predict() methods) already do 
> > that.
> > 
> > Andy
> > 
> > 
> >>Cheers,
> >>Andy
> >> 
> >>
> >>>Ross Darnell
> >>>-- 
> >>>Email: <r.darnell@uq.edu.au>
> >>>
> Hi Andy
> 
> Where?
> 
> Try predict.glm example
>       ## example from Venables and Ripley (2002, pp. 190-2.)
>       ldose <- rep(0:5, 2)
>       numdead <- c(1, 4, 9, 13, 18, 20, 0, 2, 6, 10, 12, 16)
>       sex <- factor(rep(c("M", "F"), c(6, 6)))
>       SF <- cbind(numdead, numalive=20-numdead)
>       budworm.lg <- glm(SF ~ sex*ldose, family=binomial)
>       ld <- seq(0, 5, 0.1)
>       row.names(predict(budworm.lg, data.frame(ldose=ld,
>          sex=factor(rep("M", length(ld)), levels=levels(sex))),
>          type = "response"))
[You'd want names() rather than row.names(), since predict() 
in this case returns a vector.]
 
I don't know if this is intended (and if it is, I don't 
understand why):  the names are missing only for 
type="response".  For the other types, the names are 
there.  The problem seems to be the order of arguments
in pmin() inside make.link():

            eta <- pmin(thresh, pmax(eta, -thresh))

which should probably be:

            eta <- pmin(pmax(eta, -thresh), thresh)

This is because pmin/pmax preserve the names of it's first 
argument, not the second.

There are quite a few other places in make.link() like
this.  Question to R Core:  Would such fixes be considered
`trivial' enough to make it into R-2.1.0?

Andy 


 
> I'm using
> 
>  > version
>           _
> platform i386-pc-mingw32
> arch     i386
> os       mingw32
> system   i386, mingw32
> status
> major    2
> minor    0.1
> year     2004
> month    11
> day      15
> language R
>  >
> 
> What have I done wrong? I didn't send this to the R list to avoid 
> embarrassing myself.
> 
> Cheers
> 
> Ross Darnell
> -- 
> Email: <r.darnell@uq.edu.au>
> 
> 
>

On Wed, 13 Apr 2005, Liaw, Andy wrote:

[...]
> There are quite a few other places in make.link() like
> this.  Question to R Core:  Would such fixes be considered
> `trivial' enough to make it into R-2.1.0?
No.

This sort of thing could affect packages, and at this point in code freeze 
we are only going to change things which are tightly confined (changing 
endianness in complex vectors in writeBin is one example) or show-stoppers 
(so if for example a new compiler were released and no longer compiled R, 
which has happened in code freeze before).

There will be 2.1.0-patched and no doubt 2.1.1 will be along in 1-2 
months.  Right now (during code freeze) is the least helpful time to make 
suggestions because we do not have any open branch to work on.  (Other 
projects do this differently: I have in the past suggested branching at 
code freeze and releasing from the branch.  But the reason for the exact 
release date is that our release manager is busy until then.)

Please file a report and proposed changes with R-bugs so it does not get 
overlooked.

-- 
Brian D. Ripley,                  ripley@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