Warnes, Gregory R
2001-May-23 18:56 UTC
RE^2: [Rd] New generic functions in "R base" {was `truncate'}
> From: Martin Maechler [mailto:maechler@stat.math.ethz.ch] > Sent: Friday, May 18, 2001 11:30 AM > To: gregory_r_warnes@groton.pfizer.com > Subject: RE^2: [Rd] New generic functions in "R base" {was `truncate'} >[...]> Apropos ci() : > > There's the very generally useful confint() function in MASS. > Since MASS will become one of the recommended packages `real soon now', > I doubt that we'd want yet another one in `base'. > Or do you have reasons to prefer your ci() over V&R's confint() ? > If so, it may make quite some sense discussing that on R-devel.. > > Regards, MartinActually, I wasn't aware of the confint() function in MASS. My ci() function doesn't have any particular advantage. Actually, this illustrates a problem and raises another issue. As it turns out, I'm not the only one to have (unnecessarily) re-implemented the features of confint() because it didn't occur to me to look in MASS for it. I'm sure that others have had the same thing happen. Shouldn't such generally useful functions get moved into base or some other package that is on the default search path? -Greg LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel 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-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Prof Brian Ripley
2001-May-23 19:40 UTC
RE^2: [Rd] New generic functions in "R base" {was `truncate'}
On Wed, 23 May 2001, Warnes, Gregory R wrote:> > > From: Martin Maechler [mailto:maechler@stat.math.ethz.ch] > > Sent: Friday, May 18, 2001 11:30 AM > > To: gregory_r_warnes@groton.pfizer.com > > Subject: RE^2: [Rd] New generic functions in "R base" {was `truncate'} > > > > [...] > > > Apropos ci() : > > > > There's the very generally useful confint() function in MASS. > > Since MASS will become one of the recommended packages `real soon now', > > I doubt that we'd want yet another one in `base'. > > Or do you have reasons to prefer your ci() over V&R's confint() ? > > If so, it may make quite some sense discussing that on R-devel.. > > > > Regards, Martin > > Actually, I wasn't aware of the confint() function in MASS. My ci() > function doesn't have any particular advantage. > > > Actually, this illustrates a problem and raises another issue. As it turns > out, I'm not the only one to have (unnecessarily) re-implemented the > features of confint() because it didn't occur to me to look in MASS for it. > I'm sure that others have had the same thing happen. > > Shouldn't such generally useful functions get moved into base or some other > package that is on the default search path?Interesting Q. Partly for perfomance reasons and partly for embedded applications, we are trying to make base a lot smaller. The agreed idea seems to be to have a tiny core for R and lots of added functionality. Unfortunately whereas S seems to be able to have long search paths without performance penalty, we haven't found the right tricks in R (although it is much better than it once was). So just adding MASS to the path has something like a 5% penalty (last timed just pre-1.2.0). And careful observers may have noticed that R gets a little slower (on almost) each release. One step in this direction that 1.3.0 will have is load-on-demand modules, that is compiled code that is not loaded until used. This allowed us to avoid a 50% increase in code size. Brian -- 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel 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-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Paul Gilbert
2001-May-23 20:33 UTC
RE^2: [Rd] New generic functions in "R base" {was `truncate'}
>Actually, this illustrates a problem and raises another issue. As itturns>out, I'm not the only one to have (unnecessarily) re-implemented the >features of confint() because it didn't occur to me to look in MASS forit.>I'm sure that others have had the same thing happen.Some search/browse capability sure would be nice and I think this problem is going to get worse with the elimination of function.html in R 1.3.0. Perhaps there is a possibility of putting a giant index of all functions in all packages on CRAN?>Shouldn't such generally useful functions get moved into base or some >other package that is on the default search path?The potential for name conflicts seems rather severe with this approach. Paul Gilbert -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel 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-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Warnes, Gregory R
2001-May-23 21:40 UTC
RE^2: [Rd] New generic functions in "R base" {was `truncate'}
> From: Prof Brian Ripley [mailto:ripley@stats.ox.ac.uk]> > Warnes, Gregory R wrote: > > > > Shouldn't such generally useful functions get moved into base or some other > > package that is on the default search path? > > Interesting Q. Partly for performance reasons and partly for > embedded applications, we are trying to make base a lot smaller. > The agreed idea seems to be to have a tiny core for R and lots of added > functionality. I think the problem is that functions are not necessarily well grouped into coherent packages. Currently, what functionality is contained in each package isn't being managed, per se. Rather packages and functions within packages seem to be accumulating organically. The need to trim down R-base to provides us with the opportunity to think about how features are divided into packages. We should make sure that the packages that we create are coherently organized. To do this , we will need to "pull in" code from existing packages as well as "separating out" code from R-base. -Greg LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel 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-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._