On 11/25/2011 9:10 AM, Terry Therneau wrote:
The ridge() function was put into the survival package as a simple
example of what a user could do with penalized functions. It's not a
"serious" function, and I'd be open to any suggestions for change.
Actually, for any L2 penalty + Cox model one is now better off using
coxme as the maximization process is much better thought out there. I'd
be happy to remove ridge from survival -- except that there are bound to
be lots of folks using the function and any such changes (even good
ones) to the survival package are fraught with peril.
Duncan provided one suggestion: make ridge() an S3 generic, and rename
ridge()
to ridge.coxph(), but this won't work, since you use ridge() inside
coxph() and
survreg() to add a penalty term in the model formula.
Another idea might be simply to not export ridge(), but I have the
feeling this will break
your R CMD checks.
Alternatively, my particular problem (wanting to use car::vif in my
package documentation) would
be solved if John Fox considered making making survival a Suggests:
package rather than a
Depends: one. This might work, since survival is only referenced in car
by providing Anova()
methods for coxph models.
I think all of this raises a general issue of unintended consequences of
"package bloat," where
(a) Depends: packages are forced to load by require()/library(), whether
they are really needed or not;
(b) There is nothing like require(car, depends=FALSE) to circumvent this;
(c) Once a require()'d package is loaded, it cannot be unloaded;
(d) AFAIK, there is no way for a package author to override the masking
of functions or data
provided by other other packages, except by using mypackage::myfun() calls.
To me this seems to be a flaw in the namespace mechanism.
best,
-Michael
--
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept.
York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
4700 Keele Street Web: http://www.datavis.ca
Toronto, ONT M3J 1P3 CANADA
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
