Paul Johnson <pauljohn32 <at> gmail.com> writes: > > I'd like to learn the process of revising R functions & packages and > then submitting proposed patches to the R Core team. Would someone be > willing to mentor me through one example?
I don't know about mentoring, but I'll give my two cents (some specific and some general thoughts, and some of my own questions). > For starters, consider an example. I'd like to revise the t.test > function to return the stderr value to the user. We only need to > change the "rval" in the third-from-the end line of > stats:::t.test.default. > > Change this: > > rval <- list(statistic = tstat, parameter = df, p.value = pval, > conf.int = cint, estimate = estimate, null.value = mu, > alternative = alternative, method = method, data.name = dname) > class(rval) <- "htest" > return(rval) > > To this: > > rval <- list(statistic = tstat, parameter = df, stderr=stderr, p.value = > pval, > conf.int = cint, estimate = estimate, null.value = mu, > alternative = alternative, method = method, data.name = dname) > class(rval) <- "htest" > return(rval) > > Here is where I need help. > > 1. What other changes in the R code & documents would be required for > consistency? You would certainly want to modify the corresponding manual page. There is an issue with fitting this specific change into the existing R framework. 't.test' returns an object of class 'htest', which is printed using 'stats:::print.htest'. I haven't actually tried it, but it looks to me as though print.htest (which is intended to be a generic class for statistical test -- maybe h stands for "hypothesis", I don't know) will simply ignore "stderr" or any other non-default components of an 'htest' object. There is a '...' argument to 'print.htest', but it functions to pass options to print() for the estimate and the null values. I haven't been able to find any specific documentation about htest. print.htest() is used for a wide range of tests (in the stats package and many contributed packages), so obviously it would be bad to make non-backward-compatible changes. I think it might be best to modify print.htest() so it looked for any additional/non-standard components of the object and printed them after all the other output (they would need to have reasonable labels incorporated somehow too). > > 2. How does R Core Team expect/accept patches? > I do understand a bit about SVN and CVS. I think I could mark this up > and make a diff, but I'm uncertain about the details. I think that patches via "svn diff" against the latest SVN are preferred. The only routes I know for submission are (1) sending patch files to R-devel or (2) submitting them to the R bugs system as a "wishlist" item. I don't know which is preferred. > 3. How would I best prepare a suggestion like this so as to get it > accepted into R? I think the accepted method (although I don't know whether this is documented anywhere) is to do what you have done, submitting a "request for discussion" on r-devel, getting it discussed, posting patches for comment, and hoping for the best. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
